# AD DS deployment scenarios
Backing Amazon WorkSpaces is the AWS Directory Service, and the proper design and deployment of the directory service is critical. The following six scenarios build on the [Active Directory Domain Services](https://docs.aws.amazon.com/quickstart/latest/active-directory-ds/architecture.html) *in the AWS Quick Start guide*, and describe the best practice deployment options for AD DS when used with Amazon WorkSpaces. The [Design Considerations](using-multi-region-aws-managed-active-directory-with-amazon-workspaces.md) section of this document details the specific requirements and best practices of using AD Connector for WorkSpaces, which is an integral part of the overall WorkSpaces design concept.
+ **Scenario 1: Using AD Connector to proxy authentication to on-premises AD DS** — In this scenario, network connectivity (VPN/Direct Connect) is in place to the customer, with all authentication proxied via AWS Directory Service (AD Connector) to the customer on-premises AD DS.
+ **Scenario 2: Extending on-premises AD DS into AWS (Replica)** — This scenario is similar to scenario 1, but here a replica of the customer AD DS is deployed on AWS in combination with AD Connector, reducing latency of authentication/query requests to AD DS and the AD DS global catalog.
+ **Scenario 3: Standalone isolated deployment using AWS Directory Service in the AWS Cloud** — This is an isolated scenario and doesn’t include connectivity back to the customer for authentication. This approach uses AWS Directory Service (Microsoft AD) and AD Connector. Although this scenario doesn’t rely on connectivity to the customer for authentication, it does make provision for application traffic where required over VPN or Direct Connect.
+ **Scenario 4: AWS Microsoft AD and a Two-Way Transitive Trust to On-Premises** — This scenario includes the AWS Managed Microsoft AD Service (MAD) with a two-way transitive trust to the on-premises Microsoft AD Forest.
+ **Scenario 5: AWS Microsoft AD using a Shared Services VPC** — This scenario uses AWS Managed Microsoft AD in a Shared Services VPC to be used as an Identity Domain for multiple AWS Services (Amazon EC2, Amazon WorkSpaces, and so on.) while using the AD Connector to proxy Lightweight Directory Access Protocol (LDAP) user authentication requests to the AD domain controllers.
+ **Scenario 6: AWS Microsoft AD, Shared Services VPC, and a One-Way Trust to On-Premises AD** — This scenario is similar to Scenario 5, but it includes disparate identity and resource domains using a one-way trust to on-premises.
You need to make several considerations when selecting your deployment scenario for Active Directory Domain Services (ADDS). This section explains the role of the AD Connector with Amazon WorkSpaces, and covers some important considerations when selecting an ADDS deployment scenario. For further guidance on design and planning of ADDS on AWS, please consult the [ Active Directory Domain Services on AWS Design and Planning Guide](https://d1.awsstatic.com/whitepapers/adds-on-aws.pdf).
# The Role of the AWS AD Connector with Amazon WorkSpaces
The [AWS AD Connector](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_ad_connector.html) is an AWS Directory Service that acts as a proxy service for an Active Directory. It does not store or cache any user credentials, but forwards authentication or lookup requests to your Active Directory—on-premises or on AWS. Unless you are using AWS Managed Microsoft AD, it is also the only way to register your Active Directory (on-premises or extended to AWS) for use with Amazon WorkSpaces (WorkSpaces).
An AD Connector can point to your on-premises Active Directory, to an Active Directory extended to AWS (AD Domain Controllers on Amazon EC2), or to an AWS Managed Microsoft AD.
The AD Connector plays an important role with most of the deployment scenarios covered in the following sections. Using the AD Connector with WorkSpaces provides a number of benefits:
+ When pointed to your corporate Active Directory, it allows your users to use their existing corporate credentials to log on to WorkSpaces and other services, such as [Amazon WorkDocs](https://aws.amazon.com/workdocs/).
+ You can consistently apply existing security policies (password expiration, account lockouts, etc.) whether your users are accessing resources in your on-premises infrastructure or in the AWS Cloud, such as WorkSpaces.
+ The AD Connector enables a simple integration with your existing RADIUS-based MFA infrastructure to provide an additional layer of security.
+ It enables segregation of your users. For example, it allows the configuration of a number of WorkSpaces options per business unit or persona, since multiple AD Connectors can be pointing to the same Domain Controllers (DNS servers) of Active Directory for user authentication:
+ Target Domain or Organizational Unit for targeted application of Active Directory Group Policy Objects (GPOs)
+ Different Security Groups to control traffic flow to/from WorkSpaces
+ Different Access Control Options (allowed client devices) and IP Access Control Groups (limit access to IP ranges)
+ Selective enabling of Local Administrator Permissions
+ Different Self-Service Permissions
+ Selective enforcement of Multi-Factor Authentication (MFA)
+ Placement of your WorkSpaces Elastic Network Interfaces (ENI) into different VPCs or Subnets for isolation
Multiple AD Connectors also allow to support a larger number of users, if you are hitting the performance limit of a single small or large AD Connector. Please refer to the [Sizing of AWS Managed Microsoft AD](#sizing-aws-managed-microsoft-ad) section for more detail.
The use of AD Connectors with WorkSpaces is free of charge, as long as you have at least one active WorkSpaces user in a small AD Connector and at least 100 active WorkSpaces users in a large AD Connector. For more information, see the [AWS Directory Services Pricing](https://aws.amazon.com/directoryservice/pricing/) page.
## The Importance of Your Network Link to AWS With an On-Premises Active Directory
WorkSpaces relies on connectivity to your Active Directory. Hence, the availability of the network link to your Active Directory is of utmost importance. For example, if your network link in [ Scenario 1](scenario-1-using-ad-connector-to-proxy-authentication-to-on-premises-active-directory-service.md) is down, your users won’t be able to authenticate, and as a result won’t be able to use their WorkSpaces.
If an on-premises Active Directory is to be used as part of the scenario, you’ll need to consider resiliency, latency, and traffic cost of your network link to AWS. In a multi-region WorkSpaces deployment, this may involve multiple network links in different AWS Regions, or multiple AWS Transit Gateways with peering established between them to route your AD traffic to the VPC with connectivity to your on-premises AD. These network link considerations apply to most of the scenarios outlined in the following sections, but are especially important for those scenarios where your AD traffic from AD Connectors and WorkSpaces needs to traverse the network link to reach your on-premise Active Directory. [ Scenario 1](scenario-1-using-ad-connector-to-proxy-authentication-to-on-premises-active-directory-service.md) highlights some of the caveats.
## Using Multi-Factor Authentication with WorkSpaces
If you plan to use Multi-Factor Authentication (MFA) with WorkSpaces, you must use an AWS AD Connector or an AWS Managed Microsoft AD, since only these services allow registration of the directory for use with WorkSpaces and configuration of RADIUS. For the placement of your RADIUS servers, the network link considerations covered in the [The Importance of Your Network Link to AWS With an On-Premises Active Directory](#network-link-to-aws-with-on-premises-ad) section apply.
## Separating Account and Resource Domain
For security reasons or for better manageability, it might be desirable to separate the Account Domain from the Resource Domain. For example, place the WorkSpaces Computer Objects into a separate Resource Domain, while the Users are part of the Account Domain. An implementation like this can be used to allow a partner organization to manage the WorkSpaces using AD Group Policies in the Resource Domain, while not relinquishing control or granting access to the Account Domain. This can be accomplished by using two Active Directories with a configured Active Directory Trust. The following sections cover this in more detail:
+ [Scenario 4: AWS Microsoft AD and a two-way transitive trust to on-premises](scenario-4-aws-microsoft-ad-and-a-two-way-transitive-trust-to-on-premises.md)
+ [Scenario 6: AWS Microsoft AD, shared services VPC, and a one-way trust to on-premises](scenario-6-aws-microsoft-ad-shared-services-vpc-and-a-one-way-trust-to-on-premises.md)
## Large Active Directory Deployments
You must ensure that Active Directory Sites & Services is configured accordingly. This is especially important if your Active Directory consists of a large number of domain controllers in different geographical locations. Your Windows WorkSpaces use the [standard Microsoft mechanism](https://social.technet.microsoft.com/wiki/contents/articles/24457.how-domain-controllers-are-located-in-windows.aspx) to discover their domain controller for the Active Directory Site they’re assigned to. This DC Locator process relies on DNS and may be significantly prolonged in case a lengthy list of domain controllers with unspecific priority and weight is returned at the early stage of the DC Locator process. More importantly, if your WorkSpaces get “pinned“ to a sub-optimal domain controller, all subsequent communication with this domain controller may suffer from increased network latency and reduced bandwidth when traversing wide area network links. This will slow down any communication with the domain controller, including processing of a potentially large number of Group Policy Objects (GPOs), and file transfers from the domain controller. Depending on the network topology, it may also increase your networking cost, because the data exchanged between WorkSpaces and domain controllers might unnecessarily traverse a costlier network path. Refer to the [VPC design](design-considerations.md) and [Design considerations](design-considerations.md) sections for guidance on DHCP and DNS with your VPC design, and Active Directory Sites & Services.
## Using Microsoft Azure Active Directory or Active Directory Domain Services with WorkSpaces
If you intend to use Microsoft Azure Active Directory with WorkSpaces, you might use Azure AD Connect to synchronize your identity with your on-premises Active Directory or with your Active Directory on AWS (Domain Controller on Amazon EC2 or AWS Managed Microsoft AD). However, this will not allow you to join WorkSpaces to your Azure Active Directory. For more information, see the [ Microsoft Hybrid Identity Documentation](https://docs.microsoft.com/en-us/azure/active-directory/hybrid/) in the *Microsoft Azure Documentation*.
If you want to join your WorkSpaces to your Azure Active Directory, you will need to deploy Microsoft Azure Active Directory Domain Services (Azure AD DS), establish connectivity between AWS and Azure, and use an AWS AD Connector pointing to your Azure AD DS Domain Controllers. For more information about how to set this up, see the [ Add your WorkSpaces to Azure AD using Azure Active Directory Domain Services](https://aws.amazon.com/blogs/desktop-and-application-streaming/add-your-workspaces-to-azure-ad-using-azure-active-directory-domain-services/) blog post.
When using AWS Directory Services with WorkSpaces, you’ll have to consider the size of your WorkSpaces deployment and its expected growth in order to size the AWS Directory Service appropriately. This section provides guidance on sizing the AWS Directory Service for use with WorkSpaces. We also recommend you review the [Best practices for AD Connector](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_best_practices.html) and the [Best practices for AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_best_practices.html) sections in the *AWS Directory Service Administration Guide*.
## Sizing of AD Connector with WorkSpaces
The Active Directory Connector (AD Connector) is available in two sizes, Small and Large. While there are no enforced user or connection limits, we recommend to use a small AD Connector for up to 500 WorkSpaces entitled users, and a large AD Connector for up to 5000 WorkSpaces entitled users. You can spread application loads across multiple AD Connector to scale to your performance needs. For example, if you need to support 1500 WorkSpaces users, you may spread your WorkSpaces equally across three small AD Connector, each supporting 500 users. If all of your users reside in the same Domain, the AD Connector can all point to the same set of DNS Servers resolving your Active Directory Domain.
Note, if you started with a small AD Connector, and your WorkSpaces deployment grows over time, you can raise a support ticket to have the size of your AD Connector changed from small to large in order to handle the larger number of WorkSpaces entitled users.
## Sizing of AWS Managed Microsoft AD
[AWS Managed Microsoft AD](https://aws.amazon.com/directoryservice/active-directory/) lets you run Microsoft Active Directory as a managed service. You can choose between Standard Edition and Enterprise Edition when you launch the service. The Standard Edition is recommended for small and midsize business with up to 5,000 users, and supports up to roughly 30,000 directory objects, such as users, groups, and computers. The Enterprise Edition is designed to support up to 500,000 directory objects and also offers an additional feature, such as [multi-Region replication](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_configure_multi_region_replication.html).
If you need to support more than 500,000 directory objects, consider deploying Microsoft Active Directory Domain Controllers on Amazon EC2. For the sizing of these Domain Controllers refer to Microsoft’s [Capacity planning for Active Directory Domain Services](https://docs.microsoft.com/en-us/windows-server/administration/performance-tuning/role/active-directory-server/capacity-planning-for-active-directory-domain-services) document.
# Scenario 1: Using AD connector to proxy authentication to on-premises Active Directory Service
This scenario is for customers who don’t want to extend their on-premises AD service into AWS, or where a new deployment of AD DS is not an option. The following figure shows at a high level, each of the components, and the user authentication flow.
![\[Sample architecture showing at a high-level each component and user authentication flow.\]](http://docs.aws.amazon.com/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/ad-connector-to-onprem.png)
In this scenario, AWS Directory Service (AD Connector) is used for all user or MFA authentication that is proxied through the AD Connector to the customer on-premises AD DS (detailed in the following figure). For details on the protocols or encryption used for the authentication process, refer to the [Security](security.md) section of this document.
![\[Sample architecture showing how AD Connector is used for all user or MFA authentication that is proxied through the AD Connector to the customer on-premises AD DS.\]](http://docs.aws.amazon.com/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/user-authentication-auth-gateway.png)
Scenario 1 shows a hybrid architecture where the customer might already have resources in AWS, as well as resources in an on-premises data center that could be accessed via Amazon WorkSpaces. The customer can leverage their existing on-premises AD DS and RADIUS servers for user and MFA authentication.
This architecture uses the following components or constructs:
## AWS
+ **Amazon VPC** — Creation of an Amazon VPC with at least two private subnets across two AZs.
+ **DHCP Options Set** — Creation of an Amazon VPC DHCP Options Set. This allows customer-specified domain name and domain name servers (DNS) (on-premises services) to be defined. For more information, refer to [DHCP options sets](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html).
+ **Amazon Virtual Private Gateway** — Enable communication with your own network over an IPsec VPN tunnel or an AWS Direct Connect connection.
+ **AWS Directory Service** — AD Connector is deployed into a pair of Amazon VPC private subnets.
+ **Amazon WorkSpaces** — WorkSpaces are deployed in the same private subnets as the AD Connector. For more information, refer to the [Active Directory: Sites and Services](design-considerations.md#active-directory-sites-and-services) section of this document.
## Customer
+ **Network connectivity** — Corporate VPN or Direct Connect endpoints.
+ **AD DS** — Corporate AD DS.
+ **MFA (optional)** — Corporate RADIUS server.
+ **End user devices** — Corporate or bring your own license (BYOL) end user devices (such as Windows, Macs, iPads, Android tablets, zero clients, and Chromebooks) used to access the Amazon WorkSpaces service. Refer to [this list of client applications for supported devices and web browsers](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client).
Although this solution is great for customers who don’t want to deploy AD DS into the cloud, it does come with some caveats:
+ **Reliance on connectivity** — If connectivity to the data center is lost, users cannot log in to their respective WorkSpaces, and existing connections will remain active for the Kerberos/Ticket-Granting Ticket (TGT) lifetime.
+ **Latency** — If latency exists via the connection (this is more the case with VPN than Direct Connect), then WorkSpaces authentication and any AD DS-related activity, such as Group Policy (GPO) enforcement, will take more time.
+ **Traffic costs** — All authentication must traverse the VPN or Direct Connect link, and so it depends on the connection type. This is either Data Transfer Out from Amazon EC2 to internet or Data Transfer Out (Direct Connect).
**Note**
AD Connector is a proxy service. It doesn’t store or cache user credentials. Instead, all authentication, lookup, and management requests are handled by your AD. An account with delegation privileges is required in your directory service with rights to read all user information and join a computer to the domain.
In general, the WorkSpaces experience is highly dependent on the Active Directory authentication process shown in the previous figure. For this scenario, the WorkSpaces authentication experience is highly dependent on the network link between the customer AD and the WorkSpaces VPC. The customer should ensure the link is highly available.
# Scenario 2: Extending on-premises AD DS into AWS (replica)
This scenario is similar to scenario 1. However, in this scenario, a replica of the customer AD DS is deployed on AWS in combination with AD Connector. This reduces latency of authentication or query requests to AD DS running on Amazon Elastic Compute Cloud (Amazon EC2). The following figure shows a high-level view of each of the components and the user authentication flow.
![\[Sample architecture showing a replica of the customer AD DS is deployed on AWS in combination with AD Connector.\]](http://docs.aws.amazon.com/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/extend-customer-ad-cloud.png)
As in scenario 1, AD Connector is used for all user or MFA authentication, which in turn is proxied to the customer AD DS (refer to [the previous figure](scenario-1-using-ad-connector-to-proxy-authentication-to-on-premises-active-directory-service.md#fig5)). In this scenario, the customer AD DS is deployed across AZs on Amazon EC2 instances that are promoted to be domain controllers in the customer’s on-premises [AD forest](https://ipwithease.com/what-is-a-forest-in-active-directory/), running in the AWS Cloud. Each domain controller is deployed into VPC private subnets to make AD DS highly available in the AWS Cloud. For best practices for deploying AD DS on AWS, refer to the [Design Considerations](using-multi-region-aws-managed-active-directory-with-amazon-workspaces.md) section of this document.
After WorkSpaces instances are deployed, they have access to the cloud-based domain controllers for secure, low-latency directory services and DNS. All network traffic, including AD DS communication, authentication requests, and AD replication, is secured either within the private subnets or across the customer VPN tunnel or Direct Connect.
This architecture uses the following components or constructs:
## AWS
+ **Amazon VPC** — Creation of an Amazon VPC with at least four private subnets across two AZs — two for the customer AD DS, two for AD Connector or Amazon WorkSpaces.
+ **DHCP Options Set** — Creation of an Amazon VPC DHCP options set. This allows the customer to define a specified domain name and DNSs (AD DS local). For more information, refer to [DHCP Options Sets](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html).
+ **Amazon Virtual Private Gateway** — Enable communication with a customer-owned network over an IPsec VPN tunnel or AWS Direct Connect connection.
+ **Amazon EC2**
+ Customer corporate AD DS domain controllers deployed on Amazon EC2 instances in dedicated private VPC subnets.
+ Customer (optional) RADIUS servers for MFA on Amazon EC2 instances in dedicated private VPC subnets.
+ **AWS Directory Services** — AD Connector is deployed into a pair of Amazon VPC private subnets.
+ **Amazon WorkSpaces** — WorkSpaces are deployed into the same private subnets as the AD Connector. For more information, refer to the [Active Directory: Sites and Services](design-considerations.md#active-directory-sites-and-services) section of this document.
## Customer
+ **Network connectivity** — Corporate VPN or AWS Direct Connect endpoints.
+ **AD DS** — Corporate AD DS (required for replication).
+ **MFA (optional)** — Corporate RADIUS server.
+ **End user devices** — Corporate or BYOL end user devices (such as Windows, Macs, iPads, Android tablets, zero clients, and Chromebooks) used to access the Amazon WorkSpaces service. Refer to the [list of client applications for supported devices and web browsers](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client). This solution doesn’t have the same caveats as scenario 1. Amazon WorkSpaces and AWS Directory Service have no reliance on the connectivity in place.
+ **Reliance on connectivity** — If connectivity to the customer data center is lost, end users can continue to work because authentication and *optional* MFA are processed locally.
+ **Latency** — With the exception of replication traffic, all authentication is local and low latency. Refer to the [Active Directory: Sites and Services](design-considerations.md#active-directory-sites-and-services) section of this document.
+ **Traffic costs** — In this scenario, authentication is local, with only AD DS replication having to traverse the VPN or Direct Connect link, reducing data transfer.
In general, the WorkSpaces experience is enhanced and isn’t highly dependent connectivity to the on-premises domain controllers, as shown in the previous figure. This is also the case when a customer wants to scale WorkSpaces to thousands of desktops, especially in relation to AD DS global catalog queries, as this traffic remains local to the WorkSpaces environment.
# Scenario 3: Standalone isolated deployment using AWS Directory Service in the AWS Cloud
This scenario, shown in the following figure, has AD DS deployed in the AWS Cloud in a standalone isolated environment. AWS Directory Service is used exclusively in this scenario. Instead of fully managing AD DS, customers can rely on AWS Directory Service for tasks such as building a highly available directory topology, monitoring domain controllers, and configuring backups and snapshots.
![\[Sample architecture showing AD DS deployed in the AWS Cloud in a standalone isolated environment.\]](http://docs.aws.amazon.com/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/cloud-only-ad-microsoft.png)
As in scenario 2, the AD DS (Microsoft AD) is deployed into dedicated subnets that span two AZs, making AD DS highly available in the AWS Cloud. In addition to Microsoft AD, AD Connector (in all three scenarios) is deployed for WorkSpaces authentication or MFA. This ensures separation of roles or functions within the Amazon VPC, which is a standard best practice. For more information, refer to the [Design Considerations](using-multi-region-aws-managed-active-directory-with-amazon-workspaces.md) section of this document.
Scenario 3 is a standard, all-in configuration that works well for customers who want to have AWS manage the deployment, patching, high availability, and monitoring of the AWS Directory Service. The scenario also works well for proof of concepts, lab, and production environments because of its isolation mode.
In addition to the placement of AWS Directory Service, this figure shows the flow of traffic from a user to a workspace and how the workspace interacts with the AD server and MFA server.
This architecture uses the following components or constructs.
## AWS
+ **Amazon VPC** — Creation of an Amazon VPC with at least four private subnets across two AZs — two for AD DS [Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html), two for AD Connector or WorkSpaces.
+ **DHCP options set** — Creation of an Amazon VPC DHCP options set. This allows a customer to define a specified domain name and DNS (Microsoft AD). For more information, refer to [DHCP options sets](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html).
+ **Optional: Amazon virtual private gateway** — Enable communication with a customer-owned network over an IPsec VPN tunnel (VPN) or AWS Direct Connect connection. Use for accessing on-premises back-end systems.
+ **AWS Directory Service** — Microsoft AD deployed into a dedicated pair of VPC subnets (AD DS Managed Service).
+ **Amazon EC2** — Customer “Optional” RADIUS Servers for MFA.
+ **AWS Directory Services** — AD Connector is deployed into a pair of Amazon VPC private subnets.
+ **Amazon WorkSpaces** — WorkSpaces are deployed into the same private subnets as the AD Connector. For more information, refer to the [Active Directory: Sites and Services](design-considerations.md#active-directory-sites-and-services) section of this document.
## Customer
+ **Optional: Network Connectivity** — Corporate VPN or AWS Direct Connect endpoints.
+ **End user devices** — Corporate or BYOL end-user devices (such as Windows, Macs, iPads, Android tablets, zero clients, and Chromebooks) used to access the Amazon WorkSpaces service. Refer to [this list of client applications for supported devices and web browsers](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client).
Like scenario 2, this scenario doesn’t have issues with reliance on connectivity to the customer on-premises data center, latency, or data out transfer costs (except where internet access is enabled for WorkSpaces within the VPC) because, by design, this is an isolated or cloud-only scenario.
# Scenario 4: AWS Microsoft AD and a two-way transitive trust to on-premises
This scenario, shown in the following figure, has AWS Managed AD deployed in the AWS Cloud, which has a two-way transitive trust to the customer on-premises AD. Users and WorkSpaces are created in the Managed AD, with the AD trust enabling resources to be accessed in the on-premises environment.
![\[Sample architecture showing AWS Managed AD deployed in the AWS Cloud, which has a two-way transitive trust to the customer on-premises AD.\]](http://docs.aws.amazon.com/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/cloud-only-transitive-trust.png)
As in scenario 3, the AD DS (Microsoft AD) is deployed into dedicated subnets that span two AZs, making AD DS highly available in the AWS Cloud.
This scenario works well for customers who want to have a fully managed AWS Directory Service, including deployment, patching, high availability, and monitoring of their AWS Cloud. This scenario also allows WorkSpaces users to access AD-joined resources on their existing networks. This scenario requires a domain trust to be in place. Security groups and firewall rules need to allow communication between the two active directories.
In addition to the placement of AWS Directory Service, the previous figure oulines the flow of traffic from a user to a workspace, and how the workspace interacts with the AD server and MFA server.
This architecture uses the following components or construct.
## AWS
+ **Amazon VPC** — Creation of an Amazon VPC with at least four private subnets across two AZs — two for AD DS [Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html), two for AD Connector or WorkSpaces.
+ **DHCP options set** — Creation of an Amazon VPC DHCP options set. This enables a customer to define a specified domain name and DNS (Microsoft AD). For more information, refer to [DHCP options sets](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html).
+ **Optional: Amazon virtual private gateway** — Enable communication with a customer-owned network over an IPsec VPN tunnel (VPN) or AWS Direct Connect connection. Use for accessing on-premises back-end systems.
+ **AWS Directory Service** — Microsoft AD deployed into a dedicated pair of VPC subnets (AD DS Managed Service).
+ **Amazon EC2** — Customer *optional* RADIUS Servers for MFA.
+ **Amazon WorkSpaces** — WorkSpaces are deployed into the same private subnets as the AD Connector. For more information, refer to the [Active Directory: Sites and Services](design-considerations.md#active-directory-sites-and-services) section of this document.
## Customer
+ **Network Connectivity** — Corporate VPN or AWS Direct Connect endpoints.
+ **End user devices** — Corporate or BYOL end-user devices (such as Windows, Macs, iPads, Android tablets, zero clients, and Chromebooks) used to access the Amazon WorkSpaces service. Refer to the [list of client applications for supported devices and web browsers](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client).
This solution requires connectivity to the customer on-premises data center to allow the trust process to operate. If WorkSpaces users are using resources on the on-premises network, then latency and outbound data transfer costs need to be considered.
# Scenario 5: AWS Microsoft AD using a shared services Virtual Private Cloud (VPC)
This scenario, shown in the following figure, has an AWS Managed AD deployed in the AWS Cloud, providing authentication services for workloads that are either already hosted in AWS or are planned to be as part of a broader migration. The best practice recommendation is to have Amazon WorkSpaces in a dedicated VPC. Customers should also create a specific AD OU to organize the WorkSpaces computer objects.
To deploy WorkSpaces with a shared services VPC hosting Managed AD, deploy an AD Connector (ADC) with an ADC service account created in the Managed AD. The service account requires permissions to create computer objects in the WorkSpaces designated OU in the shared services Managed AD.
![\[Sample architecture showing a WorkSpaces with a shared services VPC hosting Managed AD, deploy an AD Connector.\]](http://docs.aws.amazon.com/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/microsoft-ad-shared-services-vpc.png)
This architecture uses the following components or constructs.
## AWS
+ **Amazon VPC** — Creation of an Amazon VPC with at least two private subnets across two AZs (two for AD Connector and WorkSpaces).
+ **DHCP options set** — Creation of an Amazon VPC DHCP options set. This allows a customer to define a specified domain name and DNS (Microsoft AD). For more information, refer to [DHCP options sets](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html).
+ **Optional: Amazon virtual private gateway** — Enable communication with a customer-owned network over an IPsec VPN tunnel (VPN) or AWS Direct Connect connection. Use for accessing on-premises back-end systems.
+ **AWS Directory Service** — Microsoft AD deployed into a dedicated pair of VPC subnets (AD DS Managed Service), AD Connector
+ **AWS Transit Gateway/VPC Peering** — Enable connectivity between Workspaces VPC and the Shared Services VPC
+ **Amazon EC2** — Customer *optional* RADIUS Servers for MFA.
+ **Amazon WorkSpaces** — WorkSpaces are deployed into the same private subnets as the AD Connector. For more information, refer to the [Active Directory: Sites and Services](design-considerations.md#active-directory-sites-and-services) section of this document.
## Customer
+ **Network Connectivity** — Corporate VPN or AWS Direct Connect endpoints.
+ **End user devices** — Corporate or BYOL end-user devices (such as Windows, Macs, iPads, Android tablets, zero clients, and Chromebooks) used to access the Amazon WorkSpaces service. Refer to the [list of client applications for supported devices and web browsers](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client).
# Scenario 6: AWS Microsoft AD, shared services VPC, and a one-way trust to on-premises
This scenario, as shown in the following figure, uses an existing on-premises Active Directory for users, and introduces a separate Managed Active Directory in AWS Cloud to host the computer objects associated with the WorkSpaces. This scenario allows the computer objects and Active Directory group policies to be managed independently from the corporate Active Directory.
This scenario is useful when a third party wants to manage Windows WorkSpaces on a customer’s behalf as it allows the third party to define and control the WorkSpaces and policies associated with them, without a need to grant the third-party access to the customer AD. In this scenario, a specific Active Directory organizational unit (OU) is created to organize the WorkSpaces computer objects in the Shared Services AD.
**Note**
Amazon Linux WorkSpaces require a two-way trust to be in place for them to be created.
To deploy Windows WorkSpaces with the computer objects created in the Shared Services VPC hosting Managed Active Directory using users from the customer identity domain, deploy an Active Directory Connector (ADC) referencing the corporate AD. Use an ADC service account created in the corporate AD (identity domain) that has delegated permissions to create computer objects in the Organizational Unit (OU) that was configured for the Windows WorkSpaces in the Shared Services Managed AD, and that has read permissions to the corporate Active Directory (identity domain).
To ensure the Domain Locator function is able to authenticate WorkSpaces users in the desired AD Site for the identity domain, name both domain’s AD Sites for the Amazon WorkSpaces Subnets identically as per [Microsoft’s documentation](https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/domain-locator-across-a-forest-trust/ba-p/395689). It is a best practice to have both identity domain and Shared Services domain AD Domain Controllers in the same AWS Region as Amazon WorkSpaces.
For detailed instructions to configure this scenario, review the implementation guide to [set up a one-way trust for Amazon WorkSpaces with AWS Directory Services](https://d1.awsstatic.com/Projects/deploy-amazon-workspaces-one-way-trust-with-aws-directory-service.pdf)
In this scenario we establish a one-way transitive trust between the AWS Managed Microsoft AD in the Shared Services VPC and the on-premises AD. Figure 11 shows the direction of trust and access, and how the AWS AD Connector uses the AD Connector service account to create computer objects in the resource domain.
A forest trust is used per Microsoft recommendation to ensure that Kerberos authentication is used whenever possible. Your WorkSpaces receive Group Policy Objects (GPOs) from your resource domain in the AWS Managed Microsoft AD. Furthermore, your WorkSpaces perform Kerberos authentication with your identity domain. For this to work reliably it is best practice to extend your identity domain to AWS as already explained above. We suggest to review the [Deploy Amazon WorkSpaces using a One-Way Trust Resource Domain with Directory Service](https://aws.amazon.com/getting-started/hands-on/deploy-workspaces-one-way-trust/) implementation guide for further detail.
Both, the AD Connector and your WorkSpaces, must be able to communicate with the Domain Controllers of your identity domain and your resource domain. For more information, see [IP address and port requirements for WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/workspaces-port-requirements.html) in the *Amazon WorkSpaces Administration Guide*.
If you use multiple AD Connectors, it is best practice for each of the AD Connectors to use its own AD Connector Service Account.
![\[ASample architecture showing a Windows WorkSpaces with the computer objects created in the Shared Services VPC hosting Managed Active Directory using users from the customer identity domain.\]](http://docs.aws.amazon.com/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/one-way-trust-ad-onprem.png)
This architecture uses the following components or constructs:
## AWS
+ **Amazon VPC** — Creation of an Amazon VPC with at least two private subnets across two AZs — two for AD Connector and WorkSpaces.
+ **DHCP options set** — Creation of an Amazon VPC DHCP options set. This allows a customer to define a specified domain name and DNS (Microsoft AD). For more information, refer to [DHCP options sets](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html).
+ **Optional: Amazon virtual private gateway** — Enable communication with a customer-owned network over an IPsec VPN tunnel (VPN) or AWS Direct Connect connection. Use for accessing on-premises back-end systems.
+ **AWS Directory Service** — Microsoft AD deployed into a dedicated pair of VPC subnets (AD DS Managed Service), AD Connector.
+ **Transit Gateway/VPC Peering** — Enable connectivity between Workspaces VPC and the Shared Services VPC.
+ **Amazon EC2** — Customer “Optional” RADIUS Servers for MFA.
+ **Amazon WorkSpaces** — WorkSpaces are deployed into the same private subnets as the AD Connector. For more information, refer to the [Active Directory: Sites and Services](design-considerations.md#active-directory-sites-and-services) section of this document.
## Customer
+ **Network Connectivity** — Corporate VPN or AWS Direct Connect endpoints.
+ **End user devices** — Corporate or BYOL end-user devices (such as Windows, Macs, iPads, Android tablets, zero clients, and Chromebooks) used to access the Amazon WorkSpaces service. Refer to [this list of client applications for supported devices and web browsers](https://docs.aws.amazon.com/workspaces/latest/userguide/workspaces-user-getting-started.html#choose-client).
# Using multi-Region AWS Managed Active Directory with Amazon WorkSpaces
[AWS Directory Service for Microsoft Active Directory](https://aws.amazon.com/directoryservice/active-directory/) (MAD) is a fully managed Microsoft Active Directory (AD) that can be paired with Amazon WorkSpaces. Customers choose AWS Managed Microsoft AD because it has built-in high availability, monitoring, and backups. AWS Managed Microsoft AD Enterprise edition adds the ability to configure [Multi-Region Replication](https://aws.amazon.com/blogs/aws/multi-region-replication-now-enabled-for-aws-managed-microsoft-active-directory/). This feature automatically configures inter-region networking connectivity, deploys domain controllers, and replicates all the Active Directory data across multiple regions, ensuring that Windows and Linux workloads residing in those regions can connect to and use AWS MAD with low latency and high performance. Replicated MAD regions cannot be [directly registered with WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/register-deregister-directory.html), however a replicated MAD directory can be registered with WorkSpaces by configuring an AD Connector (ADC) to point to your replicated Domain Controllers.
The best practice when deploying AD Connectors with MAD is to create an AD Connector for each business unit within your WorkSpaces environment. This will allow you to align each business unit with a specific Organizational Unit within Active Directory. You can then assign AD Group Policy Objects at the Organization Unit level that directly align with the business unit in question.
## Architecture
![\[Sample architecture showing AD Connectors with MAD is to create an AD Connector for each business unit within your WorkSpaces environment.\]](http://docs.aws.amazon.com/whitepapers/latest/best-practices-deploying-amazon-workspaces/images/registering-replicated-mad-region.png)
## Implementation
To register your replicated MAD region to WorkSpaces, you will need to create an AD Connector pointed to your MAD Domain Controller IPs. You can find your MAD Domain Controller IP addresses by going to the [AWS Directory Service console](https://console.aws.amazon.com/directoryservicev2/) navigation pane, selecting Directories and then choosing the correct directory ID. To create these AD Connectors, follow this [guide](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ad_connector_getting_started.html). Once they are created, you can [register them for WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/register-deregister-directory.html). Before you deploy WorkSpaces in your new region, ensure you have updated your VPCs [DHCP options set.](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/dhcp_options_set.html)