There are 6 common deployment scenarios for Active Directory Domain Services on AWS. Here’s how to handle each of them.
Key Takeaways
- You can use an existing on-premises Microsoft Active Directory with Amazon WorkSpaces.
- By using AWS Directory Service for Microsoft Active Directory, you can create multiple types of directories with WorkSpaces.
- There are six Active Directory Domain Services deployment scenarios with WorkSpaces; each has its pros and cons and must be evaluated accordingly.
- Along with careful consideration of AD DS deployment scenarios with WorkSpaces, it is crucial to evaluate the design factors for any deployment.
- Partnering with an Amazon Premier Partner like CloudHesive can help you streamline AD DS deployment with WorkSpaces.
With Amazon WorkSpaces, you can leverage your existing on-premises Microsoft Active Directory (AD). You can also use AWS Directory Service (DS) for Microsoft Active Directory to set up the several types of directories with WorkSpaces:
- AWS Managed Microsoft AD: Managed AD powered by Windows Server 2012 R2; standard and enterprise versions of AWS Managed Microsoft AD are available.
- Simple AD: Standalone, AD-compatible, managed directory service powered by Samba 4.
- AD Connector: Directory proxy that redirects authentication requests and user or group lookups to an existing on-premises AD.
In order to get the best results from these directories, proper design and deployment are critical. Here’s how to build six AD DS on AWS deployment scenarios with WorkSpaces.
Scenario #1: Using AD Connector to proxy authentication to an on-premises AD service
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. 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.
The scenario is ideal for those who do not want to deploy AD DS into the cloud. Yet, with this scenario, your WorkSpaces authentication experience is dependent on the network link between AD and the WorkSpaces Virtual Private Connector. Thus, you must ensure this link is highly available.
Scenario #2: Extending on-premises AD DS into AWS
This scenario is similar to Scenario #1. The difference is that a replica of the customer AD DS is deployed on AWS in combination with AD Connector. This minimizes the risk of latency of authentication or query requests to AD DS.
In Scenario #2, AD Connector is used for user or MFA authentication and is proxied to the customer AD DS. 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. Each domain controller is deployed into VPC private subnets, so AD DS is highly available in the AWS Cloud.
After WorkSpaces instances are deployed, they can access cloud-based domain controllers for secure, low-latency directory services and DNS. Meanwhile, all network traffic is secured within the private subnets or across the customer VPN tunnel or Direct Connect.
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.
Scenario #3: Standalone isolated deployment using AWS Directory Service in AWS Cloud
This scenario involves the deployment of AD DS in the AWS Cloud in a standalone isolated environment. Only AWS Directory Service is used, so customers rely on AWS Directory Service to monitor domain controllers, configure backups and snapshots, and similar tasks.
Like Scenario #2, this scenario involves the deployment of AD DS into dedicated subnets that span two Availability Zones. AD Connected is also deployed for WorkSpaces authentication or MFA to separate roles or functions within the Amazon VPC.
Scenario #3 is an all-in configuration. It works well for customers who want AWS to manage the deployment, patching, high availability, and monitoring of AWS Directory Service. The scenario is also ideal for proof of concepts, lab, and production environments due to its isolation mode.
Scenario #4: AWS Microsoft AD and a two-way transitive trust to on-premises
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. Also, user accounts and WorkSpaces are set up in the Managed AD, and the AD trust ensures resources can be accessed on-premises.
The deployment of Scenario #4 is nearly identical to that of Scenario #3, but Scenario #4 requires a domain trust, along with security groups and firewall rules, that allow communication between the two active directories.
Scenario #4 is intended for customers who want to have a fully managed AWS Directory Service. In addition, the scenario allows WorkSpaces users to access AD-joined resources on their existing networks.
Scenario #5: AWS Microsoft AD using a Shared Services VPC
In scenario #5, AWS Managed AD is deployed in the AWS Cloud to provide authentication services for workloads that are hosted in AWS or will be as part of a larger migration. It typically delivers the optimal results with WorkSpaces in a dedicated VPC. Customers should also create a specific AD organizational unit to organize the WorkSpaces computer objects.
To deploy WorkSpaces with a Shared Services VPC hosting Managed AD, use an AD Connector with an ADC service account created in the Managed AD. Next, the service account will require permissions to create computer objects in WorkSpaces designated OU in the Shared Services Managed AD.
Scenario #6: AWS Microsoft AD, Shared Services VPC, and a one-way trust to on-premises
This scenario involves the use of an existing on-premises AD for user accounts and a separate Managed AD in AWS Cloud to host computer objects associated with WorkSpaces. In this scenario, a specific AD OU is created to organize WorkSpaces computer objects in the Shared Services AD.
To deploy WorkSpaces with computer objects created in a Shared Services VPC hosting Managed AD using user accounts from a customer domain, deploy an AD Connector that references the corporate AD. An ADC Service Account created in the corporate AD can grant permissions to create computer objects in the OU that was configured for WorkSpaces in the Shared Services Managed AD.
Design considerations for AD DS deployment in WorkSpaces
To successfully deploy AD DS in the AWS Cloud, you need to consider various design factors, including:
- VPC design: AD DS should be deployed in the AWS Cloud into a dedicated pair of private subnets, across two Availability Zones, and separated from AD Connector or WorkSpaces subnets.
- AD sites and services: You must define the correct site topology to ensure your WorkSpaces use the appropriate local domain controller.
- MFA: To implement MFA, your WorkSpaces infrastructure must use AD Connector as its AWS Directory Service and have a RADIUS server.
In addition to the following design considerations for AD DS deployment in WorkSpaces, it often helps to work with an Amazon Premier Partner that understands the ins and outs of WorkSpaces.
Call CloudHesive today at (800) 860-2040 to learn about our competitive advantage (also known as our Superpowers) and how we can apply it to your WorkSpaces environment!
