AWS Management & Governance Blog

Extend a self-managed Active Directory to AWS Control Tower

One common use case for customers during the early cloud journey is to use existing identity service such as Microsoft Active Directory. In this blog post, I show you how to setup AWS Control Tower to delegate user authentication to a self-managed Microsoft Active Directory via AWS Managed Microsoft AD. This blog post shows a simulated environment on how to connect your existing on-premises Active Directory to AWS Control Tower.

Background

AWS Control Tower incorporates AWS Single Sign-on (AWS SSO), a cloud-based service that simplifies SSO access in a multi-account environment. Using AWS SSO, the directory connected to AWS Control Tower controls user authentication. Each user’s assigned account access and level of access permissions granted determines authorization.

AWS SSO uses permission sets, which are a collection of administrator-defined policies to determine a user’s effective permissions to access a given AWS account. Permission sets can contain either AWS managed policies or inline policies that are stored in AWS SSO. Policies are essentially documents that act as containers for one or more permission statements. These statements determine what actions users can or cannot perform within the AWS account. Permission sets are stored in AWS SSO and only used for AWS accounts. Permission sets ultimately get created as AWS Identity and Access Management (IAM) roles in a given AWS account. Those roles have trust policies that allow users to assume a role through AWS SSO.

AWS Control Tower is set up with a cloud-native directory as the default identity source in AWS SSO. This directory has pre-configured groups, permission sets, and SSO access.

Solution Overview

For this walkthrough, you must already have a working version of AWS Control Tower. If you don’t, you can configure AWS Control Tower by following Jeff Barr’s walkthrough blog post. To securely connect your AWS environment to your on-premises network, please refer to AWS VPN or AWS Direct Connect.

The following diagram outlines the user authentication flow:

  1. An end user from an external identity source authenticates to an AWS Control Tower managed, multi-account environment via AWS SSO.
  2. AWS Managed Microsoft AD is selected as the identity source within AWS SSO, which delegates the user authentication task to a self-managed Active Directory. This is hosted on an EC2 instance running in a separate public subnet.
  3. AWS Control Tower grants user access to AWS resources based on the permissions set assigned to the user.

The following flowchart shows the six steps I cover in this walkthrough.

  1. Set up a test environment. In this step, you create an AWS CloudFormation stack to set up a test environment that includes the following components:
    • A Virtual Private Cloud (VPC) setup with two public subnets
    • Two domain controllers, each deployed to a separate public subnet
    • An AWS Managed Microsoft AD and a self-managed Active Directory on an Amazon Elastic Compute Cloud (Amazon EC2) instance
  2. Install Active Directory administration tools for managing AWS Managed Microsoft AD and the self-managed Active Directory.
  3. Configure the self-managed Active Directory by creating a native Active Directory forest on a self-managed Active Directory.
  4. Configure VPC outbound rules and DNS conditional forwarders.
  5. Create a multi-forest trust environment.
    • First, you create a trust from self-managed Active Directory to AWS Managed Microsoft AD.
    • Then you create a trust from AWS Managed Microsoft AD to self-managed Active Directory. This allows AWS Managed Microsoft AD to serve as a resource domain. This enables on-premises users to sign in to AWS Services via AWS SSO using their existing corporate credentials.
  6. Configure AWS Control Tower to delegate user authentication to the self-managed Active Directory. First delegate access to users from the self-managed Active Directory and then verify that users (testuser) can authenticate as expected.

Step 1: Set up a test environment

Please reference Amazon VPC Limits to make sure you are not exceeding the default limit before launching the AWS CloudFormation template.

  1. Create a new key pair in the Region where your AWS Control Tower was deployed. At the time of this writing, AWS Control Tower is available in US East (Ohio), Europe (Ireland), US East (N. Virginia), and US West (Oregon).
  2. Choose the following Launch Stack (shown in the following image) to launch a CloudFormation template that set up a test environment in the AWS Control Tower home Region.

.    

    • Set the stack name to AWSControlTowerADStack.
    • Provide a password for the default administrative user. This will be used to logon as MyManaged\Admin later.
    • Select Key Pair that you created in Step 1.1 earlier.
    • Keep other fields as default. Select Next twice. Choose I acknowledge that AWS CloudFormation might create IAM resources with custom names. Select Create stack. The CloudFormation stack takes approximately one hour to deploy the required resources. Allow deployment to complete successfully before proceeding to Step 2: Install Active Directory administration tools.

Step 2: Install Active Directory administration tools

  1. In the Amazon EC2 console, follow the steps to connect to corp.example.com-mgmt instance.
  2. From the Start menu, choose Server Manager, and then select Add Roles and Features. Choose Next.
  3. On the Select installation type page, choose Role-based or feature-based installation. Choose Next twice.
  4. On the Select features page, do the following:
    • Select Group Policy Management.
    • Expand Remote Server Administration Tools. Then expand Role Administration Tools. Select AD DS and AD LDS Tools and DNS Server Tools. Choose Next and Install.

Sign out and follow these steps below to verify your MyManagedAD.corp.example.com domain is operational:

  1. Connect to corp.example.com-mgmt EC2 instance. Log in as MyManagedAD\Admin with the password provided in your CloudFormation stack in step 2 of Step 1: Set up a test environment.
  2. In the Start menu, under Windows Administrative Tools, choose Active Directory Users and Computers.
  3. Expand MyManagedAD.corp.example.com, and notice two domain controllers were automatically created as part of AWS Managed Microsoft AD provisioning. Refer to the following screenshot. Sign out from corp.example.com-mgmt.

Step 3: Configure the self-managed Active Directory

In this section, you create a new Active Directory forest and configure self-managed Active Directory to use local DNS server for name resolution.

Install Active Directory Domain Services

  1. In your Amazon EC2 console, connect to example.local-DC.
  2. From the Start menu, choose Server Manager, and then Add Roles and Features. Choose Next.
  3. On the Select installation type page, choose Role-based or feature-based installation. Choose Next twice.
  4. On the Select server roles page, select Active Directory Domain Services. Verify that the Include management tools (if applicable) is selected. Choose Add Features. Choose Next twice and select Install.

Configure Active Directory Domain Services

  1. When Server Manager opens, look for a flag at the top next to the word Manage. Under the yellow flag, choose Promote this server to a domain controller.
  2. On the Deployment Configuration page, choose Add a new forest. Enter example.local as Root domain name and choose Next.
  3. On the Domain Controller Options page, do the following:
    • Choose Windows Server 2016 for both Forest functional level and Domain functional level.
    • For Specify domain controller capabilities, verify both Domain Name System (DNS) server and Global Catalog (GC) are selected.
    • Enter a Directory Services Restore Mode (DSRM) password. Choose Next twice.
  4. On the Additional options page, verify EXAMPLE as the NetBios domain name. Choose Next three times. The server now validates prerequisites for your domain controller.
  5. Choose Install. The server reboots once the installation completes. At that time, it becomes a functional domain controller.

Step 4: Configure VPC outbound rules and DNS forwarder

Configure VPC outbound rules

  1. In the AWS Directory Service console, navigate to Directories and select the radio button for MyManagedAD.corp.example.com. Make a note of your directory ID for MyManagedAD.corp.example.com, as shown in the following screenshot.
  2. In the Amazon VPC console left sidebar, select Security Groups. At the top, paste the Directory ID that you copied in the previous step into the search bar. This security group was automatically created as part of initial AWS Managed Microsoft AD provisioning.
  3. Choose the Outbound Rules tab, and then select Edit. Choose Add another rule, then add following values:
    • For Type, choose All Traffic.
    • For Destination, enter 0.0.0.0/0.
  4. Choose Save.

Configure DNS conditional forwarder

  1. In the AWS Directory Service console, select MyManagedAD.corp.example.com, and then locate and make a note of both DNS addresses. Refer to the following screenshot.
  2. Return to the example.local-DC domain controller, and then open Server Manager. In the Tools menu, choose DNS.
  3. Expand DNS server. Navigate to Conditional Forwarders. Right click that and choose New Conditional Forwarder. In DNS domain, enter MyManagedAD.corp.example.com.
  4. In IP addresses of the master servers, choose <Click here to add …> and enter the first DNS address you noted in this section. Select Enter. Repeat this step for the second DNS address.
  5. To the left of Store this conditional forwarder in Active Directory, and replicate as follows, select the checkbox. Choose All DNS servers in this Forest, and then choose OK, as shown in the following screenshot.

Create a user in the self-managed Active Directory

  1. In example.local-DC domain controller, navigate to Server Manager, and then Tools in the top right menu, select Active Directory Users and Computers. Expand example.local and right click Users to create a new user called testuser.
  2. Provide a password for testuser.

Step 5: Create a multi-forest trust environment

Create a trust from self-managed Active Directory to AWS Managed Microsoft AD

  1. While still connected to example.local-DC, open Server Manager and choose DNS. Take note of the IPv4 address listed for DNS server. You will use this to create a conditional forwarder from MyManagedAD.corp.example.com to example.local directory on self-managed Active Directory. Refer to the following screenshot.
  2. In Tools, choose Active Directory Domains and Trusts. Right-click example.local and choose Properties. Do the following:
    • On the Trusts tab, choose New Trust.
    • On the Trust Name page, enter MyManagedAD.corp.example.com.
    • On the Trust Type page, choose Forest trust.
    • On the Direction of Trust page, choose Two-way.
    • On the Sides of Trust page, choose This domain only.
    • On the Outgoing Trust Authentication Level page, choose Forest-wide authentication.
    • On the Trust Password page, enter your trust password twice. Select Next three times. Choose Finish and OK.

Create a trust from AWS Managed Microsoft AD to self-managed Active Directory

  1. In the AWS Directory Service console, select your MyManagedAD.corp.example.com directory. Choose the Networking & security tab.
  2. In the Trust relationships section, choose Actions, and then select Add trust relationship. Refer to the following screenshot.
  3. In Add a trust relationship, enter the following:
    • In Trust type, select Forest trust.
    • For Remote domain name, enter example.local.
    • For Trust password, enter the password you have created in step 9 of Create a trust from self-managed Active Directory to AWS Managed Microsoft AD.
    • In Trust direction, select Two-way.
    • In Conditional forwarder, enter the IP address of the DNS server that you noted in step 1 of Create a trust from self-managed Active Directory to AWS Managed Microsoft AD.
    • Choose Add. Refer to the following screenshot.
  4. The trust verification process takes approximately 15 minutes. Once trust verification completes, the Status column should display Verified. Refer to the following screenshot.

A fully-functional, multi-forest Active Directory environment is now available.

Step 6: Configure AWS Control Tower to delegate user authentication to a self-managed Active Directory

In this section, you configure AWS Control Tower to delegate user authentication to a self-managed Active Directory.

  1. In the AWS Control Tower console, navigate to Users and access. On the right, choose View in AWS Single Sign-On.
  2. Select Choose your identity source. Select Change of Identity source. Select Active Directory. Under Existing directories in US East (N. Virginia) Region, choose MyManagedAD.corp.example.com. Select Next.
  3. Enter CONFIRM in the box. Choose Finish.
  4. Self-managed Active Directory is now used as the default identity source for AWS Control Tower via trust delegation by AWS Managed Microsoft AD.

Delegate access to users from the self-managed Active Directory

  1. Return to the AWS Single Sign-On page, select AWS accounts, select Log archive, and then choose Assign users.
  2. In the drop-down menu select example.local. Choose Users. Enter testuser in the search field. Choose Next: Permission sets.
  3. Select AWSReadOnlyAccess. Choose Finish.

Verify that testuser can authenticate

  1. In the AWS SSO console, at the bottom, copy the AWS SSO User portal URL. Refer to the following screenshot.
  2. Paste the URL into a new browser tab. Login as testuser using the password you created in step 2 of Create a testuser in the self-managed Active Directory. You as testuser have read-only access to the Log archive account.

Cleaning up

To avoid incurring future charges, you can remove example resources by deleting the AWSControlTowerADStack CloudFormation stack from the CloudFormation console or run the following AWS Command Line Interface (AWS CLI) command:

aws cloudformation delete-stack –stack-name AWSControlTowerADStack

Conclusion

In this blog post, I showed how to extend a self-managed Active Directory to AWS Control Tower. Now you can manage how your on-premises users access AWS resources within a multi-account environment using their corporate credentials.

About the author

Cher Simon is a Senior Technical Account Manager at AWS. Cher enjoys working with AWS customers in solving architectural, operational, and cost optimization challenges.