I’m back again with another entry in my deep dive into AWS Managed Microsoft Active Directory (AD).  So far I’ve provided an overview of the service, covered how to configure the service, and analyzed the Active Directory default configuration such as the directory structure, security principals, password policies, and group policy setup by Amazon for new instances.  In this post I’m going to look at the setup of LDAPS and how Amazon supports configuration of it in the delegated model they’ve setup for the service.

Those of you that have supported a Windows AD environment will be quite familiar with the wonders and sometimes pain of the Lightweight Directory Access Protocol (LDAP).  Prior to the modern directories such as AWS Cloud Directory, Azure Active Directory the LDAP protocol served critical roles by providing both authentication and a method of which to work with data stored in directory data stores such as Windows AD.  For better or worse the protocol is still relevant today when working with Windows AD for both of the above capabilities (less for authentication these days if you stay away from backwards-thinking vendors).  LDAP servers listen on port 389 and 636 with 389 maintaining traffic in the clear (although there are exceptions where data is encrypted in transit such as Microsoft’s usage of Kerberos encryption or the use of StartTLS (credit to my friend Chris Jasset for catching my omission of StartTLS)) and 636 (LDAPS) providing encryption in transit via an SSL tunnel (hopefully not anymore) or a TLS tunnel.

Windows AD maintains that pattern and serves up the content of its data store over LDAP over ports 389 and 636 and additionally ports 3268 and 3269 for global catalog queries.  In the assume breach days we’re living in, we as security professionals want to protect our data as it flows over the network which means we’ll more often than not (exceptions are again Kerberos encryption usage mentioned above) be using LDAPS over ports 636 or 3269.  To provide that secure tunnel the domain controllers will need to be setup with a digital certificate issued by a trusted certificate authority (CA).    Domain Controllers have unique requirements for the certificates they use.  If you’re using  Active Directory Certificate Services (AD CS) Microsoft takes care of providing the certificate template for you.

So how do you provision a certificate to a Domain Controller’s certificate store when you don’t have administrative privileges such as the case for a managed service like AWS Managed Active Directory?   For Microsoft Azure Active Directory Domain Services (AAD DS) the public certificate and private key are uploaded via a web page in the Azure Portal which is a solid way of doing it.  Amazon went in a different and instead takes advantage of certificate autoenrollment.  If you’re not familiar with autoenrollment take a read through this blog.  In short, it’s an automated way to distribute certificates and eliminate some of the overheard of manually going through the typical certificate lifecycle which may contain manual steps.

If we bounce back to the member server in my managed domain, open the Group Policy Management Console (GPMC), and navigate to the settings tab of the AWS Managed Active Directory Policy we see that autoenrollment has been enabled on the domain controllers.  This setting explains why Amazon requires a member server joined to the managed domain be configured running AD CS.  Once the AD CS instance is setup, the CA has been configured either to as a root or subordinate CA, and a proper template is enabled for autoenrollment, the domain controllers will request the appropriate certificate and will begin using it for LDAPS.

If you’ve ever worked with AD CS you may be asking yourself how you’ll be able to install AD CS in a domain where you aren’t a domain administrator when the Microsoft documentation specifically states you need to be a member of the Enterprise Admins and root domains Domain Admins group.  Well folks that is where the AWS Delegated Enterprise Certificate Authority Administrators group comes into play.  Amazon has modified the forest to delegate the appropriate permissions to install AD CS in a domain environment.  If we navigate to the CN=Public Key Services, CN=Services, CN=Configuration using ADSIEdit and view the Security for the container we see this group has been granted full permissions over the node allowing the necessary objects to be populated underneath it.

I found it interesting that in the instructions provided by Amazon for enabling LDAPS the instructions state the Domain Controller certificate template needs to modified to remove the Client Authentication EKU.  I’d be interested in knowing the reason for modifying the Domain Controller certificate.  If I had to guess it’s to prevent the domain controller from using the certificate outside of LDAPS such as for mutual authentication during smart card logon.  Notice that from this article domain controllers only require the Server Authentication EKU when a certificate is only used to secure LDAPS.

I’ve gone ahead and installed AD CS on SERVER01 as an Enterprise root CA and thanks to the delegation model, the CA is provisioned with all the necessary goodness in CN=Public Key Services.  I also created the new certificate template following the instructions from Amazon.  The last step is to configure the traffic flow such that the managed domain controllers can contact the CA to request a certificate.  The Amazon instructions actually have a typo in them.  On Step 4 it instructs you to modify the security group for your CA and to create a new inbound rule allowing all traffic from the source of your CA’s AWS Security group.  The correct security group is actually the security group automatically configured by Amazon that is associated with the managed Active Directory instance.

At this point you’ll need to wait a few hours for the managed domain controllers to detect the new certificates available for autoenrollment.  Mine actually only took about an hour to roll the certificates out.

To test the service I opened LDP.EXE and established a secure session over port 636 and all worked as expected.

Since I’m a bit OCD I also pulled the certificate using openssl to validate it’s been issued by my CA.  As seen in the screenshot below the certificate was issued by the geekintheweeds-CA which is the CA I setup earlier.

Beyond the instructions Amazon provides, you’ll also want to give some thought as to how you’re going to handle revocation checks. Keep in mind that by default AD CS stores revocation information in AD. If you have applications configured to check for revocation remember to ensure those apps can communicate with the domain controllers over port 389 so design your security groups with this in mind.

Well folks that will wrap up this post. Now that LDAPS is configured, I’ll begin the tests looking at the protocols and ciphers supported when accessing LDAPS as well as examining the versions of NTLM supported and the encryption algorithms supported with Kerberos.

See you next post!