Leverage a one-way trust with Amazon WorkSpaces for cross-domain usage

In this blog, I will be covering how to set up a resource domain configuration for Amazon WorkSpaces using a one-way trust in Microsoft Active Directory. With this configuration you will deploy your Amazon WorkSpaces compute resources in one domain, while leveraging users from your trusted domain to log onto the Workspace. This is useful when you have access to deploy new resources in one domain, but no access to deploy resources in the domain where the user accounts exist.

Introduction

Amazon WorkSpaces is a fully managed virtual desktop infrastructure (VDI) service that allows you to integrate with Active Directory for user authentication. Amazon WorkSpaces integrates with either AWS Managed Active Directory or your own self-managed AD environment leveraging the AWS Directory Services AD Connector. This blog covers a specific situation where your resource forest is needing to host Amazon Workspaces compute resources, but user accounts are in your organizational AD across a one-way trust. I will guide you through a solution to deploy compute resources in the resource forest that you manage, while allowing users from the organizational forest to log in.

It is also possible to implement this solution using a two-way trust. You would leverage a one-way trust when you don’t want users from your resource forest (AD forest with just computer objects and service accounts) to authenticate to your organization forest (AD forest with corporate users and other objects). But if you needed users from both forests to authenticate to resources in each domain, you can leverage a two-way trust.

Solution

The implementation will look like Figure 1 in the end with two separate AD environments connected via a one-way trust. This allows you to place computer objects in one domain and user objects in the other. Doing this is handy if you want to offer your customers a managed desktop in the AWS Cloud where you control the devices, but your customers can log onto the systems with their existing user credentials. This allows you to centralize costs for your WorkSpaces and build your own charge back model for the services as needed.

In Figure 1, we see the WorkSpaces VPC with an AD Connector setup for WorkSpaces as the directory. This illustrates one example configuration with Managed AD as the resource forest with a trust connected to your corporate data center hosted organizational forest. The AD connector service account provides access to both the resource forest and the organizational forest.

Figure 1 – Solution diagram showing Amazon WorkSpaces implementation and AD one-way trust.

Prerequisites

• AD Environment with one-way trust.
• Organizational Unit (OU) in the resource forest for WorkSpaces computer objects.
• AD service account (user) in the organizational forest.
• A service account with delegated permissions for the OU in the resource forest.
• Active Directory Users and Computers console on a Windows machine for domain management.
• Amazon Web Services (AWS) console access for WorkSpaces and directories.

If you are not already using a one-way trust, you should follow these instructions provided in Creating a trust relationship.

The service account that allows domain join permissions in your domain also needs delegated access to your resource forest OU. You should review these instructions, Delegate directory join privileges for AWS Managed Microsoft AD.

You will need an OU in the resource forest for the compute resources to be deployed and a service account in the organizational forest that has permission to add computers to the resource forest’s defined OU by following the guide, Delegating Administration by Using OU Objects

You only need the Active Directory Users and Computers admin console so you can find the distinguished name of the OU.

You will also need a user in your AWS console that has permissions to deploy WorkSpaces and configure directories in AWS Directory Service and the WorkSpaces service.

Walkthrough

In this section, I will walk you through the configuration in Amazon WorkSpaces and AWS Directory Service to take advantage of your one-way trust. This will allow you to place your compute resources in your resource forest, and assign users from your trusted AD where all of your users exist (organizational forest).

Step 1 – Configure your AD Connector

1. Open AWS Directory Service console in the navigation pane, choose Directories and then choose Set up directory.
2. On Select directory type, choose AD Connector and select
3. On Enter AD Connector information, provide the following information and select Next:
   1. Directory size: Small
   2. Directory description: WorkSpaces Domain (Name this whatever makes sense to you)
4. On Choose VPC and subnets, provide the following information and select Next:
   1. VPC: Select the same VPC you use for WorkSpaces (this can be the same or different from where your domain controllers are, just ensure there is network connectivity)
   2. Subnets: Choose the subnets for the AD Connector to use. (These two subnets must be in different Availability Zones.)
5. On Connect to AD, enter the AD information for the organizational forest and select Next:
   1. Directory DNS Name (FQDN of your AD)
   2. Directory NetBIOS name
   3. DNS IP Addresses (IP addresses of your existing AD domain)
   4. Service account username (Service account which you created to allow domain joins in your resource forest from the prerequisites)
   5. Service account password (Password for service account)
   6. Confirm password (Re-enter the service account password)
6. On Review & create, review the directory information and select Create directory.
7. Once the AD Connector status changes to Active, switch to the Amazon WorkSpaces Console. 

Step 2 – Register AD Connector in Amazon WorkSpaces

1. In Amazon WorkSpaces console, locate the Directories option under the WorkSpaces menu.
2. Select the radio button next to your newly created AD Connector.
3. Go to the Actions option and select
4. On the next screen select subnets where you will deploy your Amazon Workspaces (must be two unique subnets).
5. Once the directory state changes to True (Figure 3), you can modify its configuration to target the resource forest OU for compute objects.

Once the steps above are completed you can look at figure 2 which details the configuration in the AWS console of the directory id, directory name and directory type, with the registered parameter set to true.

Figure 2 WorkSpaces console personal directories with registered directory

Step 3 – Modify your AD Connector

1. From WorkSpaces directories, select the Directory ID of the newly registered AD Connector to see additional details.
2. In the details view scroll down and select Edit in the Target domain and organizational unit section.
3. Go to your administration server with Active Directory Users and Computers installed.
   1. In the resource forest, where your computer objects will be stored, find the OU where you plan to keep resources.
   2. Select the OU and see the attributes. You need to copy the full distinguished name of the OU (e.g. OU=WorkSpaces,DC=resource,DC=example,DC=com). (see Figure 3 for example screenshot of configured OU distinguished name targeting resource forest OU)
4. Paste the OU name into the text field below the OU distinguished name and select Save.

Figure 3 Edited target domain and organization unit with compute resource domain as target

With the previous configuration items, we have created an AD connector for our organizational forest AD domain and targeted the resource forest for the compute resources. With this configuration we can now launch an Amazon WorkSpaces desktop in one domain, while selecting a user from another domain.

Step 4 – Launch and Amazon WorkSpaces

1. Open Amazon WorkSpaces Console and select Personal from the options under WorkSpaces.
2. Select Create WorkSpaces
3. On the next screen under Onboarding options leave the default setting.
4. Leave the Yes – persistent (WorkSpaces personal)
5. Under What will your users use the workSpaces for? Select an option for your use case, for this blog we will choose General – Web browsing.
6. Under What operating system do your users need? Select Windows and select Next.

Once the WorkSpaces creation is complete, you will have an Amazon WorkSpaces personal desktop that you can log onto with users across the one-way trust. Instructions on how to connect to WorkSpaces and other helpful info at Amazon WorkSpaces quick setup.

Cleanup

If this is your primary environment and you have followed the steps in this blog, you have nothing to cleanup for this solution as you now have a working WorkSpaces deployment. If this was a test run for your production environment, you will want to delete the AD Connector created and any Amazon WorkSpaces launched for testing. The AD Connectors and WorkSpaces incur a cost, so it is best to delete them if they are no longer needed.

Conclusion

In this blog, I walked you through how to use a one-way trust in AD with Amazon WorkSpaces to control the compute resources in one domain, while using AD users from another domain for accessing your WorkSpaces virtual desktops. This allows users to access resources in one domain without migrating users to another domain.

AWS has significantly more services, and more features within those services, than any other cloud provider, making it faster, easier, and more cost effective to move your existing applications to the cloud and build nearly anything you can imagine. Give your Microsoft applications the infrastructure they need to drive the business outcomes you want. Visit our .NET on AWS and AWS Database blogs for additional guidance and options for your Microsoft workloads. Contact us to start your migration and modernization journey today.