In Scenario #4, AWS Managed AD is deployed in the AWS Cloud, resulting in a two-way transitive trust to the customer’s on-premises AD. Scenario #4: AWS Microsoft AD and a two-way transitive trust to on-premises The scenario is also ideal for proof of concepts, lab, and production environments due to its isolation mode. It works well for customers who want AWS to manage the deployment, patching, high availability, and monitoring of AWS Directory Service. AD Connected is also deployed for WorkSpaces authentication or MFA to separate roles or functions within the Amazon VPC. Like Scenario #2, this scenario involves the deployment of AD DS into dedicated subnets that span two Availability Zones. Only AWS Directory Service is used, so customers rely on AWS Directory Service to monitor domain controllers, configure backups and snapshots, and similar tasks. This scenario involves the deployment of AD DS in the AWS Cloud in a standalone isolated environment. Scenario #3: Standalone isolated deployment using AWS Directory Service in AWS Cloud Perhaps the biggest benefit of using this scenario is that the WorkSpaces authentication experience is not dependent on the network link between the customer AD because the AD Directory Services are available in AWS.
Meanwhile, all network traffic is secured within the private subnets or across the customer VPN tunnel or Direct Connect. Each domain controller is deployed into VPC private subnets, so AD DS is highly available in the AWS Cloud.Īfter WorkSpaces instances are deployed, they can access cloud-based domain controllers for secure, low-latency directory services and DNS. Next, the customer AD DS is deployed across Availability Zones on Amazon EC2 instances, which function as domain controllers in the customer’s on-premises AD forest running in the AWS Cloud. In Scenario #2, AD Connector is used for user or MFA authentication and is proxied to the customer AD DS. This minimizes the risk of latency of authentication or query requests to AD DS. The difference is that a replica of the customer AD DS is deployed on AWS in combination with AD Connector. Scenario #2: Extending on-premises AD DS into AWS Thus, you must ensure this link is highly available. Yet, with this scenario, your WorkSpaces authentication experience is dependent on the network link between AD and the WorkSpaces Virtual Private Connector. The scenario is ideal for those who do not want to deploy AD DS into the cloud. It is designed for those who do not want to extend their on-premises AD service into AWS or instances where a new AD DS deployment is not an option. In the scenario, AWS Directory Service Active Directory Connector is utilized for user or multi-factor authentication proxied through the AD Connector to the customer on-premises AD DS. Scenario #1: Using AD Connector to proxy authentication to an on-premises AD service
AWS WORKSPACES MFA HOW TO
Here’s how to build six AD DS on AWS deployment scenarios with WorkSpaces. In order to get the best results from these directories, proper design and deployment are critical. AD Connector : Directory proxy that redirects authentication requests and user or group lookups to an existing on-premises AD.Simple AD: Standalone, AD-compatible, managed directory service powered by Samba 4.
AWS WORKSPACES MFA WINDOWS
AWS Managed Microsoft AD: Managed AD powered by Windows Server 2012 R2 standard and enterprise versions of AWS Managed Microsoft AD are available.You can also use AWS Directory Service (DS) for Microsoft Active Directory to set up the several types of directories with WorkSpaces:
With Amazon WorkSpaces, you can leverage your existing on-premises Microsoft Active Directory (AD).
0 kommentar(er)
