Use AWS Systems Manager to improve Microsoft AD stability

In this post, I show you how to use an existing distributed Microsoft Active Directory (Microsoft AD) to authenticate workloads on Amazon Web Services (AWS). Many enterprise organizations with distributed on-premises Microsoft AD environments have authentication issues that cause disruptions and outages. These issues can be caused by either security standards that limit communication to Microsoft AD sites and domain controllers or network latency between geographical locations and corporate-security locations. Situating a dedicated Microsoft AD site physically closer to a cloud environment helps to improve stability in such situations but may not completely solve the problem. AWS Managed Services (AMS) addresses these issues across environments and has developed ways that improve the operational stability of similar environments.

In this post, I use AWS Systems Manager (Systems Manager), a PowerShell script, and native Microsoft AD site topology to improve authentication and operational stability. The goal is to minimize operational issues and incidents related to Microsoft AD authentication by helping to ensure that the cloud environment communicates only with authorized Microsoft AD sites and domain controllers. To manage users, I use a hybrid Microsoft AD environment with a dedicated resource forest for the AWS Cloud (aws-cloud.com) and on-premises user forest (on-prem.com). For authentication, I use two-way Microsoft AD trust between the forests.

Figure 1. Overview of the hybrid Microsoft AD environment with trust between the corporate data center and AWS Cloud.

As shown in figure 1, the proposed architecture can be reworked for other variations of hybrid Microsoft AD forest environments.

Process overview

As shown in figure 2, the environment uses AWS Directory Service (Directory Service) for Microsoft AD for the aws-cloud.com resource forest. The environment includes a Systems Manager–automation document called ADSiteDNSzone and a state-manager association to run the document using an Amazon Elastic Compute Cloud (Amazon EC2) Windows instance. The ASSiteDNSzone document runs a PowerShell script that queries a customer’s on-premises Domain Name System (DNS) and creates or updates a masking DNS zone for on-prem.com, which is hosted on integrated DNS servers.

Figure 2. Microsoft AD domain controller–masking architecture.

A masking DNS zone has service records for the on-prem.com domain that point to dedicated domain controllers. The AWS environment uses the masking on-prem.com DNS zone to resolve on-premises Microsoft AD resources, which limit the communication only to the preferred corporate domain controllers. Figures 3 and 4 show authentication, connectivity, and DNS resolution patterns before the implementation.

Figure 3. Hybrid Microsoft AD environment with on-premises firewall before implementation.

Figure 3 shows that part of the on-prem.com Microsoft AD (DC1 and DC2) is blocked by the on-premises firewall.

Figure 4. Overview of Microsoft AD location in the hybrid environment before implementation.

Authentication problems happen when AWS Managed Microsoft AD or Amazon EC2 instances attempt to communicate with on-premises domain controllers (DC1 or DC2), which are protected by a firewall. After implementation, the location of the domain controller limits all communications to DC3 only.

Figure 5. Overview of domain controller location with masking in place.

The result is that AWS Managed Microsoft AD and Amazon EC2 communicate only with DC3, which improves the operational stability of the hybrid Microsoft AD environment.

Figure 6. Hybrid Microsoft AD environment with domain controller masking in place.

Figure 6 is a simplified view of an enterprise environment with three Microsoft AD sites and three domain controller connections. In a production environment, there may be dozens of sites and hundreds of connections, which makes authentication issue more difficult to troubleshoot. This solution applies to environments of all sizes.

Prerequisites

For the walkthrough, you must have the following:

1. An AWS account. If you don’t have an AWS account, sign up at https://aws.amazon.com.
2. A corporate environment with Microsoft AD.
3. Network connectivity between AWS and your corporate environment.
4. Microsoft AD trust between your corporate environment and AWS.
5. An Amazon EC2 management instance with a Systems Manager agent and permissions to update the DNS of the Microsoft AD.
6. In the corporate or simulated Microsoft AD environment, a dedicated Microsoft AD site for AWS (named AWS).

For testing, use a second AWS account or virtual private cloud (VPC) to simulate the corporate environment. To simulate the user forest, use an existing account and Amazon EC2 or Directory Service for a Microsoft AD–based environment. For more information, see Create and configure your VPC.

• To manually create a Microsoft AD, see Create your AWS Managed Microsoft AD directory.
• To create the directory using AWS CloudFormation, download and launch the AWS CloudFormation template.

For more information, see Create a Site.

Walkthrough

To deploy this architecture, follow these steps:

1. Ensure that all prerequisites are met, and then download and launch the AWS CloudFormation template from the GitHub repository. This deploys all of the assets into the target account.
2. Launch the stack. For more information, see Creating a stack on the AWS CloudFormation console.
3. Use the input parameters listed in the following table, and note that this architecture supports multiple corporate domains and sites.

Note: Ensure that the key pair is unique to only the Amazon EC2 management instance. Otherwise, Systems Manager may attempt to run the automation document against other resources with the same name.

Troubleshooting

Open the Event Viewer of the Amazon EC2 management instance that was created in the prerequisite section, and check the following log and source:

• Log: Application log
• Source: AWSADSiteUpdate

The Systems Manager association runs daily at 18:50 GMT, and the automation document runs a PowerShell script on the Amazon EC2 management instance. A script then queries the Microsoft AD zone on the corporate DNS server (on-prem.com) and pulls service records from the Microsoft AD site that are assigned to AWS. It then creates a new DNS zone on the AWS side (on-prem.com) and populates it with the global service records using site records from the corporate side.

If there is a DNS change on the corporate side, running the script updates the service records. If the script fails, it does not create anything when it runs but tries again during the next cycle. This can happen if the script is unable to resolve customer DNS records. For a log of the script’s actions, open the Event Viewer.

Cleanup

Follow these steps to remove the stack:

1. Delete the AWS CloudFormation stack. For more information, see Deleting a stack on the AWS CloudFormation console.
2. Delete the DNS zone from the DNS server in AWS Managed Microsoft AD. This created the DNS zone and must be removed.
   • Log in to your Amazon EC2 instance that has Windows Remote Server Administration (RSAT) tools installed. Use the RSAT tools to connect to the Microsoft AD DNS server (aws-cloud.com).
   • Locate the masking DNS zone for Microsoft AD (on-prem.com), and delete it.
3. Remove any prerequisite items that are no longer needed:
   • Amazon EC2 management instance
   • Microsoft AD trust between the corporate and AWS environments
   • Microsoft AD site for AWS in the corporate environment
   • Microsoft AD for a simulated environment
   • Network connectivity between AWS and corporate Microsoft AD
   • AWS account for a simulated environment
   • AWS Managed Microsoft AD on AWS

Conclusion

In this post, I showed you how to use AWS Systems Manager to improve the operational stability of hybrid Microsoft AD environments. I used a Systems Manager association, an automation document, and a PowerShell script to manage the Microsoft AD site and service records in a DNS. Based on the needs of your Microsoft AD environment, you can create variations of this architecture, including a single Microsoft AD forest with no trust. For more information, see What is AWS Managed Services?

Use the Feedback section of the GitHub repository to send us your comments and questions.