How to enable server-side LDAPS for your AWS Managed Microsoft AD directory

March 18, 2024: We have made minor updates and clarifications based on customer feedback to the post.

June 17, 2022: We simplified this post by removing all manual deployment processes and using only the Microsoft Public Key Infrastructure on AWS Quick Start.

January 10, 2022: We’ve updated this post with various minor edits.

March 29, 2021: We’ve updated this post to include two additional options for deploying the Microsoft Certificate Authority architecture: 1) using the Microsoft Public Key Infrastructure Quick Start to automate the process; and 2) using your existing on-premises PKI infrastructure.

August 5, 2020: We’ve made numerous updates to this post to better reflect best practices around Microsoft Certificate Authority deployments.

November 26, 2019: We’ve updated the language in this post to reflect new client-side LDAPS support in AWS Managed Microsoft AD.

By using the Lightweight Directory Access Protocol (LDAP) over SSL (LDAPS), you can encrypt LDAP communications between applications and AWS Directory Service for Microsoft Active Directory, also known as AWS Managed Microsoft AD. Applications can use the Active Directory LDAPS protocol to read from and write to sensitive attributes of Active Directory objects, which might include personally identifiable information (PII). LDAPS helps protect PII and other sensitive information exchanged through the LDAP protocol with AWS Managed Microsoft AD over all networks. All LDAP writes must occur over LDAPS.

To enable server-side LDAPS, you need a Microsoft Enterprise Certification Authority integrated with an AWS Managed Microsoft AD domain. You also need certificate templates configured and published for the AWS Managed Microsoft AD domain controllers. After you’ve enabled LDAPS, AWS Managed Microsoft AD can encrypt LDAP communications with LDAPS-enabled applications, Linux computers that use Secure Shell (SSH) authentication, applications such as Jira and Jenkins, and more.

In this post, we walk you through the process to enable server-side LDAPS with an AWS Managed Microsoft AD directory. Although there are multiple ways to deploy the public key infrastructure (PKI) architecture, this post uses the Microsoft Public Key Infrastructure on AWS Quick Start. We recommend you use the Quick Start because we designed it for reliably and consistently deployment of Microsoft based PKI infrastructure using best practices.

Solution overview

Before going into specific deployment steps, let’s cover a high-level overview of LDAPS deployment, some general background on certificate authority (CA) deployment models, and how to apply these models when deploying a Microsoft CA to enable LDAPS on AWS Managed Microsoft AD.

Overview of LDAPS deployment on AWS Managed Microsoft AD

LDAP-aware applications (known as LDAP clients) typically access LDAP servers using TCP or User Datagram Protocol (UDP) port 389. By default, LDAP communications on port 389 are unencrypted. LDAP clients have two standards for encrypting LDAP communications: LDAP over SSL on TCP port 636, or LDAP with StartTLS on port 389. AWS Managed Microsoft AD supports both standards when LDAPS is enabled on AWS Managed Microsoft AD domain controllers.

LDAPS with AWS Managed Microsoft AD requires a Microsoft enterprise CA to issue certificates to the AWS Managed Microsoft AD domain controllers using auto-enrollment. The current auto-enrollment period on AWS Managed Microsoft AD domain controllers is 30 minutes, which is shorter than the Microsoft OS default of 8 hours.

Background of CA deployment models

You can deploy CAs as part of a single-tier or multi-tier CA hierarchy. In a single-tier hierarchy, issued certificates come from the root of the hierarchy. A multi-tier hierarchy is a collection of CAs in a hierarchy where the certificates issued to computers and users come from subordinate CAs in the hierarchy, rather than the root.

Certificates issued by a CA include the certification path (hierarchy) of the CA. When a computer sends its certificate to another computer for verification, the receiving computer must have trusted the public certificate from the issuing CA and its hierarchy. If the CA that issued the certificate is part of a single-tier hierarchy, the receiver must trust the public certificate of the CA that issued the certificate. If the CA that issued the certificate is part of a multi-tier hierarchy, the receiver must trust the public certificates for all CAs that are in the hierarchy of the CA that issued the sender’s certificate. If the certificate came from a CA that’s in the receiver’s hierarchy’s trusted CA certificates, the receiver trusts the sender. Otherwise, the receiver rejects the sender.

How to deploy Microsoft CA to enable LDAPS on AWS Managed Microsoft AD

Microsoft Windows Server offers the ability to deploy a standalone or enterprise CA. Although you can configure either in single-tier or multi-tier hierarchies, only the enterprise CA integrates with Active Directory and offers auto-enrollment for certificate issuing. AWS Managed Microsoft AD domain controllers require automatic certificate enrollment. Server-side LDAPS with AWS Managed Microsoft AD doesn’t support certificates that are issued by a standalone CA. Nor does it support certificates issued by a third-party certification authority. AWS recommends a multi-tier Microsoft CA trust hierarchy consisting of a standalone root CA and enterprise subordinate CA in a two-tier hierarchy.

In a two-tier hierarchy, you must issue a certificate from the standalone root CA to the enterprise subordinate CA, which gives the enterprise subordinate CA the right to issue certificates on behalf of the root CA. This makes your enterprise subordinate CA part of the standalone root CA’s hierarchy. You also need to deploy the public certificates of the standalone root CA and enterprise subordinate CA to the trusted root store of all computers in your network, which tells the computers to trust certificates issued by the CAs.

In such a hierarchy, the standalone root CA is offline (inaccessible to other computers in the network) to protect the root of the hierarchy. The enterprise subordinate CA, is online to issue certificates on behalf of the standalone root CA. A multi-tier hierarchy helps increase security in the event of an enterprise subordinate CA compromise. You can revoke certificates issued by the compromised enterprise subordinate CA and create a new enterprise subordinate CA from the standalone root CA. To learn more about setting up a secure CA hierarchy, see Securing PKI: Planning a CA Hierarchy.

Steps to enable LDAPS for your AWS Managed Microsoft AD directory

For the rest of this post, we walk you through the steps to enable LDAPS for your AWS Managed Microsoft AD directory.

Prerequisites

The instructions in this post assume that you already have the following components running:

• An active AWS Managed Microsoft AD directory. To learn how to deploy AWS Managed Microsoft AD, see the AWS Managed Microsoft AD workshop module.
  

  Note: I use the domain name of corp.example.com for all examples in this post.

• An Amazon Elastic Compute Cloud (Amazon EC2) Windows Server instance (referred to as the MGMT EC2 instance in this post) joined to your AWS Managed Microsoft AD directory with the Active Directory Administration Tools installed. To learn how to join and configure an instance for your AWS Managed Microsoft AD, see the AWS Managed Microsoft AD workshop.

The solution setup

Figure 1 illustrates the components needed to enable LDAPS for AWS Managed Microsoft AD.
 

Figure 1: Solution diagram

Below, I summarize the deployment process:

1. Collect DNS resolver IP addresses of the AWS Managed Microsoft AD.
2. Create an AWS Secrets Manager secret to store the PKI deployment service account.
3. Set up an Amazon Simple Storage Service (Amazon S3) bucket to store the certificate revocation lists (CRLs) and public certificates of both CAs.
4. Deploy an offline root CA and enterprise subordinate CA by using the Microsoft Public Key Infrastructure Quick Start CloudFormation template.
5. Configure the AWS security group for the AWS Managed Microsoft AD directory to connect to the enterprise subordinate CA for certificate requests.
6. Test LDAPS access by using the LDP.exe tool.

The next part of this post covers these steps in detail. This post uses the names of components—such as MGMT EC2 instance—and refers to users—such as Admin—to illustrate who performs the steps. All component names and user names in this post are for illustrative purposes only.

Deploy the solution

In this section, you perform the deployment process. You perform three manual steps, and then the Microsoft Public Key Infrastructure Quick Start CloudFormation template automates the rest.

Step 1: Collect DNS IP addresses for AWS Managed Microsoft AD

To deploy the Microsoft Public Key Infrastructure Quick Start CloudFormation template, you first need to gather the DNS IP addresses of the AWS Managed Microsoft AD domain controllers.

To get the DNS IP addresses

1. In the AWS Directory Service console, choose Directories.
2. Choose the directory ID of the AWS Managed Microsoft AD. The directory ID looks like: d-12345678e9.
3. In the Networking & security tab of your directory, under Networking details, note the DNS address values. You will need them later in this post.
    
   
   

   Figure 2: DNS IP addresses of AWS Managed Microsoft AD

Step 2: Create a Secrets Manager secret to store the PKI deployment service account information

To use a Microsoft enterprise CA with AWS Managed Microsoft AD, AWS created an AD security group named AWS Delegated Enterprise Certificate Authority Administrators, which has been delegated permissions to install and administer a Microsoft enterprise CA. By default, the directory Admin account is part of this group and can add other users or groups to the security group.

In this section, you store the Admin account credentials in a Secrets Manager secret. Automation uses this secret to create the CA infrastructure.

Note: if you prefer, you can use a different account instead of the Admin account. If you use a different account, make sure that it is a member of the AWS Delegated Enterprise Certificate Authority Administrators and AWS Delegated Administrators AD security groups.

To create the Secrets Manager secret

1. In the Secrets Manager console, choose Store a new secret.
2. On the Store a new secret page, under Select secret type, choose Other type of secret.
3. Under Key/value pairs, do:
   1. In the first field, enter username, and in the same row, in the next field, enter Admin.
   2. Choose + Add row.
   3. On the new row, in the first field, enter password, and on the same row, in the next field, enter a password for Admin.
   4. Under Encryption key, choose a key of your choice.
   5. Choose Next.
       
      
      

      Figure 3: Secrets Manager secret creation

4. On the Store a new secret page, for Secret name, enter a name for the secret, leave the default settings for the remaining fields, and choose Next on each of the next two pages.
5. Review the settings, and then choose Store to save your changes. The Secrets Manager console returns you to the list of secrets in your account with your new secret included in the list.
6. Choose your newly created secret from the list and note the Secret ARN value. You will need it in the next section.
    
   
   

   Figure 4: Secrets Manager secret ARN

Step 3: Set up an S3 bucket to store certificate revocation lists and certificates

For all examples in this post, we use the S3 bucket named corp-example-com.

To set up the S3 bucket

1. Create or use an existing S3 bucket to store the public certificates and certificate revocation lists (CRL) for both CAs. See creating a bucket for S3 bucket creation steps.
2. Make sure that public access isn’t blocked. See set S3 bucket public access.

Note: You aren’t required to store the certificates and CRLs in an S3 bucket. If you don’t use an S3 bucket, it will host the CRLs in a file share and Internet Information Services (IIS) website on the enterprise CA.

Step 4: Deploy an offline root CA and enterprise subordinate CA by using the Microsoft Public Key Infrastructure Quick Start template

In this section, you deploy an offline root CA and enterprise subordinate CA by using the Microsoft Public Key Infrastructure Quick Start. Because you use a Quick Start template for this deployment, you only need to enter the following information—you can change the default values for any fields not explicitly mentioned here.

To deploy the CAs with the Microsoft Public Key Infrastructure Quick Start

1. In the AWS CloudFormation console, choose Create stack and then do the following:
   • For Prepare template, select Template is ready.
   • For Template source, select Amazon S3 URL.
   • For Amazon S3 URL, enter:  https://aws-quickstart.s3.amazonaws.com/quickstart-microsoft-pki/templates/microsoft-pki.template.yaml
   • Choose Next.
2. Specify the stack details as follows:
   • For VPC CIDR, enter the CIDR of the VPC where your AWS Managed Microsoft AD directory is deployed to.
   • For VPC ID, select the VPC where your AWS Managed Microsoft AD directory resides.
   • For CA(s) Subnet ID, select a subnet in the VPC where your AWS Managed Microsoft AD directory is deployed to.
   • For Domain Members Security Group ID, select an existing security group that allows communication with the AWS Managed Microsoft AD directory.
   • For Key Pair Name, select an EC2 key pair in your account.
   • For Active Directory Domain Services Type, select AWSManaged.
     

     Important: You must select AWSManaged for this field. If you select SelfManaged instead of AWSManaged, the deployment will fail.

   • For Domain FQDN DNS Name, enter the DNS name of the AWS Managed Microsoft AD directory. In this example, I use corp.example.com.
   • For Domain NetBIOS Name, enter the NetBIOS name of the AWS Managed Microsoft AD directory. In this example, I use CORP.
   • For IP used for DNS (Must be accessible), enter the IP address of one of the AWS Managed Microsoft AD directory domain controllers. You collected this information in Step 1: Collect DNS IP addresses for AWS Managed Microsoft AD.
   • For IP used for DNS (Must be accessible), enter the IP address of the other AWS Managed Microsoft AD directory domain controller. You collected this information in Step 1: Collect DNS IP addresses for AWS Managed Microsoft AD.
   • For Secret ARN Containing CA Install Credentials, enter the Secrets Manager secret created in  Step 2: Create a Secrets Manager secret to store the PKI deployment service account information.
   • For CA Deployment Type, select Two-Tier.
   • For Use S3 for CA CRL Location, select Yes.
     

     Note: if you don’t want to use an S3 bucket to store the CRLs, set Use S3 for CA CRL Location to No. When No is selected, the Quick Start stores and hosts the CRLs on the enterprise CA itself.

   • For CA CRL S3 Bucket Name, enter the name of the bucket created in Step 3: Set up S3 bucket to store certificate revocation lists (CRLs) and certificates.
     

     Note: if you set Use S3 for CA CRL Location to No, leave this field to the default value of examplebucket.

   • Select Next on the current screen and the following screen.
   • Check the box next to each of the following statements.
     • I acknowledge that AWS CloudFormation might create IAM resources with custom names.
     • I acknowledge that AWS CloudFormation might require the following capability: CAPABILITY_AUTO_EXPAND.
   • Choose Create stack.

Figure 5: CloudFormation create stack

It should take 20 to 30 minutes for the CAs to deploy. While the CloudFormation stack is deploying, feel free to move onto the next step.

Step 5: Configure AWS security group rules

In this step, you configure AWS security group rules so that your directory domain controllers can connect to the enterprise subordinate CA to request a certificate. To do this, you must add outbound rules to the directory’s AWS security group to allow outbound traffic to the private IP of the enterprise subordinate CA so that the directory domain controllers can request certificates from the enterprise subordinate CA.

To configure AWS security group rules

1. In the navigation pane of the AWS VPC console, under the Security heading, choose Security Groups.
2. Select the AWS security group of your AWS Managed Microsoft AD directory. The security group name is formatted like the following: d-1234567890_controllers.
3. Switch to the Outbound rules tab, and choose Edit outbound rules.
4. Choose Add rule and then do the following:
   1. For Type, select Custom TCP.
   2. For Port range, enter 135.
   3. For Destination, select Custom and then enter the private IP assigned to the enterprise CA instance.
   4. Repeat steps a–c but change the Port range value for step b to 49152 – 65535.
5. Choose Save rules.

Figure 6: Modify AWS Managed Microsoft AD security group

You have completed the configuration of AWS security group rules to allow traffic between your directory domain controllers and the enterprise CA.

The AWS Managed Microsoft AD domain controllers will automatically request a certificate based on the template named LdapOverSSL-QS that the Microsoft Public Key Infrastructure on AWS Quick Start created. It can take up to 30 minutes for the directory domain controllers to auto-enroll the certificates. After it issued the certificates to the directory domain controllers, LDAPS will be functional. This completes the setup of LDAPS for the AWS Managed Microsoft AD directory. The LDAP service on the directory is now ready to accept LDAPS connections.

Step 6: Verify certificates have been issued to the AWS Managed Microsoft AD domain controllers

In this step, you will log into the enterprise CA to validate it has issued certificates to the AWS Managed Microsoft AD domain controllers.

To check the certificate issuance

1. Log in to ENTCA1 EC2 Instance as Admin.
2. Launch the Enterprise PKI MMC by choosing Start and entering pkiview.msc.
3. In the Enterprise PKI MMC left-hand navigation pane select ORCA1 (the offline root CA) and you will see the status for all items in the details pane listed as OK.
4. In the left-hand navigation pane expand ORCA1 and select ENTCA1(the enterprise CA). You will see the status for all items listed in the details pane as OK for that CA as well.
   

   Figure 8: Enterprise PKI MMC

5. Right click on ENCA1 and select Manage CA… to open the Certificate Authority MMC for ENTCA1.
6. In the Certificate Authority MMC left-hand navigation pane expand ENTCA1 and select Issued Certificates.
7. You will see all certificates issued by the CA. Specifically, you are looking for certificates with the template name of LdapOverSSL-QS. This is the certificate template CloudFormation created and is issued to domain controllers.

Note the AWS Managed AD used in this post has 2 domain controllers, so there are only 2 certificates issued. There should be a certificate issued to each domain controller. In environments with over 2, there will be more certificates issued.

Figure 9: Certificate Authority MMC

Step 7: Test LDAPS access by using the LDP tool

In this step, you test the LDAPS connection to the AWS Managed Microsoft AD directory by using the LDP tool. The LDP tool is available on the MGMT EC2 Instance machine where you installed Active Directory Administration Tools. Before you test the LDAPS connection, you must wait up to 30 minutes for the enterprise subordinate CA to issue a certificate to your domain controllers. To test LDAPS, you connect to one of the domain controllers using port 636.

To test the LDAPS connection

1. Log in to MGMT EC2 Instance as Admin.
2. Launch the LDP.exe tool by choosing Start and entering LDP.exe.
3. In the LDP tool, choose Connection > Connect.
    
   
   

   Figure 10: LDP Connect

4. In the Connect section, do:
   1. For Server, enter the DNS name of your domain. In this example, the server is corp.example.com.
   2. For Port, enter 636.
   3. Select SSL.
   4. Choose OK to connect to the directory through LDAPS.
       
      
      

      Figure 11: LDP Connect input

5. You should see the following message to confirm that your LDAPS connection is now open.

Figure 11: LDP successful LDAPS connection

You have completed the setup of LDAPS for your AWS Managed Microsoft AD directory. You can now encrypt LDAP communications between your Windows and Linux applications and your AWS Managed Microsoft AD directory using LDAPS.

Conclusion

In this post, you learned how to enable LDAPS for your AWS Managed Microsoft AD directory. Enabling LDAPS helps you protect PII, and other sensitive information exchanged over untrusted networks between your Windows and Linux applications and your AWS Managed Microsoft AD. To learn more about how to use AWS Managed Microsoft AD, see the Directory Service documentation. For general information and pricing, see the Directory Service home page.

To enable LDAPS communications between AWS applications, such as Amazon WorkSpaces and a trusted self-managed active directory, use client-side LDAPS support in AWS Managed Microsoft AD.

If you have feedback about this post, submit a comment in the Comments section below. If you have implementation or troubleshooting questions, start a new thread on the Directory Service forum or contact AWS Support.

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.