Deploying Windows AD in AWS using AWS Directory Service and Terraform

AWS Directory Service allows us to quickly deploy a highly available, scalable Windows Active Directory infrastructure inside a VPC.

Using AWS Directory Service, we are freed from configuring and maintaining the Windows servers where the Directory is hosted. The domain controllers are deployed in multiple subnets in different availability zones, making it tolerant of any failure in one availability zone. AD snapshots can also be taken through AWS console or CLI, which is very convenient.

To manage the Directory, for instance to add or remove users, we need to deploy a Windows machine, join it to the domain, then login to it as the domain administrator. Then using the Microsoft Management Console, we manipulate the Directory objects.

This is a proof of concept of deploying a single forest Microsoft AD and the Windows VM (I call it “AD Writer”) into a VPC using Terraform.

The Terraform files can be found at:
https://github.com/tonyprawiro/aws-msad-terraform

All of the objects are deployed in a VPC, which has four subnets:

• Public subnet / DMZ in availability zone 1
• Public subnet / DMZ in availability zone 2
• Private subnet in availability zone 1
• Private subnet in availability zone 2

The AD Writer machine is deployed in DMZ subnet, while the Domain Controllers are deployed in both private subnets.

Once the Directory and the AD Writer machine are deployed, EC2 State Manager is used to create and associate an SSM document to join the machine to the domain. The machine, of course, needs to have SSM permission, as described in the instance profile.

Here is the explanation of the Terraform files.

The Directory is manifested as an aws_directory_service_directory Terraform resource.

In the resource, we define the domain name, the admin password (please take care of secrets properly), and the VPC settings, for instance the VPC ID, and the subnets where the Domain Controllers are deployed in.

The manifest of the AD Writer machine is as follow :

The AD Writer is a Windows 2012 R2 Base machine. Nothing special about this machine when it is being created, except that the IAM role contains a policy with SSM permissions:

We use SSM (EC2 Systems State Manager) to automatically join the machine to the Domain.

There are two parts of SSM, which is SSM document and SSM association.

SSM document defines the commands that we want to be run against the machines it is associated with. In this case, the command is to join the machine to the myapp.com domain. Here is the SSM document:

The above SSM document refers to the Directory ID and the DNS servers that were created during directory creation.

Once the SSM document is created, all we have to do is associate it with the AD Writer machine, and SSM will automatically run the commands against the machine:

Once the SSM Automation is completed, you can access AD Writer machine’s Remote Desktop as “MYAPP\Admin”, with the password you specify in the Terraform manifest (terraform.tfvars, variable dir_admin_password).

If you wish to perform troubleshooting, create an EC2 keypair and associate it with the vm_adwriter resource during creation. Then you can decrypt the Windows password using the keypair, and login as local Administrator to the machine.

To manipulate the Directory, you have to add Windows feature “Active Directory Domain Services” using Windows Server Manager.

Once the feature is installed, you will see Active Directory snap-ins from Administrative Tools which you can use to administer the Directory and manipulate objects.

Check out the full Terraform codes in my GitHub:
https://github.com/tonyprawiro/aws-msad-terraform