Active Directory Domain Services on AWS

Partner Solution Deployment Guide

QS

July 2023
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 discusses architectural considerations and configuration steps for deploying a highly available Active Directory Domain Services (AD DS) environment on the AWS Cloud. It also provides links for launching AWS CloudFormation templates that automate the deployment.

The guide is for IT infrastructure architects and administrators who want to design and deploy a solution to launch AD DS in the AWS Cloud or extend their on-premises AD DS into the AWS Cloud.

AWS provides a comprehensive set of services and tools for deploying Microsoft Windows-based workloads on its cloud infrastructure. Microsoft AD DS and Domain Name System (DNS) are core Windows services that provide the foundation for many enterprise class Microsoft-based solutions, including Microsoft SharePoint, Microsoft Exchange, and .NET applications.

This solution is for organizations running workloads in the AWS Cloud to help set up secure, low-latency connectivity to AD DS and DNS services. After reading this guide, IT infrastructure personnel should have a good understanding of how to design and deploy a solution to launch AD DS in the AWS Cloud, or extend their on-premises AD DS into the AWS Cloud. The solution optionally deploys a one- or two-tier Microsoft Public Key Infrastructure.

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

Costs and licenses

This solution 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 doesn’t require client access licenses (CALs). It includes two Microsoft Remote Desktop Services (RDS) licenses. For details, see Microsoft Licensing on AWS.

For more information, refer to the AWS Partner Solution General Information Guide.

Architecture

This solution provides separate AWS CloudFormation templates to support three deployment scenarios. For each scenario, you also have the option to create a new virtual private cloud (VPC) or use your existing VPC infrastructure. Choose the scenario that best fits your needs.

  • Scenario 1: Deploy and manage your own AD DS installation on the Amazon EC2 instances. The AWS CloudFormation template for this scenario builds the AWS Cloud infrastructure, and sets up and configures AD DS and AD-integrated DNS on the AWS Cloud. It doesn’t include AWS Directory Service, so you handle all AD DS maintenance and monitoring tasks yourself. You can also choose to deploy the solution into your existing VPC infrastructure.

  • Scenario 2: Extend your on-premises AD DS to AWS on Amazon EC2 instances. The AWS CloudFormation template for this scenario builds the base AWS Cloud infrastructure for AD DS, and you perform several manual steps to extend your existing network to AWS and to promote your domain controllers. As in scenario 1, you manage all AD DS tasks yourself. You can also choose to deploy the solution into your existing VPC infrastructure.

  • Scenario 3: Deploy AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD). The AWS CloudFormation template for this scenario builds the base AWS Cloud infrastructure and then deploys AWS Managed Microsoft AD on the AWS Cloud. AWS Directory Service takes care of AD DS tasks such as building a highly available directory topology, monitoring domain controllers, and configuring backups and snapshots. As with the first two scenarios, you can choose to deploy the solution into an existing VPC infrastructure.

For all new AD DS installations, the solution also deploys AD DS and AD-integrated DNS, and it sets up Active Directory sites and subnets.

The following sections discuss the architecture for each scenario.

Scenario 1: Deploy self-managed AD

Scenario 1 is based on a new installation of AD DS in the AWS Cloud without AWS Directory Service.

Architecture scenario 1
Figure 1. Scenario 1—Architecture for self-managed AD DS on AWS

As illustrated in Figure 1, the AWS CloudFormation templates that automate this deployment set up the following (with an option to deploy a certificate authority in Availability Zone 1):

  • A VPC configured with public and private subnets in two Availability Zones for high availability.*

  • In the public subnets:

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

    • Remote Desktop Gateway (RD Gateway) instances in an Auto Scaling group to help secure remote access to instances in private subnets.*

  • In the private subnets, a Windows Server forest and domain functional level, including security groups and rules for traffic between instances.

  • AWS Systems Manager Automation documents to set up and configure AD DS and AD-integrated DNS.

  • AWS Secrets Manager to store passwords.

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

In this architecture, domain controllers are deployed into two private VPC subnets in separate Availability Zones, making AD DS highly available. NAT gateways are deployed to public subnets, providing outbound internet access for instances in private subnets. Remote Desktop Gateways are deployed in an Auto Scaling group to the public subnets to help secure remote access to instances in private subnets. You can deploy an optional certificate authority in Availability Zone 1.

Windows Server 2019 is used for the Remote Desktop Gateway instances and the domain controller instances. The AWS CloudFormation template deploys AWS resources, including a Systems Manager Automation document. When the second node is deployed, it triggers execution of the Automation document through Amazon EC2 user data. The automation workflow deploys the required components, finalizes the configuration to create a new AD forest, and promotes instances in two Availability Zones to Active Directory domain controllers.

To deploy this stack, follow the step-by-step instructions in the Deployment Steps section. After deploying this stack, you can move on to deploying your AD DS-dependent servers into the VPC. The DNS settings for new instances will be ready via the updated DHCP options set that is associated with the VPC. You’ll also need to associate the new instances with the domain member security group that is created as part of this deployment.

Scenario 2: Extend your on-premises AD

Scenario 2 is for users who want to use their existing installation of AD DS and extend their on-premises network to the VPC. The on-premises Active Directory environment has one or more domain controllers, global catalog servers, or DNS servers. In this scenario, the newly created Windows Server instances are not automatically promoted to domain controllers. You need to perform postdeployment tasks.

Architecture scenario 2
Figure 2. Scenario 2—Architecture for extending your on-premises AD DS to AWS

As shown in Figure 2, the AWS CloudFormation templates that automate this deployment set up the following (except for the virtual private network (VPN) gateway, VPN connection, and customer gateway, which you create manually):

  • A VPC configured with public and private subnets in two Availability Zones for high availability.*

  • In the public subnets:

    • Managed NAT gateways to allow outbound internet access for resources in the private subnets.*

    • RD Gateway instances in an Auto Scaling group to help secure remote access to instances in private subnets.*

  • In the private subnets, EC2 instances to act as domain controllers.

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

Scenario 2 provides an example of using a VPC and a virtual private gateway to enable communication with your own network over an IPsec VPN tunnel. Active Directory is deployed in the customer data center, and Windows servers are deployed into two VPC subnets. After deploying the VPN connection, you can promote the Windows instances to domain controllers in the on-premises Active Directory forest, making AD DS highly available in the AWS Cloud.

After you deploy the VPN connection and promote your servers to domain controllers, you can launch additional instances into the empty VPC subnets in the web, application, or database tier. These instances will have access to cloud-based domain controllers to help set up secure, low-latency directory services and DNS. All network traffic, including AD DS communication, authentication requests, and Active Directory replication, is secured either within the private subnets or across the VPN tunnel.

Scenario 3: Deploy AWS Managed Microsoft AD

Scenario 3 is similar to scenario 1, except that it includes AWS Directory Service to provision and manage AD DS on the AWS Cloud. Instead of fully managing AD DS yourself, you rely on AWS Directory Service for tasks such as building a highly available directory topology, monitoring domain controllers, and configuring backups and snapshots.

AWS Directory Service deploys AD DS across multiple Availability Zones, and automatically detects and replaces domain controllers that fail. AWS Directory Service also handles time-consuming tasks such as patch management, software updates, data replication, snapshot backups, replication monitoring, and point-in-time restores. For more information about AWS Directory Service, see product details and the AWS documentation.

Architecture scenario 3
Figure 3. Scenario 3—Architecture for deploying AD DS with AWS Directory Service

As shown in Figure 3, the AWS CloudFormation templates that automate this deployment set up the following:

  • A VPC configured with public and private subnets in two Availability Zones for high availability.*

  • In the public subnets:

    • Managed NAT gateways to allow outbound internet access for resources in the private subnets.*

    • RD Gateway instances in an Auto Scaling group to help secure remote access to instances in private subnets.*

  • In the private subnets, an optional Windows EC2 instance to act as a management instance, including security groups and rules for traffic between instances.

  • AWS Systems Manager Automation documents to set up and configure AD DS and AD-integrated DNS.

  • AWS Secrets Manager to store passwords.

  • AWS Directory Service to provision and manage AD DS in the private subnets.

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

Deployment options

This solution provides six deployment options (three scenarios with two options each):

Scenario 1:

Scenario 2:

Scenario 3:

The solution provides separate templates for these options. You can configure Classless Inter-Domain Routing (CIDR) blocks, instance types, and AD DS settings.

AWS Secrets Manager and AWS Directory Service are available only in the AWS Regions listed in the AWS documentation: AWS Secrets Manager endpoints and quotas and Region availability for AWS Directory Service. If you’re deploying scenario 1 (deploy and manage your own AD DS) or scenario 3 (deploy AD DS with AWS Directory Service)—as described in the Architecture section of this guide—check service availability before you choose the Region to deploy the solution into. Otherwise, your deployment will fail.

Plan the deployment

This solution assumes that you’re familiar with Active Directory and DNS. For details, consult the Microsoft product documentation.

Deploying a functional AD DS deployment in the AWS Cloud requires a good understanding of specific AWS services. In this section, we discuss key considerations for both new AD DS deployments and extensions of existing AD DC deployments to the AWS Cloud. We discuss how to use Amazon VPC to define your networks in the cloud. We also cover domain controller placement, Active Directory Sites and Services configuration, and how DNS and DHCP work in Amazon VPC.

VPC configuration

With Amazon VPC, you can define a virtual network topology closely resembling a traditional network that you might operate on your own premises. A VPC can span multiple Availability Zones so that you can place independent infrastructure in physically separate locations. A Multi-AZ deployment provides high availability and fault tolerance. In the scenarios in this guide, we place domain controllers in two Availability Zones to provide highly available, low-latency access to AD DS services in the AWS Cloud.

Each scenario is automated by two templates: one that builds a new VPC for the deployment, and the other that deploys into an existing VPC. To accommodate highly available AD DS in the AWS Cloud, the solution builds (or requires, in the case of the existing VPC template) 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 deployment templates provided in this guide will 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 gateways are also deployed into the public subnets for remote administration. Other components such as reverse proxy servers can be placed into these public subnets, if needed.

This VPC architecture uses two Availability Zones, each with its own distinct public and private subnets. We recommend that you 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 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 solution uses the following 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 solution provides spare capacity for additional subnets, to support your environment as it grows or changes over time. If you have sensitive workloads that should be completely isolated from the internet, you can create new VPC subnets using these optional address spaces. For background information and more details on this approach, see the Amazon VPC on AWS solution deployment guide.

Security group ingress traffic

When launched, Amazon EC2 instances must be associated with a security group, which acts as a stateful firewall. You have complete control over the network traffic entering or leaving 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 egress traffic from the security group is permitted. However, ingress traffic must be configured to allow the appropriate traffic to reach your instances.

The Securing the Microsoft Platform on Amazon Web Services whitepaper discusses methods of securing your AWS infrastructure. Recommendations include providing isolation between application tiers by using security groups. We recommend that you tightly control ingress traffic in order to reduce the attack surface of your Amazon EC2 instances.

If you’re deploying and managing your own AD DS installation, domain controllers and member servers will require several security group rules to allow traffic for services such as AD DS replication, user authentication, Windows Time services, and Distributed File System (DFS), among others. You should also consider restricting these rules to specific IP subnets that are used within your VPC.

We provide an example of how to implement these rules for each application tier later in this guide as part of the AWS CloudFormation template for each scenario. For a detailed list of port mappings used by the AWS CloudFormation templates, see the Security section of this guide.

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 guidance for implementing rules, see Adding Rules to a Security Group in the Amazon EC2 User Guide.

Help set up secure administrative access using Remote Desktop Gateway

As you design your architecture for highly available AD DS, also design for highly available and secure remote access. The solution templates help with this by deploying Remote Desktop (RD) Gateway in each Availability Zone. In case of an Availability Zone outage, this architecture allows access to the resources that may have failed over to the other Availability Zone.

RD Gateway uses the Remote Desktop Protocol (RDP) over HTTPS to help 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 administration solution for administrators.

The AWS CloudFormation templates provided with this solution automatically deploy the architecture and configuration outlined in the Remote Desktop Gateway solution.

After you’ve launched your AD 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 solution to help secure future connections via HTTPS.

Active Directory design

If you’re managing your own AD DS infrastructure—scenario 1 or scenario 2, as described in the Architecture section of this guide—review the following sections for key design considerations specific to the solution. Also get familiar with the Active Directory design considerations that are discussed in the Active Directory Domain Services on AWS whitepaper.

Site topology

Because AWS Global 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, this solution deploys a single AD 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 AD Region site.

Sites and Services configuration
Figure 4. Active Directory Sites and Services configuration

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

Highly available directory domain services

Within this 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 further support the high availability of your architecture and help mitigate the impact of a possible disaster, each domain controller in this solution is a global catalog server and an Active Directory DNS server.

The AWS CloudFormation template provided for scenario 1 (deploy and manage your own AD DS, as described in the Architecture section of this guide) builds out an Active Directory Sites and Services configuration for you automatically that supports a highly available AD DS architecture. If you plan to deploy AD DS manually, properly map subnets to the correct site to help ensure that AD DS traffic uses the best possible path.

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

Active Directory DNS and DHCP inside the VPC

With a VPC, Dynamic Host Configuration Protocol (DHCP) services are provided by default for your instances. DHCP scopes do not need to be managed; they are created for the VPC subnets you define when you deploy your solution. These DHCP services cannot be disabled, so you’ll need to use them rather than deploying your own DHCP server.

The VPC also provides an internal DNS server. This DNS provides instances with basic name resolution services for internet access. This is crucial for access to AWS service endpoints such as AWS CloudFormation and Amazon Simple Storage Service (Amazon S3) during the bootstrapping process when you launch the solution.

Amazon-provided DNS server settings will be assigned to instances launched into the VPC based on a DHCP options set. DHCP options sets are used within a VPC to define scope options, such as the domain name or the name servers that should be handed to your instances via DHCP. Amazon-provided DNS is used only for public DNS resolution.

Since Amazon-provided DNS cannot be used to provide name resolution services for Active Directory, you’ll need to ensure that domain-joined Windows instances have been configured to use Active Directory DNS.

As an alternative to statically assigning Active Directory DNS server settings on Windows instances, you have the option of specifying them using a custom DHCP options set. This will allow you to assign your Active Directory DNS suffix and DNS server IP addresses as the name servers within the VPC via DHCP.

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 and continue to resolve host names successfully. However, during normal operations, the first DNS server listed will always handle DNS requests. To ensure that DNS queries are distributed evenly across multiple servers, statically configure DNS server settings on your instances.

For details on creating a custom DHCP options set and associating it with your VPC, see Working with DHCP options sets in the Amazon VPC User Guide.

If you’re deploying scenario 1 (deploy and manage your own AD DS) or scenario 3 (deploy AD DS with AWS Directory Service)—as described in the Architecture section of this guide—the AWS CloudFormation template configures the DHCP options set with the Active Directory domain controllers as the name servers. This is recommended in the AWS Directory Service documentation: Create a DHCP options set. Instances that need to join the domain will therefore automatically be able to join without requiring any changes.

DNS settings on Windows Server instances

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

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

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

If you have a small number of instances in the VPC, you may 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 AD DS solution

In this section, we will provide an overview of Windows Powershell Desired State Configuration (DSC), and we will cover how this solution uses DSC and Systems Manager to configure each domain controller. If you are new to PowerShell DSC, we highly recommend that you consult the additional resources at the end of this guide for a deeper look at the topic.

Overview of PowerShell DSC

Introduced in Windows Management Framework 4.0, PowerShell DSC provides a configuration management platform native to operating systems later than Windows Server 2012 R2 and Windows 8.1, as well as Linux. Because we are leveraging Windows Server 2019 in this solution, we are using Windows Mangement 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. 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 6. 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 7. Basic DSC configuration script

  1. Line 1 – We use the Configuration keyword to define a name (MyService) for the configuration.

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

  3. Lines 3 through 6 – We create an instance of the Service resource called bits. Within the resource, we’re declaring that the service named bits should be in a running state.

  4. Line 10 – The configuration is executed, which generates a MOF file called Server1.mof in a folder called MyService.

  5. Line 11 – The Start-DscConfiguration cmdlet pushes the MOF file in the MyService folder to the computer Server1. When doing this interactively, it’s useful to use the -Wait and -Verbose parameters to get detailed information. In each step of the solution, we use the -Wait parameter so that we can orchestrate tasks interactively with AWS services. We use the -Verbose parameter so that execution details gets exported to Amazon CloudWatch.

DSC usage in the AD DS 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. In this solution, we use a local push configuration on each node. The following figure shows how we are configuring the LCM.

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

The following list describes why we chose certain settings for this solution.

  • RefreshMode – We use the default value, Push Mode, to send the configuration to the LCM on each node.

  • ActionAfterReboot -We set this to StopConfiguration so that we can orchestrate actions between reboots through AWS services such as Systems Manager. The default value is ContinueConfiguration.

  • RebootNodeIfNeeded – We use the default value, false, so that we can control reboots through AWS services.

    These settings, along with the -Wait parameter, allow the 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 leverage PowerShell DSC in your environment.

Sample script to configure the LCM
Figure 9. Sample script to configure the LCM

The script is available in this solution’s GitHub repo. Note the use of the DSCLocalConfigurationManager attribute and the Set-DscLocalConfigurationManager cmdlet to specifically configure the LCM. For more information on settings and options, see Understanding Meta Configuration in Windows PowerShell Desired State Configuration.

In the GitHub repo you can also review the ConfigDC1.ps1 and ConfigDC2.ps1 scripts, which are used to generate the MOF file for each node of the solution. These scripts have been annotated for documentation purposes.

Systems Manager usage in the AD DS solution

During the deployment of this solution, Systems Manager Automation documents orchestrate the steps in the configuration of each domain controller. AWS CloudFormation deploys all AWS resources in this solution, including the EC2 instances, VPC, and Systems Manager Automation documents. Then the Systems Manager Automation documents are used to configure the EC2 instances as domain controllers.

The following figure shows the workflow that the Systems Manager Automation document uses to configure the EC2 instances as domain controllers.

Systems ManagerAutomation document workflow
Figure 10. Systems Manager Automation document workflow

The solution AWS CloudFormation template deploys a stack that consists of two EC2 instances with tag values for the Name key derived from the ADServer1NetBIOSName and ADServer2NetBIOSName parameters as well as the AWSQuickStartActiveDirectoryDS Automation document. After the second instance is deployed, it will start the Automation document through EC2 user data. The process includes the following steps:

  • dcsInstanceIds – This step gets the instance IDs for EC2 instances that have the Name tag set to ADServer1NetBIOSName and ADServer2NetBIOSName parameters in the solution and outputs them for subsequent steps.

  • dcsInstallDscModules – This step installs the xActiveDirectory DSC module and the additional required DSC modules (NetworkingDsc, ComputerManagementDsc, xDnsServer) from the PowerShell Gallery on the instances that were identified by their instance IDs in step 1. It also generates an encryption certificate to encrypt MOF files. This ensures that no clear text passwords are saved locally in this solution. This step uses the install-ad-modules.ps1 script that is in the scripts folder in the GitHub repo.

  • dcsLCMConfig – This step configures the LCM on each EC2 instance from step 1. It uses the LCM-Config.ps1 script that is in the scripts folder.

  • dc1InstanceId – This step gets the instance ID for the EC2 instance that has the Name tag value set to the ADServer1NetBIOSName parameter and outputs it for subsequent steps.

  • createDC1Mof– This step generates a local encrypted MOF file on the first domain controller in the C:\AWSQuickstart\ directory. This MOF file is used in the step 7 to configure the domain controller. It uses the ConfigDC1.ps1 script that is in the scripts folder.

  • configDC1 – This step configures the first domain controller by using the MOF file generated in Step 6. It uses the Exit 3010 Status code to signal the Systems Manager Agent to reboot the instance when needed. The agent will reboot the instance and restart DSC configuration on this instance until the configuration of the instance matches the MOF file.

  • dc2InstanceId – This step gets the instance ID for the EC2 instance that has the Name tag value set to the ADServer2NetBIOSName parameter and outputs it for subsequent steps.

  • createDC2Mof – This step generates a local encrypted MOF File on the second domain controller in the C:\AWSQuickstart\ directory. This MOF file is used in the next step to configure the domain controller. It uses the ConfigDC1.ps1 script that is in the scripts folder.

  • configDC2 – This step configures the second domain controller by using the MOF file generated in Step 9. It usees the Exit 3010 Status code to signal the Systems Manager Agent to reboot the instance when needed. The agent will reboot the instance and restart DSC configuration on this instance until the configuration of the instance matches the MOF file.

  • DnsConfig – This step ensures that both domain controllers point to AD DNS as their DNS Servers. It uses the Dns-Config.ps1 script that is in the scripts folder.

  • CFNSignalEnd – This branch step determines if AWS CloudFormation needs to be signaled that deployment was successful. If the StackName parameter is not null, the Automation document will move to the signalsuccess step; if the parameter is null, it will move to the sleepend step.

  • signalsuccess or sleepend – The signalsuccess steps signals to AWS CloudFormation that the workflow completed successfully and that stack deployment may proceed. The sleepend step is provided for re-use of the Automation document. If no AWS CloudFormation stack name is provided, the sleepend step will end the Automation document.

  • signalfailure – If any steps fail, the Automation document will attempt to signal failure to the AWS Cloud.

Predeployment steps

Before you deploy the solution, make sure that your AWS account is set up properly by following these steps.

  1. If you don’t already have an AWS account, create one at https://aws.amazon.com by following the on-screen instructions. Part of the sign-up process involves receiving a phone call and entering a PIN using the phone keypad.

  2. Use the Region selector in the navigation bar to choose the AWS Region where you want to deploy AD DS. Consider choosing the Region closest to your data center or corporate network to reduce network latency between systems running on AWS and the systems and users on your corporate network.

  3. Create an Amazon EC2 key pair in your preferred Region. To do this, in the navigation pane of the Amazon EC2 console, choose Key Pairs, Create Key Pair, type a name, and then choose Create.

    Amazon EC2 uses public-key cryptography to encrypt and decrypt login information. To be able to log in to your instances, you must create a key pair. With Windows instances, we use the key pair to obtain the administrator password via the Amazon EC2 console and then log in using Remote Desktop Protocol (RDP) as explained in the instructions Create a key pair using Amazon EC2 in the Amazon Elastic Compute Cloud User Guide.

  4. If necessary, request a service limit increase for the Amazon EC2 m4.xlarge instance type. To do this, in the AWS Support Center, choose Create Case, Service Limit Increase, EC2 instances. Then, complete the fields in the limit-increase form. The current default limit is 20 instances.

    You might need to request an increase if you already have an existing deployment that uses this instance type and if you think you might exceed the default limit with this reference deployment. It might take a few days for the new service limit to become effective. For more information, see Amazon EC2 service quotas.

If you’re deploying AD DS into an existing VPC, make sure that your VPC has two private subnets in different Availability Zones for the workload instances and that the subnets aren’t shared. This solution doesn’t support shared subnets. These subnets require NAT gateways in their route tables to allow the instances to download packages and software without exposing them to the internet. Also make sure that the domain name option in the DHCP options is configured as explained in DHCP options sets. You provide your VPC settings when you launch the solution.

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 10 to 60 minutes to deploy.

  8. Monitor the stack’s status, and when the status is CREATE_COMPLETE, the Active Directory Domain Services deployment is ready.

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

Postdeployment steps

After deploying this solution, do the following.

Run Windows updates

In order to ensure the deployed servers' operating systems and installed applications have the latest Microsoft updates, run Windows Update on each server.

  1. Create an RDP session from the Remote Desktop Gateway server to each deployed server.

  2. Open the Settings application.

  3. Open Update & Security.

  4. Click Check for updates.

  5. Install any updates and reboot if necessary.

Postdeployment steps for scenario 2 only

If you’re extending your on-premises AD DS to the AWS Cloud—scenario 2, as described in the Architecture section of this guide—the solution does not promote the newly created Windows servers to domain controllers. You need to perform the following tasks manually after the stack has been successfully created:

  1. Connect your on-premises network to the VPC using AWS Direct Connect or a VPN connection and verify that the new Windows Server instances that were created by the solution can resolve the domain DNS name.

  2. Promote the new Windows Server instances that were created by the solution to domain controllers in your Active Directory domain.

  3. Configure your on-premises Active Directory Sites and Services to include sites and subnets that represent the Availability Zones within your VPC, and place the newly promoted Domain Controllers in their associated sites.

  4. Ensure that instances can resolve names via AD DNS by using one of these methods:

    • Statically assign AD DNS servers on Windows instances.

      —or—

    • Set the domain-name-servers field in a new DHCP options set in your VPC to include your AWS-based domain controllers hosting Active Directory DNS.

The following sections provide more information about these postdeployment tasks.

Connect your on-premises network to the VPC

By default, instances that you launch into a virtual private cloud can’t communicate with your own network. To extend your existing AD DS into the AWS Cloud, you’ll need to extend your on-premises network to the VPC. We’ll discuss two ways to do this: by using IPsec virtual private network (VPN) tunnels or by using AWS Direct Connect.

Use IPsec VPN tunnels

The most common scenario for extending your on-premises network to your VPC is through IPsec VPN tunnels. Within the VPC, you can create a virtual private gateway that acts as a VPN concentrator on the Amazon side of the VPN tunnel. A customer gateway is the anchor on your side of that connection. The customer gateway can be a physical device or a software appliance.

Single VPN connection
Figure 11. Single VPN connection from your on-premises network to your VPC

Multiple VPN configuration options are available, including the ability to use multiple on-premises customer gateways and configuring redundant VPN connections to provide failover. For details, see VPN Configuration Examples in the Amazon VPC User’s Guide. Details about which hardware or software appliances you can use are available in the Customer Gateway devices we’ve tested and Requirements for your customer gateway sections of the Amazon VPC Network Administrator Guide.

Use AWS Direct Connect

AWS Direct Connect links your internal network to an AWS Direct Connect location over a standard 1 gigabit or 10 gigabit Ethernet fiber-optic cable. One end of the cable is connected to your router, the other to an AWS Direct Connect router. With this connection in place, you can create virtual interfaces directly to the AWS Cloud (for example, to Amazon EC2, to Amazon S3, and to Amazon VPC), bypassing internet service providers in your network path. More information about AWS Direct Connect can be found here.

Connect to additional VPCs

If your Active Directory environment has already been deployed to AWS via a different VPC, you can connect the other VPC to your new VPC via VPC Peering. VPC Peering allows network connectivity within the same account or across multiple accounts. See the AWS VPC Peering guide for additional information.

AWS Direct Connect interfaces
Figure 12. How AWS Direct Connect interfaces with your network

When you choose AWS Direct Connect to extend your on-premises network to the cloud, you should consider configuring two dedicated connections for maximum redundancy. There are different configuration choices available when you provision two dedicated connections, including active/active (BGP multipath), and active/passive (failover).

In a failover configuration, only one connection link handles traffic. If that link becomes unavailable, the standby connection link becomes active. We recommend that you configure both connection links as active, because this will help ensure that network traffic is load-balanced across both connections. In an active configuration, if one connection link becomes unavailable, all traffic is routed through the other link. For implementation details, see Getting Started in the AWS Direct Connect User Guide.

Deploy additional domain controllers in the AWS Cloud

Although you can use AWS Direct Connect or a VPN connection to provide access to on-premises resources from the VPC, we recommend that you also add domain controllers to the AWS Cloud. Additional domain controllers provide a reliable, low-latency network connection for resources in AWS that need access to your AD DS. They can also maintain availability for AD DS in the AWS Cloud if there’s an on-premises infrastructure outage.

In the architecture shown in Figure 13, a single Active Directory forest has been extended from an on-premises deployment into a VPC using a VPN connection. Within the VPC, additional domain controllers configured as global catalog and DNS servers are deployed in the existing Active Directory forest.

AWS Direct Connect interfaces
Figure 13. How AWS Direct Connect interfaces with your network

In this type of environment, the customer network will already be defined in Active Directory Sites and Services. For example, there will already be a site definition that corresponds to the on-premises network, along with a subnet definition for the 192.168.1.0/24 network. The next step is to configure Active Directory Sites and Services to support the network components located in the VPC.

Configure Active Directory Sites and Services

An Active Directory site should be created for the Region in AWS. The 10.0.0.0/19 and 10.0.32.0/19 CIDR blocks used by the VPC subnets should be added to Active Directory Sites and Services. The subnets can then be associated with the AD DS site definition for the Region. Additional subnets for web, application, and database tiers in the VPC can be mapped to each AWS site object. Both the on-premises site and the site in the AWS Cloud can be mapped to a site link, which can be configured to replicate at custom intervals or during a specific time of day, if needed.

By properly configuring Active Directory Sites and Services, you can help ensure that the AD DS queries and authentication requests that originate from the VPC are serviced by a local domain controller in the same AWS Availability Zone. This configuration reduces network latency and minimizes traffic that may otherwise need to travel across the VPN back to the on-premises infrastructure.

Configure DNS resolution

After you’ve created a VPC and established connectivity to your on-premises network by using AWS Direct Connect or a VPN connection, your next step is to launch Windows instances to act as domain controllers. In order to join the on-premises Active Directory domain and promote your Windows instances to domain controllers, you’ll need to ensure that DNS resolution is configured appropriately.

As discussed previously, by default, instances launched into the VPC will be assigned an Amazon-provided DNS server, which will not provide DNS resolution for your on-premises infrastructure. To address this, you can do one of two things:

  • Manually assign DNS server settings on the Windows instances. This static DNS setting would initially point to the on-premises Active Directory DNS server. After promoting the instance to a domain controller, you could modify the setting to use a cloud-based Active Directory DNS server IP address to prevent subsequent DNS queries from traversing the link back to the on-premises environment.

    —or—

  • Initially configure the VPC DHCP options set to assign your on-premises Active Directory DNS server IP address to your instances launched into the VPC. After the Windows instances have been joined to the domain and promoted to domain controllers, you can create a new DHCP options set to assign the IP address of the Active Directory DNS server instances running in AWS.

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 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 templates and are listed here for your reference.

Security group Associated with Inbound source Port(s)

DomainControllerSG

DC1, DC2

DomainMemberSG

UDP53, TCP53, TCP88, UDP88, UDP123, TCP135, UDP138, TCP389, TCP445, UDP445, UDP464, TCP464, TCP636, TCP3268, TCP3269, RDP3389, TCP5985, TCP9389, TCP49152-65535, UDP49152-65535

DomainMemberSG

RDGW1, RDGW2

DomainMemberSG

TCP3389, TCP5985, TCP5986

RemoteDesktopGatewaySG

RDGW1, RDGW2

RDGWCIDR

TCP3389, TCP443, UDP3391, ICMP-1

Important RDP should never be opened up to the entire internet, not even temporarily or for testing purposes. For more information, see this 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 issues, refer to the AWS Partner Solution General Information Guide and Troubleshooting CloudFormation.

I encountered a CREATE_FAILED error when I launched the solution

If AWS CloudFormation fails to create the stack, relaunch the template with Rollback on failure set to Disabled. This setting is under Advanced in the AWS CloudFormation console on the Configure stack options page. With this setting, the stack’s state is retained and the instance is left running, so you can troubleshoot the issue. (For Windows, look at the log files in %ProgramFiles%\Amazon\EC2ConfigService and C:\cfn\log.)

When you set Rollback on failure to Disabled, you continue to incur AWS charges for this stack. Delete the stack when you finish troubleshooting.

I encountered a size-limitation error when I deployed the AWS CloudFormation templates

Launch the solution templates from the links in this guide or from another S3 bucket. If you deploy the templates from a local copy on your computer or from a location other than an S3 bucket, you might encounter template size limitations. For more information, see AWS CloudFormation quotas.

The AWS CloudFormation deployment failed because the Systems Manager Automation document failed

Check the logs in CloudWatch. Also ensure that the deployment is targeting the correct instances. If any other EC2 instances in your environment use the same Name tag, they will be targeted and will fail during automation, which will cause the solution to fail.

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.