AWS Managed Active Directory Service

In December, AWS announced a rather significant, and welcome, update to their existing Directory Service.

The service, which was first introduced at re:Invent 2014, initially offered two operability modes:

  • AD Connector – A proxy service that allows you to connect AWS services (and applications running on them) to an existing on-premise Active Directory domain. No directory information is stored or cached in AWS, but rather identities are federated using SAML 2.0. This is useful if your aim is to allow AWS services to authenticate to your current AD. If your network or VPN connection goes down then anything running in AWS is effectively cut off. If you intend to extend, or ultimately migrate, your domain into the cloud, then this mode may not be for you.
  • Simple AD – This service offers an “AD compatible” directory based on the open source Samba 4 implementation. If your aim is to establish a new simple directory within AWS for services to authenticate then this is an option. Again however, there is no facility to extend an existing on-premise domain. With Simple AD you are also unable to federate or trust other domains.

AWS’ announcement in December 2015 presents us with another option  in the form of the  Managed Directory Service. This represents the first fully managed directory service (in general release) of any of the major cloud providers and the only one that is currently available in the Australian region.

The timing of this announcement was perfect for us as we had a customer who was an ideal candidate for the new functionality. Consequently, we spun up a quick proof of concept last week to see what its pros and cons are.

In our test we were attempting to implement federation and trust to an existing on-premise Active Directory domain running inside our lab. We were using Windows Server 2008 R2 for the on-premise AD. The AWS Directory Service uses a Windows 2012R2 AD.

As we didn’t have a Direct Connect connection we setup up Openswan software VPNs on each side. It’s important to not have overlapping  CIDR block between the on-premise and cloud networks. For our test we used 10.20.34.0/24 for the on-premise network and 10.0.0.0/16 for the AWS VPC.

The basic setup process is very straightforward. The type of the AD service, for instance, is enterprise size only.  You can’t downgrade it to small.  You also have to setup a new domain name during the creation phase. It currently won’t let you extend into an existing domain.

Another interesting thing is that the service MUST be configured to use two different Availability Zones (AZs). During the creation phase you need to specify two deployment subnets and these must be in different AZs or the process will not continue.

The configuration screens are fairly self explanatory for anyone across Active Directory terminology. Whilst the service was being created we extracted the Directory ID from the Directory Details page to check what was happening in terms of security groups. The creation process creates its own security group, which by default , only allows outbound traffic to itself.  We needed to modify this to allow communications between our on-premise domain.

The diagram below shows the high level network topology for what we were attempting as well as the basic flow of traffic

Figure 2.

 

In terms of security groups, the inbound VPN rules (as shown in the green box) can be basically represented as:

 

Type Protocol Port Range Source
Custom UDP Rule UDP 500 On-prem VPN external address
Custom UDP Rule UDP 4500 On-prem VPN external address
Custom Protocol Rule ESP ALL On-prem VPN external address
Custom Protocol Rule AH ALL On-prem VPN external address

 

For the inbound rules to the AD service in AWS, there should be two separate security groups, one for establishing trust between the on-premise Domain Controller and the AWS Directory Service. The DC to DC trust rules are as follows:

 

Type Protocol Range Source
DNS(UDP) UDP 53 On-prem AD IP range
DNS(TCP) TCP 53 On-prem AD IP range
Custom TCP Rule TCP 88 On-prem AD IP range
Custom UDP Rule UDP 123 On-prem AD IP range
Custom TCP Rule TCP 135 On-prem AD IP range
Custom UDP Rule UDP 389 On-prem AD IP range
LDAP TCP 389 On-prem AD IP range
Custom UDP Rule UDP 445 On-prem AD IP range
Custom TCP Rule TCP 445 On-prem AD IP range
Custom UDP Rule UDP 464 On-prem AD IP range
Custom TCP Rule TCP 464 On-prem AD IP range
Custom TCP Rule TCP 636 On-prem AD IP range
Custom TCP Rule TCP 3268-3269 On-prem AD IP range
All ICMP ICMP 0-65535 On-prem AD IP range
Custom TCP Rule TCP 49152-65535 On-prem AD IP range

 

The rules to allow Windows clients to authenticate and connect to the domain are quite similar. They are as follows:

 

Type Protocol Range Source
DNS(UDP) UDP 53 AWS Windows clients secgrp
DNS(TCP) TCP 53 AWS Windows clients secgrp
Custom TCP Rule TCP 88 AWS Windows clients secgrp
Custom UDP Rule UDP 123 AWS Windows clients secgrp
Custom UDP Rule UDP 389 AWS Windows clients secgrp
LDAP TCP 389 AWS Windows clients secgrp
Custom UDP Rule UDP 445 AWS Windows clients secgrp
Custom TCP Rule TCP 445 AWS Windows clients secgrp
Custom UDP Rule UDP 464 AWS Windows clients secgrp
Custom TCP Rule TCP 464 AWS Windows clients secgrp
Custom TCP Rule TCP 636 AWS Windows clients secgrp
Custom TCP Rule TCP 3268-3269 AWS Windows clients secgrp
Custom TCP Rule TCP 49152-65535 AWS Windows clients secgrp

 

As security groups are stateful there is no need to explicitly cater for packet responses. However, it is best practice to also use NACLs on associated subnets. NACLs are stateless and will require outbound rules to explicitly cater for responses. The NACL rules can be implied from above. Likewise, any associated firewall rules that are needed can be inferred as reciprocals of the above. This model assumes that only on-premise Windows clients will connect to the on-premise AD and vice versa for AWS.

Once the service creation has completed, we need to connect to and configure the initial domain.

From the diagram in Figure 2 we have named the new AWS AD controller MSAD2012. In order to configure MSAD2012 we first need to connect to it. To do this we launched one of the new t2.nano Windows servers into the appropriate security group.

Open Advanced TCP/IP Settings from TCP/IPV4 properties’ page in network settings. Then add “test.aws” and “msad.test.aws” in “Append these DNS suffixes” section and promote them to the top. After that, put MSAD2012’s IP addresses,10.0.0.211 (using our example) in the DNS area on TCP/IPV4 properties’ page.

After DNS setup, choose to make the current instance become a member of domain msad.test.aws . A window will subsequently pop up for the username and password of the new domain. Use the admin account that you created during the initial Directory Service setup. After restarting the instance you should be able to log into it as part of the new domain.

As you are now essentially connected to the new domain, you can use the standard AD and DNS management tools to complete setting up the conditional forwarders and establishing trust. An easy to follow guide for this can be found on the official AWS site at the following link http://docs.aws.amazon.com/directoryservice/latest/admin-guide/setup_trust.html.

Finally, for those of you who are looking to extend an existing AD domain into the cloud, you can still launch EC2 instances, running as AD Domain controllers, across a VPN or dedicated private link. These EC2 instances are essentially configured and managed as Windows servers similar to their on-site equivalents. There is an established architectural pattern for this and a detailed overview of the necessary steps can be found at Steve Morad’s detailed tutorial on the official AWS site.

Figure 1. A high level overview of using EC2 to extend your domain.

In Summary

The AWS Directory Service running in full AD mode does work as advertised, however, there are a number of things that you should be aware before deploying it:

  1. At this stage, it is only available in Enterprise mode. This means that when you deploy it, you must configure it to run inside subnets spread over at least two AZs. Obviously, this is great for high availability in production environments.
  2. As a result of the Enterprise label, the costs associated with the service also make it a little less viable for smaller environments. For example, the service costs USD$0.48 per hour to run in the Sydney region. This is about 33% more expensive than configuring 2 x t2.large EC2 instances to run as redundant domain controllers. We don’t recommend you use t2 instances in production, however it seems running your own servers is definitely more economical in non-production environments.
  3. It seems that you cannot use the new service feature to extend an existing on-premise domain yet, for that you must still launch independent EC2 instances. You can create a new domain,federate it and establish trust with an on-premise forest, however a pure extension appears to not be an option at the moment. For our specific customer use case, this is not actually an issue, however it would be good to hear if anyone has done any further testing to get this working.

 


Cloudten Industries © is an Australian cloud practice and an Advanced consulting partner of AWS. We specialise in the design, delivery and support of secure cloud based solutions. Don’t hesitate to contact us if you have any queries about this post or any cloud related topic.