Field Notes: Designing Multi-Region AWS Managed Microsoft Active Directory for Hybrid Environments

Previously, customers with large and complex Microsoft Active Directory deployments across geographies faced challenges when migrating their on-premises Active Directory to AWS. Integrating with AWS Managed Microsoft Active Directory also proved difficult.

The AWS Managed Microsoft Active Directory Multi-Region feature that was released last year simplifies global deployment for these customers and mitigates their migration pain points. Customers are asking how to design and architect a hybrid Active Directory on AWS Managed Microsoft Active Directory with the new Multi-Region feature.

In this article, we cover designing AWS Managed Microsoft Active Directory by spanning across multiple Regions, and a Domain Name Service (DNS) architecture. The main benefit in doing so is when new AWS services are joined to AWS Managed Microsoft Active Directory, you can use your domain credentials to access them.

Walkthrough

The following architecture diagram (Figure 1) displays two corporate data centers that are geographically separated, each data center has Microsoft Active Directory Domain controllers. There is a forest name that is shared but both have independent child domains.

Both data centers are connected to AWS via their own AWS Direct Connect. This is then connected to an AWS Transit Gateway in each AWS Region. Transit Gateway peering is established allowing for interconnectivity between the AWS Virtual Private Clouds (VPCs).

This simplifies your network and puts an end to complex peering relationships. If you only have a single VPC in each Region then you could replace Transit Gateway with VPC Peering instead as it is a cost-effective networking solution.

Each VPC is split across two Availability Zones (AZs) with one public subnet and two private subnets in each AZ. A NAT Gateway is provisioned in the public subnet and the domain controllers for each corporate data center are replicated into the private subnet. AWS Managed Microsoft Active Directory is also deployed in this private subnet and connected via a trust to the replicated domain controllers. Finally, in the second private subnet there are Amazon Elastic Compute Cloud (EC2) instances deployed.

From a Domain Name perspective, the customer is using customer.com as the forest name while sg.customer.com and eu.customer.com are being used as child domains.

We recommend running root domain controllers in both Regions and domain controllers for child domains in their respective Regions. Once AWS Managed Active Directory is setup, we establish a one-way forest trust to the root domain. Since we are creating a transitive trust type, child domains are automatically trusted with AWS Managed Microsoft Active Directory.  Use child domains credentials are also provided to access AWS resources.

Figure 1 – Solution Architecture illustrating the Multi-Region architecture connected via Transit Gateway

Connectivity

Before we provision EC2 instances, and AWS Managed Microsoft Active Directory, we provision the underlining interconnectivity between two AWS Regions.

• First, you need to provision two AWS Transit Gateways, one in each Region.
• Next, attach your VPCs to their respective Transit Gateways.
• Now, add routes between the Transit Gateways and your VPCs.
• Finally, you can perform peering between the two Transit Gateways.

As mentioned previously, if you only have one VPC in each Region consider leveraging VPC peering. In order to route traffic flowing from subnets in both VPC, you configure route tables as illustrated in Figure 2.

Figure 2 – Network Architecture outlines the route tables and Transit Gateway peering used to establish inter-region connectivity within AWS

Deploy AWS Managed Microsoft Active Directory across Multiple Regions

First, we need to create a new Enterprise Edition directory. If you already have an existing Enterprise Edition directory, you can also enable the Multi-Region feature.

Remember that the Enterprise Edition is the only edition that supports Multi-Region replication. In our case, we create a new directory aws.local. To differentiate from the Internet domain, we use “.local”. When creating the new directory you need to ensure that the Fully Qualified Domain Name (FQDN) and NetBIOS name used in AWS Managed Microsoft Active Directory cannot be as same as the on-premises domain.

As we are creating the directory in the eu-west-1 Region, it becomes our primary Region. Once the domain controllers in the primary Region are up and running, you can add additional Regions under the Multi-Region replication section.

Figure 3 – AWS Regions where AWS Managed Microsoft Active Directory have been deployed

Figure 4 – A list of AWS Managed Microsoft Active Directories, specifically highlighting which one has Multi-Region enabled

Site Links

A site link is used to bridge two or more sites, and  enables transitivity between sites. The Knowledge Consistency Checker (KCC) is used to compute the cost of replication between sites in one site link and sites in the other site.

To control the replication flow in our customer’s environment, we created site links between the Active Directory site in AWS and on-premises as indicated in Figure 5. To optimize replication flow, there is no direct replication between on-prem-sg and eu-west-1-on-prem site. Site Link in Managed Active Directory was created during the directory provisioning and is not necessary to manually create them. However it is recommended to update a site with the same name as the nearest customer Active Directory Site Name.

Therefore, when a client is looking for a customer’s Domain Controller (DC), it will always pick up the DC in a site that matches the client’s site in AWS Managed Microsoft Active Directory. Figure 5 illustrates how Active Directory sites and site links are logically created in our environment.

Figure 5 – Site links between the customer’s Active Directory sites and independent site link for AWS Managed Microsoft Active Directory

Both the eu-site and sg-site for the customer’s domain can be seen in the Active Directory Site and Services.

Figure 6 -Active Directory Sites and Services displays the Active Directory Domain Controllers in each Region.

DNS Design

DNS resolution plays a very important role in a hybrid Active Directory deployment. Before we can create a forest trust, we need to ensure that name resolution is working.

We configure a typical conditional forwarder in the customer’s domain to forward DNS requests from the on-premises network to AWS Managed Microsoft Active Directory.

Figure 7 – DNS Manager with Conditional Forwarders for aws.local domain

We can verify DNS resolution by running the Resolve-DnsName command. The results display successful name resolution to four provisioned AWS Managed Microsoft Active Directory instances.

Figure 8 – Resolution of DNS query in Powershell for AWS Managed Microsoft Active Directory aws.local domain

In AWS, we leverage both the conditional forwarder and Amazon Route53. We configure the conditional forwarder in AWS Managed Microsoft Active Directory. This is required to establish the forest trust between the existing forest and the new AWS Managed Microsoft Active Directory forest. We will go into more details about this in the trust relationship section.

First, let’s create the Route53 resolver to automatically answer DNS queries for the customer domain. This is so that the newly provisioned EC2 instances will use the Resolver created as an outbound endpoint to send DNS query.

To forward selected queries such as customer.com, sg.customer.com and eu.customer.com, we create a Resolver rule that allows us to forward the query to the IP address of customer’s DNS server.

For all other domain names that do not match configured in Resolver Rule, the Resolver performs recursive lookups against public name servers. Figure 9 illustrates the DNS query flow originated from EC2 instances.

Figure 9 – Demonstrates the DNS resolution from an EC2 instance in a private subnet via Amazon Route 53 Resolver and outbound Elastic Network Interfaces. This sends the DNS query to the customer’s domain controller running on EC2.

As shown in Figure 10, the two IP addresses are outbound Elastic Network Interface (ENI) addresses. We have created a rule to forward queries for customer.com domain name to the customer’s DNS server.

Figure 10 – Outbound endpoint displaying the two Elastic Network Interface IP Addresses and the conditional forwarding rule.

Now we can use PowerShell to see if the customer’s domain name can be resolved by DNS servers.

Figure 11 – Resolution of DNS query in Powershell for the customer.com domain

Trust Relationship

Once DNS resolution is confirmed, one-way forest trust can be established between AWS Managed Microsoft Active Directory and the customer’s root domain (customer.local). Figure 12 illustrates the trusts types between the customer’s forest and AWS Managed Microsoft Active Directory.

Building a forest trust from AWS Managed Microsoft Active Directory (aws.local) to the root domain(customer.com), means resources in aws.local domain can be accessed using credentials from sg.customer.com and eu.customer.com. This is because both domains have transitive trust to the root domain.

Figure 12 – The customers root domain of customer.com has a parent-child trust to each of the child domains, sg.customer.com and eu.customer.com. The root domain has a one-way forest trust to the AWS Managed Microsoft Active Directory aws.local domain.

Trust relationships from AWS Managed Microsoft Active Directory can be created from the primary Region which is eu-west-1 in our case. Otherwise, the option to add a trust is disabled and a message “Inherited from primary Region” is shown.

Figure 13 – Creation of trusts from secondary Region in AWS Managed Microsoft Active Directory

From the primary Region, we create a trust relationship to the customer’s root domain. This provides necessary information including the DNS server address of the customer’s domain as a conditional forwarder. As a result, AWS Managed Microsoft Active Directory will look for this DNS server to resolve customer.com domain to establish a trust relationship.

Figure 14 – Adding a trust relationship by selecting Forest trust, entering the existing customer.com domain along with the trust password and conditional forwarder

We create incoming trust in the customer’s domain by using the trust password specified in the previous step.

Figure 15 – Creating an incoming forest trust between the customer.com domain and aws.local domain

We have completed all required procedures for the hybrid Active Directory setup. Now, let’s take a look how AWS resources can be accessed using the customer’s domain credentials.

Figure 16 illustrates the steps when a user from sg.customer.com tries to access a shared folder hosted in Amazon FSx for Windows File Server.

Figure 16 – User access flow for resources on Amazon FSx for Windows File Server

Four-step sequence is described as follows:

1. A user accesses \\fsx1\share by logging in to a client with credentials from sg.customer.com.
   1. a.  The client computer contacts the Kerberos KDC running on one of the domain controller and requests a service ticket for FSx for Windows File Server SPN.
   2. b. It searches in global catalog server for information about forest trusts that customer.com forest has.
   3. c. Once a one-way forest trust is found, the search compares the domain name suffixes listed in the forest trust to the suffix of the target SPN to find a match. sg.customer.com sends a referral for its parent domain back to client.
2. Client contacts a domain controller in the root domain, customer.com, for a referral to aws.local forest and root domain returns with a referral.
3. Client contacts aws.local forest for a service ticket to the requested service. aws.local search SPN in Global Catalog and sends SPN back to client.
4. Client contacts the KDC in the aws.local domain again and negotiates the ticket for user to gain access to FSx for Windows File server.

Once the client receives a ticket, it sends the service ticket to FSx for Windows File Server which validates the user’s security credentials and constructs an access token accordingly.

Cleaning Up

If you are performing this implementation for a proof of concept or for your own testing, make sure the following services are deleted after testing to avoid incurring future charges.

1. Amazon EC2 Instances
2. Route53
3. AWS Managed Microsoft Active Directory
4. Transit Gateway
5. AWS VPC

Conclusion

We have demonstrated how you can leverage the Multi-Region feature for AWS Managed Microsoft Active Directory in simplifying your hybrid Active Directory deployment.

Throughout our post, we delineated all major components and steps that are required to meet the customer’s objectives from different perspectives.  Although the example we used in this article is emphasizing multiple domains and multiple forests, the scenario is also applicable to smaller scale environments with a single domain and a single forest. For other best practices in designing Active Directory Domain Services architecture on AWS, consult the Active Directory Domain Services on AWS whitepaper.

Field Notes provides hands-on technical guidance from AWS Solutions Architects, consultants, and technical account managers, based on their experiences in the field solving real-world business problems for customers.