CMMC-ready Microsoft Active Directory on AWS

Partner Solution Deployment Guide

QS

August 2023
Mike Whalen, AWS Cloud Architectam
Dave May and Troy Ameigh, AWS Integration & Automation team

Refer to the GitHub repository to view source files, report bugs, submit feature ideas, and post feedback about this Partner Solution. To comment on the documentation, refer to Feedback.

This Partner Solution was created by Amazon Web Services (AWS). Partner Solutions are automated reference deployments that help people deploy popular technologies on AWS according to AWS best practices. If you’re unfamiliar with AWS Partner Solutions, refer to the AWS Partner Solution General Information Guide.

Overview

This guide covers the information you need to deploy the CMMC-ready Microsoft Active Directory Partner Solution in the AWS Cloud.

This Partner Solution is for users who want to deploy an Active Directory environment that is ready for compliance with the Cybersecurity Maturity Model Certification (CMMC). CMMC certification is typically required of US Department of Defense (DOD) contractors.

Deploying this Partner Solution does not guarantee an organization’s compliance with any laws, certifications, policies, or other regulations.

To comply with governance and security requirements, the Partner Solution template uses:

  • An AWS Key Management Service (AWS KMS) customer master key (CMK) to use with Amazon Elastic Block Store (Amazon EBS) and AWS Secrets Manager encryption.

  • Amazon API Gateway Federal Information Processing Standards (FIPS) endpoints.

  • Local customer-controlled file download sources.

  • Implementation of Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGS).

This guide focuses on infrastructure configuration topics that require careful consideration when you are planning and deploying AD DS, domain controller instances, DNS services, and CA services in the AWS Cloud. It doesn’t cover general Windows Server installation and software configuration tasks. For general software configuration guidance and best practices, see the Microsoft product documentation.

Specialized knowledge

A functional AD DS deployment in the AWS Cloud requires knowledge of certain AWS services. This section discusses key considerations for both new AD DS deployments and extensions of existing AD DC deployments to the AWS Cloud. It covers how to place domain controllers and configure the Active Directory Sites and Services tool. It also covers how to use Amazon VPC to define your networks in the Cloud, and how DNS and Dynamic Host Configuration Protocol (DHCP) work in Amazon VPC.

VPC configuration

With Amazon VPC, you can define a virtual network topology that closely resembles a traditional network that you might operate on your own premises. A VPC can span multiple Availability Zones, letting you place independent infrastructures in physically separate locations. A Multi-AZ deployment provides high availability and fault tolerance. This Partner Solution places domain controllers in two Availability Zones to provide highly available, low latency access to AD DS services in the AWS Cloud.

This Partner Solution offers a template that you can use to deploy Active Directory into a new VPC or an existing VPC. When launching the Partner Solution, you can enter an existing VPC ID in the VPCID parameter field to deploy into your existing VPC, or keep this field empty to create a new VPC. To accommodate highly available AD DS in the AWS Cloud, the Partner Solution builds (or requires, if there is an existing VPC) a base VPC configuration that complies with the following AWS best practices:

  • Domain controllers should be placed in a minimum of two Availability Zones to provide high availability.

  • Domain controllers and other non-internet-facing servers should be placed in private subnets.

  • Instances launched by the Partner Solution deployment require internet access to connect to the AWS CloudFormation endpoint during the bootstrapping process. To support this configuration, public subnets are used to host NAT gateways for outbound internet access. Remote Desktop Gateway (RD Gateway) servers are also deployed into the public subnets for remote administration. If needed, you can place other components such as reverse proxy servers into these public subnets.

This VPC architecture uses two Availability Zones, each with its own public and private subnets. Be sure to leave plenty of unallocated address space to support the growth of your environment over time and to reduce the complexity of your VPC subnet design. This Partner Solution uses a default VPC configuration that provides plenty of address space by using the minimum number of private and public subnets. By default, this Partner Solution uses the following Classless Inter-Domain Routing (CIDR) ranges:

VPC 10.0.0.0/16

Private subnets A

10.0.0.0/17

Availability Zone 1

10.0.0.0/19

Availability Zone 2

10.0.32.0/19

Public subnets

10.0.128.0/18

Availability Zone 1

10.0.128.0/20

Availability Zone 2

10.0.144.0/20

In addition, the Partner Solution provides spare capacity for additional subnets to support your environment as it grows or changes over time. If you have sensitive workloads that must be isolated from the internet, you can create new VPC subnets using these optional address spaces. For background information and more details on this option, see Amazon VPC on the AWS Cloud.

Security group input traffic

When launched, Amazon EC2 instances must be associated with a security group, which acts as a stateful firewall. You have full control over the network traffic entering or exiting the security group, and you can build granular rules that are scoped by protocol, port number, and source/destination IP address or other security groups. By default, all output traffic from the security group is permitted. However, input traffic must be configured to allow the appropriate traffic to reach your instances.

To learn about different ways of securing your AWS infrastructure, see the Securing the Microsoft Platform on Amazon Web Services whitepaper. One recommendation is to use security groups to isolate application tiers. To align with this recommendation, you should tightly control input traffic to reduce the attack surface of your Amazon EC2 instances.

Domain controllers and member servers require several security group rules to allow traffic for services such as AD DS replication, user authentication, Windows Time services, Distributed File System (DFS), and others. This Partner Solution automates the deployment of these security groups and associated rules.

This guide provides an example of how to implement these rules for each application tier as part of the AWS CloudFormation template. For a detailed list of port mappings used by the AWS CloudFormation template, see the Security section.

For a complete list of ports, see Active Directory and Active Directory Domain Services Port Requirements in the Microsoft TechNet library. For step-by-step instructions for implementing rules, see Add rules to a security group in the Amazon EC2 documentation.

Configure secure administrative access using RD Gateway

As you design your architecture for AD DS, you should also design for highly available and secure remote access. The Partner Solution template handles this by deploying RD Gateway in each Availability Zone to allow for failover from one Zone to the other.

RD Gateway uses the Remote Desktop Protocol (RDP) over HTTPS to establish a secure, encrypted connection between remote administrators on the internet and Windows-based Amazon EC2 instances without the need for a virtual private network (VPN) connection. This configuration helps reduce the attack surface on your Windows-based Amazon EC2 instances while providing a remote solution for administrators.

The AWS CloudFormation template provided with this Partner Solution automatically deploys the architecture and configuration outlined in the Remote Desktop Gateway Partner Solution.

After you’ve launched your Active Directory infrastructure by following the deployment steps in this guide, you will initially connect to your instances by using a standard RDP TCP port 3389 connection. You can then follow the steps in the Remote Desktop Gateway Partner Solution to secure future connections via HTTPS.

Active Directory design

Review the following sections for key design considerations that are specific to the Partner Solution. Learn about the Active Directory design considerations that are discussed in the Active Directory Domain Services on AWS whitepaper.

Site topology

AWS Global Cloud Infrastructure is built around Regions that contain multiple physically separated, isolated Availability Zones that are connected with low latency, high throughput, and highly redundant networking. Given this, this Partner Solution deploys a single Active Directory site per Region and gives it the Region name.

The following figure shows an example of site and subnet definitions for a typical AD DS architecture running within a VPC. A single Active Directory site has been named after the Region, and subnets have been defined and associated with the Active Directory Region site.

Architecture
Figure 1. Active Directory Sites and Services configuration

Creating a single Active Directory site for the Region, and associating VPC subnets with that site, provides an effective architecture that helps maintain a highly available AD DS deployment.

Highly available directory domain services

Within this Partner Solution, two domain controllers are deployed in your AWS environment in two Availability Zones. This design provides fault tolerance and prevents a single domain controller failure from affecting the availability of the AD DS.

To support the high availability of your architecture and help mitigate the impact of a possible disaster, each domain controller in this Partner Solution is a global catalog server and an Active Directory DNS server.

The AWS CloudFormation template automatically builds an Active Directory Sites and Services configuration that supports a highly available AD DS architecture. If you plan to deploy AD DS into an existing VPC, make sure that you properly map subnets to the correct site to help ensure that AD DS traffic uses the best possible path.

For detailed instructions on creating sites, adding global catalog servers, and creating and managing site links, see Microsoft Active Directory Sites and Services.

Active Directory DNS and DHCP inside the VPC

With a VPC, Dynamic Host Configuration Protocol (DHCP) services are provided by default for your instances via DHCP options sets. This Partner Solution’s AWS CloudFormation template configures the DHCP options set with the Active Directory domain controllers as the name servers, as recommended by the AWS Directory Service documentation. This means that instances that need to join the domain are automatically able to join, without requiring any changes.

The VPC also provides an internal DNS server, which provides instances with basic name resolution services for access to AWS service endpoints such as AWS CloudFormation and Amazon S3 during the bootstrapping process when you launch the Partner Solution.

Note The IP addresses in the domain-name-servers field are always returned in the same order. If the first DNS server in the list fails, instances should fall back to the second IP address and continue to resolve hostnames successfully. However, during normal operations, the first DNS server listed will always handle DNS requests. If you want to ensure that DNS queries are distributed evenly across multiple servers, you should consider statically configuring DNS server settings on your instances.

For details on creating or modifying a custom DHCP options set associated with your VPC, see Working with DHCP options sets in the Amazon VPC User Guide.

DNS settings on Windows server instances

To make sure that domain-joined Windows instances automatically register host (A) and reverse lookup (PTR) records with Active Directory-integrated DNS, set the properties of the network connection as shown in the following figure.

Architecture
Figure 2. Advanced TCP/IP settings on a domain-joined Windows instance

The default configuration for a network connection is set to register the connections address in DNS automatically. In other words, as shown in the preceding figure, the Register this connection’s address in DNS option is chosen for you automatically. This takes care of host (A) record dynamic registration. However, if you do not also choose the second option, Use this connection’s DNS suffix in DNS registration, PTR records will not be dynamically registered.

If you have a small number of instances in the VPC, you can choose to configure the network connection manually. For larger fleets, you can push this setting out to all your Windows instances by using Active Directory Group Policy. For step-by-step instructions, see IPv4 and IPv6 Advanced DNS Tab in the Microsoft TechNet Library.

PowerShell DSC usage in the Partner Solution

This section provides an overview of Windows PowerShell Desired State Configuration (DSC), including how this Partner Solution uses DSC and AWS Systems Manager to configure each domain controller.

Overview of PowerShell DSC

Introduced in Windows Management Framework 4.0, PowerShell DSC provides a configuration management platform that is native to operating systems later than Windows Server 2012 R2 and Windows 8.1, and Linux. Because this Partner Solution uses Windows Server 2019, it also uses Windows Management Framework 5.1 and PowerShell 5.1. Using lightweight commands called cmdlets, DSC allows you to express the desired state of your systems using declarative language syntax instead of configuring servers with complex imperative scripts. If you have worked with configuration management tools like Chef or Puppet, you will notice that DSC provides a familiar framework.

When using DSC to apply a desired configuration for a system, you create a configuration script with PowerShell that explains what the system should look like. Then, you use that configuration script to generate a Management Object Format (MOF) file, which is then pushed or pulled by a node to apply the desired state. PowerShell DSC uses vendor-neutral MOF files to enable cross-platform management, so the node can be either a Windows or a Linux system.

Architecture
Figure 3. High-level PowerShell DSC architecture

Windows systems that are running Windows Management Framework 4.0 or later include the Local Configuration Manager (LCM) engine, which acts as a DSC client. The LCM calls the DSC resources that are required by the configuration defined in the MOF files. These DSC resources apply the desired configuration.

The following figure shows an example of a basic DSC configuration script that can be used to push a desired configuration to a computer.

Architecture
Figure 4. Basic DSC configuration script

  • Line 1: Keyword to define a name (MyService) for the configuration.

  • Line 2: The Node keyword used to define the desired state for a server named Server1.

  • Lines 3-6: Creates an instance of the Service resource called bits and declares that it should be in a running state.

  • Line 10: The configuration is run, generating a MOF file called Server1.mof in a folder called MyService.

  • Line 11: The Start-DscConfiguration cmdlet pushes the MOF file in the MyService folder to the computer Server1. When doing this interactively, use the -Wait and -Verbose parameters to get detailed information. In each step of the Partner Solution, the -Wait parameter is used to orchestrate tasks interactively with AWS services. The -Verbose parameter is used so that execution details are exported to Amazon CloudWatch.

PowerShell DSC usage in the Partner Solution

As noted previously, PowerShell DSC clients can pull their configurations from a server, or their configurations can be pushed to them either locally or from a remote system. This Partner Solution uses a local push configuration on each node. The following figure shows how the Local Configuration Manager (LCM) is configured.

Architecture
Figure 5. Using the Get-DscLocalConfigurationManager cmdlet to get the LCM configuration

The following list describes reasons for using certain settings for this Partner Solution:

  • RefreshMode: The default value Push Mode is used to send the configuration to the LCM on each node.

  • ActionAfterReboot: The value is set to StopConfiguration to orchestrate actions between reboots through AWS services such as Systems Manager. The default value is ContinueConfiguration.

  • RebootNodeIfNeeded: The default value, false, is used to control reboots through AWS services.

These settings, along with the -Wait parameter, allow the Partner Solution to use Systems Manager to orchestrate deployment workflows when starting a DSC configuration.

The following figure shows an example script that you can use to change the configuration of the LCM to align with how you may want to use PowerShell DSC in your environment.

Architecture
Figure 6. Sample script to configure the LCM

The script is available in this Partner Solution’s GitHub repository. Note the use of the DSCLocalConfigurationManager attribute and the Set-DscLocalConfigurationManager cmdlet to configure the LCM specifically. For more information on settings and options, see the PowerShell documentation.

In the GitHub repository, you can also review the ConfigDC1-SSM.ps1 and ConfigDC2-SSM.ps1 scripts, which are used to generate the MOF file for each domain controller node of the Partner Solution. The scripts directory in the repository has a subdirectory labeled certificate-authority containing the scripts used to configure the root and subordinate CAs. These scripts have been annotated for documentation purposes.

AWS Systems Manager usage in the Partner Solution

During the deployment of this Partner Solution, AWS Systems Manager (SSM) Automation documents orchestrate the steps in the configuration of each domain controller and of the certificate authorities. AWS CloudFormation deploys all AWS resources in this Partner Solution, including the Amazon EC2 instances, VPC, and Systems Manager Automation documents. Then the Systems Manager Automation documents are used to configure the Amazon EC2 instances as domain controllers or certificate authorities.

The Partner Solution AWS CloudFormation template deploys stacks that consist of five Amazon EC2 instances with tag values for the Name key derived from the CloudFormation parameters as well as the Systems Manager Automation document. After the second domain controller is deployed, it will start the Automation document through Amazon EC2 user data. See Run commands on your Windows instance at launch for more information.

Costs and licenses

There is no cost to use this Partner Solution, but you will be billed for any AWS services or resources that this Partner Solution deploys. For more information, refer to the AWS Partner Solution General Information Guide.

This Quick Start launches the Amazon Machine Image (AMI) for Microsoft Windows Server 2019 and includes the license for the Windows Server operating system. The AMI is updated on a regular basis with the latest service pack for the operating system, so you don’t have to install any updates. The Windows Server AMI includes two Microsoft Remote Desktop Services licenses. The Windows Server AMI doesn’t require Client Access Licenses (CALs). For details, see Microsoft Licensing on AWS.

Architecture

Deploying this Partner Solution with default parameters builds the following Active Directory environment in the AWS Cloud.

Architecture
Figure 7. Partner Solution architecture for Active Directory on AWS

As shown in Figure 7, the Quick Start sets up the following:

  • A highly available architecture that spans two Availability Zones.*

  • A VPC configured with public and private subnets, according to AWS best practices, to provide you with your own virtual network on AWS.*

  • In the public subnets:

    • Managed network address translation (NAT) gateways to allow outbound internet access for resources in the private subnets.*

    • A Remote Desktop Gateway (RD Gateway) in an Auto Scaling group to allow inbound Remote Desktop Protocol (RDP) access to Amazon Elastic Compute Cloud (Amazon EC2) instances in public and private subnets. An RD Gateway is deployed in Availability Zone 2 only if Availability Zone 1 becomes unavailable.*

  • In the private subnets:

    • An offline root certificate authority.

    • Two Active Directory domain controllers.

    • An online subordinate certificate authority.

  • Amazon S3 Federal Information Processing Standards (FIPS) endpoints for accessing Group Policy Objects (GPOs), logs, certificate revocation lists (CRLs), and setup files.

  • Lambda functions to check for and import new GPOs.

  • AWS Systems Manager automation to import GPOs and set up both the Active Directory domain controllers and the certificate authority.

  • AWS Secrets Manager to store credentials.

  • An AWS Key Management Service (AWS KMS) customer master key (CMK) to use with Amazon Elastic Block Store (Amazon EBS) and AWS Secrets Manager encryption.

  • Encrypted Amazon EBS volumes for the Amazon EC2 instances.

* The template that deploys this Partner Solution into an existing VPC skips the components marked by asterisks and prompts you for your existing VPC configuration.

Deployment options

This Partner Solution provides the following deployment option:

  • Deploy Active Directory into a new VPC. This option provides the ability to build a new AWS environment that comprising a VPC, subnets, NAT gateways, security groups, bastion hosts, and other infrastructure components, and then deploy Active Directory into this new VPC, or to deploy Active Directory into an existing VPC.

Predeployment steps

Do the following steps to prepare for the Partner Solution deployment:

  1. Create an Amazon S3 bucket to store the files.

  2. If you change the index.js file for the GPOPackagesFunction Lambda function, you must create a .zip archive file named GPOPackagesFunction.zip. Be sure it contains only this one file. Next, replace the archive file with the same name in the Archives folder.

  3. Upload the Archives, Scripts, and Templates directories, including all files within those directories.

  4. Create a key pair to use with the Amazon EC2 instances.

Deployment steps

  1. Sign in to your AWS account, and launch this Partner Solution, as described under Deployment options. The AWS CloudFormation console opens with a prepopulated template.

  2. Choose the correct AWS Region, and then choose Next.

  3. On the Create stack page, keep the default setting for the template URL, and then choose Next.

  4. On the Specify stack details page, change the stack name if needed. Review the parameters for the template. Provide values for the parameters that require input. For all other parameters, review the default settings and customize them as necessary. When you finish reviewing and customizing the parameters, choose Next.

    Unless you’re customizing the Partner Solution templates or are instructed otherwise in this guide’s Predeployment section, don’t change the default settings for the following parameters: QSS3BucketName, QSS3BucketRegion, and QSS3KeyPrefix. Changing the values of these parameters will modify code references that point to the Amazon Simple Storage Service (Amazon S3) bucket name and key prefix. For more information, refer to the AWS Partner Solutions Contributor’s Guide.

  5. On the Configure stack options page, you can specify tags (key-value pairs) for resources in your stack and set advanced options. When you finish, choose Next.

  6. On the Review page, review and confirm the template settings. Under Capabilities, select all of the check boxes to acknowledge that the template creates AWS Identity and Access Management (IAM) resources that might require the ability to automatically expand macros.

  7. Choose Create stack. The stack takes about 1 hour to deploy.

  8. Monitor the stack’s status, and when the status is CREATE_COMPLETE, the CMMC-ready Microsoft Active Directory deployment is ready.

  9. To view the created resources, choose the Outputs tab.

Postdeploy
Figure 8. CloudFormation outputs

Postdeployment steps

After deployment, upload the current DISA STIG GPO package to the GPO S3 bucket. For more information on this process, read the DISA STIG GPO Import Process documentation, located in the docs/gpo-import.md file in the GitHub repository. Uploading the package starts the process that imports the GPO backups into Active Directory. You must do this manual process only once after initial deployment.

From then on, you can use a Lambda function to check the DISA website for a new package on a defined schedule and send an SNS notification when a package is found or when it has not been found but should have been available.

Security

AWS provides a set of building blocks (including the Amazon EC2 and Amazon VPC services) that you can use to provision infrastructure for your applications. In this model, some security capabilities such as physical security are the responsibility of AWS and are highlighted in the AWS Security Best Practices whitepaper. Other capabilities, such as controlling access to applications, are the responsibility of the application developer and the tools provided in the Microsoft platform.

If you have followed the automated deployment options in this guide, the necessary security groups are configured for you by the provided AWS CloudFormation template and are listed here for your reference.

Security group Associated with Inbound source Ports

DomainControllerSG

DC1, DC2

VPCCIDR

TCP5985, TCP53, UDP53, TCP80, TCP3389

DomainControllerSG

IpProtocol-1, FromPort-1, ToPort-1

DomainMemberSG

UDP123, TCP135, UDP138, UDP137, TCP139, TCP445, UDP445, TCP464, UDP464, TCP49152-65535, UDP49152-65535, TCP389, UDP389, TCP636, TCP3268, TCP3269, TCP88, UDP88, UDP67, UDP2535, TCP9389, TCP5722, UDP5355, (ICMP -1)

DomainMemberSG

RDGW1, RDGW2

ADServer1PrivateIp,

ADServer2PrivateIp

UDP88, TCP88, TCP445, UDP445, TCP49152-65535, UDP49152-65535, TCP389, UDP389, TCP636

RDGWSecurityGroup

RDGW1, RDGW2

RDGWCIDR*

TCP3389, TCP3391, TCP443

CASurityGroup

RootCA, SubordinateCA

VPCID*

All traffic
Important Never open RDP to the entire internet, not even temporarily or for testing purposes. For more information, see the Morto Worm Spreading via Remote Desktop Protocol Amazon security bulletin. Always restrict ports and source traffic to the minimum necessary to support the functionality of the application. For more about securing Remote Desktop Gateway, see the Securing the Microsoft Platform on Amazon Web Services whitepaper.

Troubleshooting

For troubleshooting common Partner Solution issues, refer to the AWS Partner Solution General Information Guide and Troubleshooting CloudFormation.

Customer responsibility

After you deploy a Partner Solution, confirm that your resources and services are updated and configured—including any required patches—to meet your security and other needs. For more information, refer to the Shared Responsibility Model.

Feedback

To submit feature ideas and report bugs, use the Issues section of the GitHub repository for this Partner Solution. To submit code, refer to the Partner Solution Contributor’s Guide. To submit feedback on this deployment guide, use the following GitHub links:

Notices

This document is provided for informational purposes only. It represents current AWS product offerings and practices as of the date of issue of this document, which are subject to change without notice. Customers are responsible for making their own independent assessment of the information in this document and any use of AWS products or services, each of which is provided "as is" without warranty of any kind, whether expressed or implied. This document does not create any warranties, representations, contractual commitments, conditions, or assurances from AWS, its affiliates, suppliers, or licensors. The responsibilities and liabilities of AWS to its customers are controlled by AWS agreements, and this document is not part of, nor does it modify, any agreement between AWS and its customers.

The software included with this paper is licensed under the Apache License, version 2.0 (the "License"). You may not use this file except in compliance with the License. A copy of the License is located at https://aws.amazon.com/apache2.0/ or in the accompanying "license" file. This code is distributed on an "as is" basis, without warranties or conditions of any kind, either expressed or implied. Refer to the License for specific language governing permissions and limitations.