// Replace the content in <>
// For example: “familiarity with basic concepts in networking, database operations, and data encryption” or “familiarity with <software>.”
// Include links if helpful. 
// You don't need to list AWS services or point to general info about AWS; the boilerplate already covers this.

// Replace the content in <>
// For example: “familiarity with basic concepts in networking, database operations, and data encryption” or “familiarity with <software>.”
// Include links if helpful. 
// You don't need to list AWS services or point to general info about AWS; the boilerplate already covers this.

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 Quick Start places domain controllers in two Availability Zones to provide highly available, low latency access to AD DS services in the AWS Cloud.

This Quick Start offers a template that you can use to deploy Active Directory into a new VPC or an existing VPC. When launching the Quick Start, 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 Quick Start 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 Quick Start 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 Quick Start uses a default VPC configuration that provides plenty of address space by using the minimum number of private and public subnets. By default, this Quick Start uses the following Classless Inter-Domain Routing (CIDR) ranges:

[cols="3",options="header",]
|====================================
|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 Quick Start 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 https://fwd.aws/9VdxNAmazon[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 https://d1.awsstatic.com/whitepapers/aws-microsoft-platform-security.pdf[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 Quick Start 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 link:#_security[Security] section.

For a complete list of ports, see http://technet.microsoft.com/library/dd772723(v=ws.10).aspx[Active Directory and Active Directory Domain Services Port Requirements^] in the Microsoft TechNet library. For step-by-step instructions for implementing rules, see http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html#adding-security-group-rule[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 Quick Start 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 Quick Start automatically deploys the architecture and configuration outlined in the https://fwd.aws/5VrKP[Remote Desktop Gateway Quick Start].

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 https://fwd.aws/5VrKP[Remote Desktop Gateway Quick Start^] to secure future connections via HTTPS.

==== Active Directory design

Review the following sections for key design considerations that are specific to the Quick Start. Learn about the Active Directory design considerations that are discussed in the https://d1.awsstatic.com/whitepapers/adds-on-aws.pdf[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 Quick Start 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.

[#knowledge1]
.Active Directory Sites and Services configuration
image::../images/image5.png[Architecture,width=648,height=338]

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]]
===== Highly available directory domain services

Within this Quick Start, 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 Quick Start 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 http://technet.microsoft.com/library/cc730868.aspx[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 Quick Start's AWS CloudFormation template configures the DHCP options set with the Active Directory domain controllers as the name servers, as recommended by the http://docs.aws.amazon.com/directoryservice/latest/admin-guide/dhcp_options_set.html[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 Quick Start.

*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 http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html#DHCPOptionSet[Working with DHCP options sets^] in the _Amazon VPC User Guide_.

[[dns-settings-on-windows-server-instances]]
===== 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.

[#knowledge2]
.Advanced TCP/IP settings on a domain-joined Windows instance
image::../images/image6.png[Architecture,width=295,height=353]

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 http://technet.microsoft.com/library/cc754143.aspx[IPv4 and IPv6 Advanced DNS Tab] in the Microsoft TechNet Library.

=== PowerShell DSC usage in the Quick Start

This section provides an overview of Windows PowerShell Desired State Configuration (DSC), including how this Quick Start 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 Quick Start 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.

[#knowledge3]
.High-level PowerShell DSC architecture
image::../images/image7.png[Architecture,width=563,height=224]

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.

[#knowledge4]
.Basic DSC configuration script
image::../images/image8.png[Architecture,width=533,height=224]

* 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 Quick Start, 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.

[[dsc-usage-in-the-ad-ds-quick-start]]
==== PowerShell DSC usage in the Quick Start

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 Quick Start uses a local push configuration on each node. The following figure shows how the Local Configuration Manager (LCM) is configured.

[#knowledge5]
.Using the Get-DscLocalConfigurationManager cmdlet to get the LCM configuration
image::../images/image9.png[Architecture,width=547,height=370]

The following list describes reasons for using certain settings for this Quick Start:

* *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 Quick Start 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.

[#knowledge6]
.Sample script to configure the LCM
image::../images/image10.png[Architecture,width=100%,height=100%]

The script is available in this Quick Start’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 https://docs.microsoft.com/en-us/powershell/?view=powershell-7.1[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 Quick Start. 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.

[[systems-manager-usage-in-the-ad-ds-quick-start]]
==== AWS Systems Manager usage in the Quick Start

During the deployment of this Quick Start, 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 Quick Start, 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 Quick Start 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 https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-windows-user-data.html[Run commands on your Windows instance at launch^] for more information. 
