Deploy Amazon WorkSpaces using a One-Way Trust Resource Domain with AWS Directory Service
Learn how to set up separate identity and resource Active Directory domains
Introduction
Amazon WorkSpaces can be integrated with a range of Active Directory Service configuration scenarios. This guide walks you through the process of deploying Amazon WorkSpaces in a one-way trust domain environment with an account and a resource domain configuration. An account/resource configuration consists of two Microsoft Active Directories with a configured Active Directory Trust.
An account domain is an Active Directory domain set up to manage user accounts. A resource domain is used to enhance security, or make the Active Directory structure more logical or manageable. There are Active Directory deployments in which all desktop, or desktop-as-a-service, computers are grouped into a dedicated resource domain. Resource domains are useful when you treat them as management domains.
A one-way trust is a unidirectional authentication path created between two domains (trust flows in one direction, and access flows in the other). With a one-way trust relationship, the Resource domain (trusting) makes its resources available to users in the Account domain (trusted). This means that in a one-way trust between a trusted domain and a trusting domain, users or computers in the trusted domain can access resources in the trusting domain. However, users in the trusting domain cannot access resources in the trusted domain.
Consider the following scenarios which benefit from using account and resource domains with configured trusts:
Isolating resources for external management: This scenario allows users to maintain their Active Directory (AD) credentials. For example, customers can work with a Partner organization to manage their Amazon Work Spaces using AD Group Policies; while not relinquishing control or granting access into the corporate AD account domain.
As an additional example, customers can extend access to their partner managed resources, and have contractors or external providers have user accounts in their resource domain. This configuration allows collaboration while reducing the security impact of allowing third party access to the corporate account domain.
Isolating resources for collaborative projects or short term projects: This scenario allows users to isolate resources in a separate Active Directory that can have a different level of security controls than their existing account domain.
Customers can create new Active Directory user accounts for collaborative projects. The associated AD Computer Objects can be isolated from existing Group Policy
Objects (GPOs) linked to the Organizational Units (OUs), and domain policies linked with the default account domain. This can reduce the potential impact of entangling GPO policies for divestitures, or other short term projects.
The following sections provide details about how to configure Account and Resource domains with Amazon Work Spaces, explain show the Active Directory Connectors are set, and describes design considerations when selecting one-way or two-trusts.
What you will accomplish
In this tutorial, you will:
- This section will walk you through the process a setting up a one-way transitive Active Directory trust for Amazon WorkSpaces.
Architecture
This deployment configures a trust relationship between two Active Directory domains. In the following example configuration, the account domain is hosted in the customer’s corporate data center. The Amazon WorkSpaces are managed within a separate Active Directory, with users authenticating using their corporate AD credentials.
Prerequisites
You must have the following components configured to complete this tutorial:
- AWS Account
- Active Directory (Identity Domain)
- ActiveDirectory (Resource Domain)(Computer objects) such as AWS Directory Service
- Network connectivity between domains:
- The following ports need to be open between domains:
| Protocol | Port range |
| UDP | 445 |
| UDP | 389 |
| UDP | 88 |
| UDP | 123 |
| UDP | 53 |
| TCP | 636 |
| TCP | 3389 |
| TCP | 445 |
| TCP | 389 |
| TCP | 135 |
| TCP | 49152 - 65535 |
| TCP | 53 |
| TCP | 88 |
- Active Directory Conditional Forwarder
- Determine AWS Region for Amazon WorkSpaces deployment (same as MAD). Note: Amazon WorkSpaces service is available in select AWS Regions; verify region availability before deployment.
AWS experience
Intermediate
Time to complete
20 minutes
Cost to complete
Less than $1
Requires
AWS Account
Services used
Amazon WorkSpaces
AWS Directory Service
Last updated
Dec 14, 2023
Implementation
Step 1: Configure Conditional Forwarders to Each Domain
- On the Microsoft Windows Domain Controller, open DNS Manager (Windows Key >Windows Administrative Tools > DNS).
- Right-click Conditional Forwarder and choose New Conditional Forwarder.
- Enterthe DNS Domain Name and the IP Address of the DNS server in the Identity Domain.
- Click OK.
- Repeat steps 1 through 4 for the Identity Domain. Set the Conditional Forwarder IP Address to the Resource Domain for Step 3.
Step 2: Configure Active Directory Domains and Trusts
In this step, you establish a one-way incoming trust from the Resource Domain to the Identity Domain.
- In the Identity Domain, open Active Directory Domains and Trusts.
- Right-click the domain and choose Properties.
- Choose the Trusts tab, then choose New Trust.
- In the New Trust Wizard, choose Next.
- Enter the name of the resource domain(e.g. rdomain.infra) and choose Next.
- For Trust Type, select External Trust and choose Next.
- On the Direct of Trust page, select One-Way:Incoming and choose Next.
- On the Sides of Trust page, select This domain only and choose Next.
- Enter the service account and password that will be used for the One-Way incoming Trust and choose Next.
- On the Trust Authentication page, select Forest-wide authentication and choose Next.
- Choose Next.
- On the Trust Creation Complete page, choose Next.
- Choose No, do not confirm the incoming trust and choose Next.
- Completing the New Trust Wizard page, choose Finish.
You should now see a One-Way Trust listed on the Trust properties tab for each domain.
Step 3: Configure the AD Connector
- Open the AWS Directory Service console and in the navigation pane, choose
Directories and then choose Set up Directory.
- On the Select directory type page, choose AD Connector, and then choose Next.
- Choose AD Connector and choose Next.
- On the Enter AD Connector information page, provide the following information:
- Directory size: Small
- Directory description: WorkSpaces Lab ADC
- On the Choose VPC and subnets page, provide the following information and choose Next:
- VPC: Select the same VPC that you use for WorkSpaces
- Subnets: Choose the subnets for the domain controllers. These two subnets must be in different Availability Zones.
- On the Connect to AD page, enter the Active Directory information for the Identity Domain. Then, choose Next.
- On the Review & create page, review the directory information and choose Create directory.
- Once the AD Connector status changes to Active, select the directory and choose Actions, Register.
- Select two subnets in two different availability zones. Select the preferred configuration options then choose Register.
Step 4: Create the Computer Object in the Resource Domain
- Open the WorkSpaces console and in the navigation pane, choose Directories.
- Select the directory you created in Step 3 and choose Actions, then Update Details.
- Expand Target Domain and Organizational Unit and choose List all OU. The OU selected for WorkSpaces Users during the AD Connector creation is listed.
- In the Selected OU field, insert the Canonical Name of the OU that will be used for the WorkSpaces Computer Objects. The following example shows an OU for Amazon WorkSpaces Active Directory Computer Objects that will be created in the resource domain.
- Choose Update and Exit.
- In Active directory of the Resource domain, Right click on the workspaces OU and choose Delegate Control. Click on other locations and choose the identity domain
- Enter the connector service account details
- Perform the delegation as per the article : https://docs.aws.amazon.com/whitepapers/latest/access-workspaces-with-accesscards/create-a-service-account-and-delegate-privileges.html
Step 5: Test Launch a WorkSpace
- In the WorkSpaces console choose WorkSpaces.
- Choose Launch WorkSpaces
- On the Select a Directory page, choose the Identity Domain and then choose
Next Step.
- On the Identify Users page, choose Show All Users. Select the User(s) from the Identity Domain list and choose Add Selected. Then, choose Next Step.
For Bundle, select Standard with Windows 10 (PCoIP) or Performance with Windows 10 (PCoIP).
- Under the Assign WorkSpace Bundles, adjust the User Volume to 10GB and choose Next Step.
- Choose the running mode, choose the encryption settings, and configure any tags. When you are finished, choose Next Step.
- Choose Launch WorkSpaces.
Note that it can take up to 20 minutes for the WorkSpaces to become available. The initial status of the WorkSpace is PENDING. When the launch is complete, the status is AVAILABLE. After the test WorkSpaces have been deployed you will see newly created Computer Objects in the Resource Domain OU.
- Repeat steps 1 – 8 to deploy a second Amazon WorkSpace (Standard or Performance) if desired.
Step 6: Clean up resources
After completing this tutorial, you can keep your configuration running or clean up all resources. For pricing details on this configuration, see Estimate Your Costs. To delete the AWS resources that you created so that you no longer accrue charges, complete these steps:
- Shut down and terminate any launched Amazon WorkSpaces.
- Unregister the AD Connector.
- Delete the AD Connector.
- Delete the AWS Directory Service for Microsoft Active Directory instance.
Conclusion
In this tutorial, you created a separate identity and resource Active Directory domains using a one-way domain trust. You configured AWS Directory Service for Microsoft Active Directory to integrate into that environment and ensure that user accounts available from the account domain. Computer objects were deployed and manageable from the resource domain.