AWS Security Blog

How to Enable Server-Side LDAPS for Your AWS Microsoft AD Directory

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.


Starting today, you can encrypt the Lightweight Directory Access Protocol (LDAP) communications between your applications and AWS Directory Service for Microsoft Active Directory, also known as AWS Microsoft AD. Many commercial and homegrown applications use Active Directory’s (AD) LDAP service to read and write sensitive information about users and devices, including personally identifiable information (PII). Now, you can encrypt your AWS Microsoft AD LDAP communications end to end to protect this information by using LDAP Over Secure Sockets Layer (SSL)/Transport Layer Security (TLS), also called LDAPS. This helps you protect PII and other sensitive information exchanged with AWS Microsoft AD over untrusted networks.

To enable server-side LDAPS, you need to add a Microsoft Enterprise Certification Authority (CA) server to your AWS Microsoft AD domain and configure certificate templates for your domain controllers. After you have enabled LDAPS, AWS Microsoft AD encrypts communications with LDAPS-enabled Windows applications, Linux computers that use Secure Shell (SSH) authentication, and applications such as Jira and Jenkins.

Note: To enable LDAPS communications between AWS applications, such as Amazon Workspaces or Amazon Chime, and your self-managed AD, use client-side LDAPS support in AWS Microsoft AD.

In this post, I show how to enable server-side LDAPS for your AWS Microsoft AD directory in seven steps:

  1. Delegate permissions to CA administrators.
  2. Setup an S3 Bucket to store certificate revocation lists (CRLs) and certificates.
  3. Deploy a Microsoft Offline Root CA.
  4. Deploy a Microsoft Enterprise Subordinate CA to your AWS Microsoft AD directory.
  5. Create a certificate template to be issued to domain controllers.
  6. Configure AWS security group rules to allow AWS Microsoft AD directory to communicate with the Microsoft Enterprise Subordinate CA.
  7. Test LDAPS access using the LDP tool.

Assumptions

For this post, I assume you are familiar with the following:

Solution overview

Before going into specific deployment steps, I will provide a high-level overview of deploying LDAPS. I cover how you enable LDAPS on AWS Microsoft AD. In addition, I provide some general background about CA deployment models and explain how to apply these models when deploying Microsoft CA to enable LDAPS on AWS Microsoft AD.

How you enable LDAPS on AWS Microsoft AD

LDAP-aware applications (LDAP clients) typically access LDAP servers using Transmission Control Protocol (TCP) port 389. By default, LDAP communications using port 389 are unencrypted. However, many LDAP clients use one of two standards to encrypt LDAP communications: LDAP over SSL on port 636, and LDAP with StartTLS on port 389. If an LDAP client uses port 636, the LDAP server encrypts all traffic unconditionally with SSL. If an LDAP client issues a StartTLS command when setting up the LDAP session on port 389, the LDAP server encrypts all traffic to that client with TLS. AWS Microsoft AD now supports both encryption standards when you enable LDAPS on your AWS Microsoft AD domain controllers.

You enable LDAPS on your AWS Microsoft AD domain controllers by installing a digital certificate that a trusted CA issued. Though Windows servers have different methods for installing certificates, LDAPS with AWS Microsoft AD requires you to add a Microsoft Enterprise CA to your AWS Microsoft AD domain and deploy the certificate through auto-enrollment from the Microsoft Enterprise CA. The installed certificate enables the LDAP service running on domain controllers to listen for and negotiate LDAP encryption on port 636 (LDAP over SSL) and port 389 (LDAP with StartTLS).

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, all certificates come from the root of the hierarchy. In a multi-tier hierarchy, you organize a collection of CAs in a hierarchy and the certificates sent to computers and users come from subordinate CAs in the hierarchy (not the root).

Certificates issued by a CA identify the hierarchy to which the CA belongs. When a computer sends its certificate to another computer for verification, the receiving computer must have the public certificate from the CAs in the same hierarchy as the sender. If the CA that issued the certificate is part of a single-tier hierarchy, the receiver must obtain 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 can obtain a public certificate for all the CAs that are in the same hierarchy as the CA that issued the certificate. If the receiver can verify that the certificate came from a CA that is in the hierarchy of the receiver’s “trusted” public CA certificates, the receiver trusts the sender. Otherwise, the receiver rejects the sender.

Deploying Microsoft CA to enable LDAPS on AWS Microsoft AD

Microsoft Windows Server offers the ability to deploy a Standalone CA or an Enterprise CA. Though you can configure either as single-tier or multi-tier hierarchies, only the Enterprise CA integrates with AD and offers auto-enrollment for certificate deployment. Because you cannot sign in to run commands on your AWS Microsoft AD domain controllers, an automatic certificate enrollment model is required. Therefore, AWS Microsoft AD requires the certificate to come from a Microsoft Enterprise CA that you configure to work in your directory. When you install the Microsoft Enterprise CA, you can configure it to be part of a single-tier hierarchy or a multi-tier hierarchy. As a best practice, AWS recommends a multi-tier Microsoft CA trust hierarchy consisting of a Standalone Root CA and an Enterprise Subordinate CA. This post covers only this two-tier hierarchy.

In a multi-tier hierarchy, you configure your Enterprise Subordinate CA by importing a certificate from the Standalone Root CA. You must issue a certificate from the Standalone Root CA such that the certificate gives your 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 should also deploy the Standalone Root CA’s public certificate to all of your computers, which tells all your computers to trust certificates that your Standalone Root CA issues and to trust certificates from any authorized Enterprise Subordinate CA.

In such a hierarchy, you typically leave your Standalone Root CA offline (inaccessible to other computers in the network) to protect the root of your hierarchy. You leave the Enterprise Subordinate CA online so that it can issue certificates on behalf of the Standalone Root CA. This multi-tier hierarchy increases security because if someone compromises your Enterprise Subordinate CA, you can revoke all certificates it issued and set up a new Enterprise Subordinate CA from your offline Standalone Root CA. To learn more about setting up a secure CA hierarchy, see Securing PKI: Planning a CA Hierarchy.

When a Microsoft CA is part of your AD domain, you can configure and publish certificate templates to be issued. These templates become visible to client computers through AD. If a client’s profile matches a template, the client requests a certificate from the Microsoft CA that matches the template. Microsoft calls this process auto-enrollment, and it simplifies certificate deployment. To enable LDAPS on your AWS Microsoft AD domain controllers, you create and publish a certificate template on the Microsoft Enterprise Subordinate CA that generates SSL and TLS-compatible certificates. The domain controllers see the template and automatically import a certificate of that type from the Microsoft Enterprise Subordinate CA. The imported certificate enables LDAP encryption.

Steps to enable LDAPS for your AWS Microsoft AD directory

The rest of this post is composed of the steps for enabling LDAPS for your AWS Microsoft AD directory. First, though, I explain which components you must have running to deploy this solution successfully. I also explain how this solution works and include an architecture diagram.

Prerequisites

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

  1. An active AWS Microsoft AD directory – To create a directory, follow the steps in Create an AWS Microsoft AD directory.
  2. An Amazon EC2 for Windows Server instance for managing users and groups in your directory – This instance needs to be joined to your AWS Microsoft AD domain and have Active Directory Administration Tools installed. Active Directory Administration Tools installs Active Directory Administrative Center and the LDP tool.

The solution setup

The following diagram illustrates the setup with the steps you need to follow to enable LDAPS for AWS Microsoft AD. You will learn how to set up an offline Standalone Root CA (in this case, RootCA) and an Enterprise Subordinate CA (in this case, SubordinateCA) to join to your AWS Microsoft AD domain (in this case, corp.example.com). You also will learn how to create a certificate template on SubordinateCA and configure AWS security group rules to enable LDAPS for your directory.

Note that you may already have a Root CA or a multi-tier CA hierarchy in your on-premises network that you can use for creating SubordinateCA instead of creating a new Standalone Root CA. If you choose to use your existing CA hierarchy, you must have administrative permissions on your Root CA to issue a certificate to SubordinateCA.

Lastly, I also already created an Amazon EC2 instance (in this case, Management) that I use to manage users and test the LDAPS connection. I join this instance to the AWS Microsoft AD directory domain.

Figure 1: Diagram showing the process discussed in this post

Here is how the process works:

  1. Delegate permissions to CA administrators (in this case, CAAdmin) so that they can join a Microsoft enterprise CA to your AWS Microsoft AD domain and configure it as a subordinate CA.
  2. Setup an S3 Bucket to the store certificate revocation lists (CRLs) and certificates of both CAs.
  3. Deploy a Microsoft Windows Server Standalone Root CA (in this case, RootCA) so that it can issue a certificate to SubordinateCA that grants SubordinateCA permissions to issue certificates. This step includes installing the Microsoft Standalone Root CA and uploading the certificate revocation lists (CRLs) and certificates to the S3 Bucket created in Step 2.
  4. Deploy a Microsoft Windows Server Enterprise Subordinate CA to your AWS Microsoft AD directory (in this case, SubordinateCA) so that it can issue certificates to your directory’s domain controllers to enable LDAPS. This step includes joining SubordinateCA to your directory domain, installing the Microsoft enterprise CA, and obtaining a certificate from RootCA that grants SubordinateCA permissions to issue certificates, and uploading the certificate revocation lists (CRLs) and certificates to the S3 Bucket created in Step 2.
  5. Create a certificate template to be issued to domain controllers (in this case, LDAPOverSSL) with auto-enrollment configured so that your AWS Microsoft AD directory domain controllers can obtain certificates through auto-enrollment to enable LDAPS.
  6. Configure AWS security group rules so that AWS Microsoft AD directory domain controllers can connect to the Enterprise Subordinate CA to request certificates.
  7. Test LDAPS access by using the LDP tool.

I now will show you these steps in detail. I use the names of components—such as RootCA, SubordinateCA, and Management—and refer to users—such as Admin and CAAdmin—to illustrate who performs these steps. All component names and user names in this post are used for illustrative purposes only.

Deploy the solution

Step 1: Delegate permissions to CA administrators

In this step, you will delegate permissions to your users who manage your Enterprise CAs. Your users then can join an Enterprise CA to your AWS Microsoft AD domain and create the certificate template in your CA.

To enable use with a Microsoft Enterprise CA, AWS added a new built-in AD security group called AWS Delegated Enterprise Certificate Authority Administrators that has delegated permissions to install and administer a Microsoft enterprise CA. By default, your directory Admin is part of the new group and can add other users or groups in your AWS Microsoft AD directory to this security group. If you have trust with your on-premises AD directory, you can also delegate CA administrative permissions to your on-premises users by adding on-premises AD users or global groups to this new AD security group.

To create a new user (in this case CAAdmin) in your directory and add this user to the AWS Delegated Enterprise Certificate Authority Administrators security group, follow these steps:

  1. Sign in to the Management instance using RDP with the user name Admin and the password that you set for the Admin user when you created your directory.
  2. Launch the Microsoft Windows Server Manager on the Management instance and navigate to Tools > Active Directory Users and Computers.

    Figure 2: Screnshot of the menu including the 'Active Directory Users and Computers' choice

  3. Switch to the tree view and navigate to corp.example.com > CORP > Users. Right-click Users and choose New > User.

    Figure 3: Screenshot of choosing New < User

  4. Add a new user with the First name CA, Last name Admin, and User logon name CAAdmin.

    Figure 4: Screenshot of completing the 'New Object - User' boxes

  5. In the Active Directory Users and Computers tool, navigate to corp.example.com > AWS Delegated Groups. In the right pane, right-click AWS Delegated Enterprise Certificate Authority Administrators and choose Properties.

    Figure 5

  6. In the AWS Delegated Enterprise Certificate Authority Administration window, switch to the Members tab and choose Add.

    Figure 6

  7. In the Enter the object names to select box, type CAAdmin and choose OK.

    Figure 7: Screenshot showing the 'Enter the object names to select' box

  8. In the next window, choose OK to add CAAdmin to the AWS Delegated Enterprise Certificate Authority Administrators security group.

    Figure 8: Screenshot of adding "CA Admin" to the 'AWS Delegated Enterprise Certificate Authority Administrators' security group

  9. Also add CAAdmin to the AWS Delegated Server Administrators security group so that CAAdmin can RDP in to the Microsoft Enterprise CA machine.

 You have granted CAAdmin permissions to join a Microsoft Enterprise CA to your AWS Microsoft AD directory domain.

Step 2: Setup S3 Bucket to Store Certificate Revocation Lists (CRLs) and Certificates

  1. Create an S3 Bucket that will be used to store both CA’s certificates and certificate revocations lists (CRL). See here for steps on how to create an S3 bucket.
  2. Ensure public access is NOT blocked. See here how to set S3 bucket public access.
  3. Create three (3) folders named Root, Subordinate, and Private. See here for steps on how to create S3 folders.

    Note: For all examples in this guide, we will be using the S3 bucket named corp-example-com.

Step 3: Install and Configure an Offline CA

Note: If you already have a Root CA that you would like to use, you can move on to Step 4.

In this step, you set up a Microsoft Standalone Root CA. I will summarize the process first and then walk through the steps.

First, you create an Amazon EC2 for Windows Server instance called RootCA. You then install and configure the Microsoft Standalone Root CA service on RootCA and it will be ready to issue certificates to subordinate CAs.

Step 3a: Install Standalone Root CA

    1. Set up an Amazon EC2 instance joined to your AWS Microsoft AD directory domain – Create an Amazon EC2 for Windows Server 2019 instance to use as a Standalone Root CA. For this example, the machine name is RootCA.
    2. Open Windows PowerShell (Admin) and run the following command.
      
      & notepad.exe c:\Windows\CAPolicy.inf
      

      Note: For more information on the CAPolicy.inf syntax see here.

    3. When prompted to create a new file, select Yes.
    4. Enter the following as the contents of the file:
      
      [Version]
      Signature="$Windows NT$"
      [Certsrv_Server]
      RenewalKeyLength=2048
      RenewalValidityPeriod=Years
      RenewalValidityPeriodUnits=20
      CRLPeriod=Weeks
      CRLPeriodUnits=26
      CRLDeltaPeriod=Days
      CRLDeltaPeriodUnits=0
      AlternateSignatureAlgorithm=0
      [CRLDistributionPoint]
      [AuthorityInformationAccess]
      
    5. Select Save As. Ensure the following:
      • File name is set to CAPolicy.inf
      • Save as type is set to All Files
      • Encoding is ANSI
    6. When you are prompted to overwrite the file, select Yes.
    7. Open Server Manager, select Manage, and then select Add Roles and Features.

      Figure 9

    8. On the Before you begin screen, select Next.

      Figure 10

    9. On the Select installation type screen, ensure the default selection of Role-based or feature-based installation is selected. Select Next.

      Figure 11

    10. On the Select destination server screen, ensure that RootCA is selected and then select Next.

      Figure 12

    11. On the Select server roles screen, select the Active Directory Certificate Services role.
    12. When prompted to install Remote Server Administration Tools, select Add Features. Select Next.

      Figure 13

    13. On the Select features screen, select Next.

      Figure 14

    14. On the Active Directory Certificate Services screen, select Next.

      Figure 15

    15. On the Select role services screen, the Certification Authority role is selected by default. Select Next.

      Figure 16

    16. On the Confirm installation selections screen, verify the information and then select Install.

      Figure 17

    17. Wait for the installation to complete. The installation progress screen is displayed while the binary files for the CA are installed. When the binary file installation is complete, select the Configure Active Directory Certificate Services on the destination server link.

      Figure 18

    18. On the Credentials screen, you should see that the ROOTCA\Administrator is displayed in the Credentials box. Select Next.

      Figure 19

    19. On the Role Services screen, select Certification Authority. This is the only available selection when only the binary files for the certification authority role are installed on the server. Select Next.

      Figure 20

    20. The only selection available on the Setup Type screen is Standalone CA. This is because the account used to install is a member of the local Administrators group and the server is not a member of an Active Directory Domain Services (AD DS) domain. Select Next.

      Figure 21

    21. On the CA Type screen, Root CA is selected by default. Select Next.

      Figure 22

    22. On the Private Key screen, leave the default selection to Create a new private key selected. Select Next.

      Figure 23

    23. On the Cryptography for CA screen, ensure that the cryptographic provider is RSA#Microsoft Software Key Storage Provider, the key length is set to 2048, and the hash algorithm is set to SHA256. Then select Next.

      Note: Large key character lengths provide optimal security; however, they can impact server performance and might not be compatible with legacy applications. It is recommended that you keep the default setting of 2048.

      Figure 24

    24. On the CA Name screen, in the Common name for this CA text box, type ROOTCA-CA and then select Next.

      Figure 25

    25. On the Validity Period screen, enter 20 for the number of Years for the certificate to be valid and then select Next.

      Note: You can select a time value (Years, Months, Weeks, or Days). Something to note whatever you set this value to is the maximum validity period for all certificates this CA will issue.

      Figure 26

    26. On the CA Database screen, leave the default locations for the database and database log files. Select Next.

      Figure 27

    27. On the Confirmation screen, select Configure.

      Figure 28

    28. The Progress screen is displayed during the configuration processing, then the Results screen appears. Select Close. If the Installation progress screen is still open, select Close on that screen, as well.

Figure 29
Figure 30

Step 3b: Configure Offline Root CA

  1. From a Windows PowerShell (Admin) prompt, run the following:
    1. The following command will remove all CRL Distribution Points except for the one located in C:\Windows\system32\CertSrv\CertEnroll
      
      Get-CACRLDistributionPoint | Where-Object { $_.Uri -like '*ldap*' -or $_.Uri -like '*http*' -or $_.Uri -like '*file*' } | Remove-CACRLDistributionPoint -Force
      
    2. The following command will remove all Authority Information Access except for the one located in C:\Windows\system32\CertSrv\CertEnroll
      
      Get-CAAuthorityInformationAccess | Where-Object { $_.Uri -like '*ldap*' -or $_.Uri -like '*http*' -or $_.Uri -like '*file*' } | Remove-CAAuthorityInformationAccess -Force
      
    3. The following command will add a new CRL Distribution Point located in the S3 bucket defined in Step 2: Setup S3 Bucket to Store Certificate Revocation Lists (CRLs) and Certificates. You will need to replace corp-example-com.s3-us-west-2.amazonaws.com with the URL to your bucket.
      
      Add-CACRLDistributionPoint -Uri "http://corp-example-com.s3-us-west-2.amazonaws.com/Root/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl" -AddToCertificateCDP -Force 
      
    4. The following command will add a new Authority Information Access located in the S3 bucket defined in Step 2: Setup S3 Bucket to Store Certificate Revocation Lists (CRLs) and Certificates. You will need to replace corp-example-com.s3-us-west-2.amazonaws.com with the URL to your bucket.
      
      Add-CAAuthorityInformationAccess -AddToCertificateAia -Uri "http://corp-example-com.s3-us-west-2.amazonaws.com/Root/<ServerDNSName>_<CaName><CertificateName>.crt" -Force
      
    5. The following commands will set additional configurations to the CA and restart the CA service. For more information on these settings, refer to here.
      
      & certutil.exe -setreg CA\CRLOverlapPeriodUnits '12'
      & certutil.exe -setreg CA\CRLOverlapPeriod "Hours"
      & certutil.exe -setreg CA\ValidityPeriodUnits '5'
      & certutil.exe -setreg CA\ValidityPeriod "Years"
      & certutil.exe -setreg CA\AuditFilter '127'
      & auditpol.exe /set /subcategory:'Certification Services' /failure:enable /success:enable  
      Restart-Service -Name 'certsvc'
      
    6. The following commands will publish the Certificate Revocation List and create a folder name PKI on the C: drive. It will then copy the root CA certificate and CRL to the C:\PKI folder. It also creates a folder name C:\Temp which will be used later.
      
      & certutil.exe -crl
      New-Item -Path 'C:\Pki' -Type 'Directory'
      New-Item -Path 'C:\Temp' -Type 'Directory'
      Copy-Item -Path 'C:\Windows\System32\CertSrv\CertEnroll\*.cr*' -Destination 'C:\Pki\' 
      
  2. Upload the RootCA’s public certificate and CRL files from C:\Pki to the S3 bucket folder named Root that was created in Step 2: Setup S3 Bucket to Store Certificate Revocation Lists (CRLs) and Certificates by following the steps in How Do I Upload Files and Folders to an S3 Bucket.
    1. Make the Root folder public so anyone can download the CRL and CA certificates that you just uploaded. See how to make a folder public.

      Note: Be careful with what you put in this folder as all object contained in this folder can be read by anyone. This is fine for CRLs and CA public certificates.

    2. The following screenshot shows the RootCA‘s public certificate and CRL uploaded to an S3 bucket.

      Figure 31

Step 4: Add a Microsoft Enterprise CA to your AWS Microsoft AD directory

In this step, you set up a Microsoft Enterprise Subordinate CA and join it to your AWS Microsoft AD domain. I will summarize the process first and then walk through the steps.

First, you create an Amazon EC2 for Windows Server instance called SubordinateCA and join it to the domain, corp.example.com. You then publish RootCA’s public certificate and certificate revocation list (CRL) to SubordinateCA’s local trusted store. You also publish RootCA’s public certificate to your directories domain. Doing so enables SubordinateCA and your directory domain controllers to trust RootCA. You then install the Microsoft Enterprise CA service on SubordinateCA and request a certificate from RootCA to make SubordinateCA a Subordinate CA to RootCA. After RootCA issues the certificate, SubordinateCA is ready to issue certificates to your directory domain controllers.

Step 4a: Install Enterprise Subordinate CA

  1. Set up an Amazon EC2 instance joined to your AWS Microsoft AD directory domain – Create an Amazon EC2 for Windows Server 2019 instance to use as an Enterprise Subordinate CA, and join it to your AWS Microsoft AD directory domain. For this example, the machine name is SubordinateCA and the domain is corp.example.com.
    1. Create C:\rootcerts and C:\Temp folders on SubordinateCA using Windows PowerShell with administrative privileges run the following commands.
      
      New-Item -Path 'C:\rootcerts' -Type 'Directory'
      New-Item -Path 'C:\Temp' -Type 'Directory'
      
  2. Publish RootCA’s public certificate to your directory domain – Log in to SubordinateCA as the CAAdmin.
    1. Download RootCA’s public certificate and CRL from the S3 bucket created in Step 2 by following the instructions in How Do I Download an Object from an S3 Bucket? Saving the certificate and CRL to the C:\rootcerts folder on SubordinateCA.
    2. Add RootCA’s public certificate and the CRL to the local store of SubordinateCA and publish RootCA’s public certificate to your directory domain by running the following commands using Windows PowerShell with administrative privileges.
      
      & certutil.exe –addstore –f root C:\rootcerts\RootCA_ROOTCA-CA.crt
      & certutil.exe –addstore –f root C:\rootcerts\ROOTCA-CA.crl
      & certutil.exe –dspublish –f C:\rootcerts\RootCA_ROOTCA-CA.crt RootCA
      
  3. Using Windows PowerShell with administrative privileges, run the following command.
    
    & notepad.exe c:\Windows\CAPolicy.inf
    

    Note: For more information on the CAPolicy.inf syntax see here.

  4. When prompted to create a new file, select Yes.
  5. Enter the following as the contents of the file:
    
    [Version]
    Signature="$Windows NT$"
    [PolicyStatementExtension]
    Policies=InternalPolicy
    [InternalPolicy]
    OID= 1.2.3.4.1455.67.89.5
    Notice="Legal Policy Statement"
    URL=http://corp-example-com.s3-us-west-2.amazonaws.com/Subordinate/cps.txt
    [Certsrv_Server]
    RenewalKeyLength=2048
    RenewalValidityPeriod=Years
    RenewalValidityPeriodUnits=5
    CRLPeriod=Weeks
    CRLPeriodUnits=1
    CRLDeltaPeriod=Days
    CRLDeltaPeriodUnits=0
    LoadDefaultTemplates=0
    AlternateSignatureAlgorithm=0
    [CRLDistributionPoint]
    [AuthorityInformationAccess]
    

    Note: you will need to replace corp-example-com.s3-us-west-2.amazonaws.com with the URL to your bucket you created in Step 2: Setup S3 Bucket to Store Certificate Revocation Lists (CRLs) and Certificates.

  6. Select Save As. Ensure the following:
    • File name is set to CAPolicy.inf
    • Save as type is set to All Files
    • Encoding is ANSI
  7. When you are prompted to overwrite the file, select Yes.
  8. Open Server Manager, select Manage, and then select Add Roles and Features.

    Figure 32

  9. On the Before you begin screen, select Next.

    Figure 33

  10. On the Select installation type screen, ensure the default selection of Role-based or feature-based installation is selected. Select Next.

    Figure 34

  11. On the Select destination server screen, ensure that SubordinateCA is selected and then select Next.

    Figure 35

  12. On the Select server roles screen, select the Active Directory Certificate Services role.
  13. When prompted to install Remote Server Administration Tools select Add Features. Select Next.

    Figure 36

  14. On the Select features screen, select Next.

    Figure 37

  15. On the Active Directory Certificate Services screen, select Next.

    Figure 38

  16. On the Select role services screen, the Certification Authority role is selected by default. Select Next.

    Figure 39

  17. On the Confirm installation selections screen, verify the information and then select Install.

    Figure 40

  18. Wait for the installation to complete. The Installation progress screen is displayed while the binary files for the CA are installed. When the binary file installation is complete, select the Configure Active Directory Certificate Services on the destination server link.

    Figure 41

  19. On the Credentials screen, you should see that the CORP\caadmin is displayed in the Credentials box. Select Next.

    Figure 42

  20. On the Role Services screen, select Certification Authority. This is the only available selection when only the binary files for the certification authority role are installed on the server. Select Next.

    Figure 43

  21. On the Setup Type screen, select Enterprise CA. Select Next.

    Figure 44

  22. On the CA Type screen, select Subordinate CA. Select Next.

    Figure 45

  23. On the Private Key screen, leave the default selection to Create a new private key selected. Select Next.

    Figure 46

  24. On the Cryptography for CA screen, ensure that the cryptographic provider is RSA#Microsoft Software Key Storage Provider, the key length is set to 2048, and the hash algorithm is set to SHA256. Then select Next.

    Note: Large key character lengths provide optimal security; however, they can impact server performance and might not be compatible with legacy applications. It is recommended that you keep the default setting of 2048.

    Figure 47

  25. On the CA Name screen, in the Common name for this CA text box, enter SUBORDINATECA-CA and then select Next.

    FIgure 48

  26. On the Certificate Request screen, leave the default Save a certificate request to file on the target machine. Select Next.

    Figure 49

  27. On the CA Database screen, leave the default locations for the database and database log files. Select Next.

    Figure 50

  28. On the Confirmation screen, select Configure.

    Figure 51

  29. The Progress screen is displayed during the configuration processing, and then the Results screen appears. Select Close. If the Installation progress screen is still open, select Close on that screen, as well.

    Figure 52

    Figure 53

Step 4b: Configure Enterprise Subordinate CA

  1. Copy the Certificate Request file from step 26 above on the SubordinateCA to the C:\Temp folder on RootCA.
  2. From Windows PowerShell (Admin) running on RootCA, run the following command. This command will submit the certificate request for SubordinateCA.
    
    & certreq.exe -submit C:\Temp\SubordinateCA.corp.example.com_corp-SUBORDINATECA-CA.req
    

    Note: change the name and path “C:\Temp\SubordinateCA.corp.example.com_corp-SUBORDINATECA-CA.req” to match the file you copied from SubordinateCA.

  3. On the RootCA, a Certificate Authority List window will pop up. Select OK.

    Figure 54

  4. On the RootCA, you must approve the request.
    1. Open Server Manager, select Tools, and then select Certification Authority.

      Figure 55

    2. Expand the ROOTCA-CA object and then select Pending Requests. Right-click the Request ID that corresponds with the one you saw when you submitted the request in the previous step. Select All Tasks and then select Issue.

      Figure 56

    3. Select Issued Certificates and see the issued certificate in the Details pane. Make note of the Request ID.
  5. On the RootCA, you must retrieve the issued certificate by running the following command.
    
    & certreq.exe  –retrieve 2 C:\Temp\SUBORDINATECA.crt
    

    Note: change the number ‘2’ to the Request ID noted in step 4.c.

  6. On the RootCA, a Certification Authority List window will pop up. Select OK.

    Figure 57

  7. Copy the Certificate file from step 5 on the RootCA to the C:\temp folder on SubordinateCA.
  8. From Windows PowerShell (Admin) running on SubordinateCA, run the following:
    1. The following command will install the Subordinate CA certificate.
      
      & certutil.exe  –installcert C:\temp\SUBORDINATECA.crt
      Start-Service 'certsvc'
      
    2. The following command will remove all CRL Distribution Points except for the one located in C:\Windows\system32\CertSrv\CertEnroll.
      
      Get-CACRLDistributionPoint | Where-Object { $_.Uri -like '*ldap*' -or $_.Uri -like '*http*' -or $_.Uri -like '*file*' } | Remove-CACRLDistributionPoint -Force
      
    3. The following command will remove all Authority Information Access except for the one located in C:\Windows\system32\CertSrv\CertEnroll.
      
      Get-CAAuthorityInformationAccess | Where-Object { $_.Uri -like '*ldap*' -or $_.Uri -like '*http*' -or $_.Uri -like '*file*' } | Remove-CAAuthorityInformationAccess -Force
      
    4. The following command will add a new CRL Distribution Point located in the S3 bucket defined in Step 2: Setup S3 Bucket to Store Certificate Revocation Lists (CRLs) and Certificates. You will need to replace corp-example-com.s3-us-west-2.amazonaws.com with the URL to your bucket.
      
      Add-CACRLDistributionPoint -Uri "http://corp-example-com.s3-us-west-2.amazonaws.com/Subordinate/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl" -AddToCertificateCDP -Force 
      
    5. The following command will add a new Authority Information Access located in the S3 bucket defined in Step 2: Setup S3 Bucket to Store Certificate Revocation Lists (CRLs) and Certificates. You will need to replace corp-example-com.s3-us-west-2.amazonaws.com with the URL to your bucket.
      
      Add-CAAuthorityInformationAccess -AddToCertificateAia -Uri "http://corp-example-com.s3-us-west-2.amazonaws.com/Subordinate/<ServerDNSName>_<CaName><CertificateName>.crt" -Force
      
    6. The following command will set additional configurations to the CA and restart the CA service. For more information on these settings, refer to here.
      
      & certutil.exe -setreg CA\CRLOverlapPeriodUnits '12'
      & certutil.exe -setreg CA\CRLOverlapPeriod "Hours"
      & certutil.exe -setreg CA\ValidityPeriodUnits '5'
      & certutil.exe -setreg CA\ValidityPeriod "Years"
      & certutil.exe -setreg CA\AuditFilter '127'
      & auditpol.exe /set /subcategory:'Certification Services' /failure:enable /success:enable  
      Restart-Service -Name 'certsvc'
      
    7. The following commands will publish the Certificate Revocation List and create a folder name PKI on the C: drive. It will then copy the root CA certificate and CRL to the C:\PKI folder.
      
      & certutil.exe -crl
      New-Item -Path 'C:\Pki' -Type 'Directory'
      Write-Output "Example CPS statement" | Out-File C:\pki\cps.txt
      Copy-Item -Path 'C:\Windows\System32\CertSrv\CertEnroll\*.cr*' -Destination 'C:\Pki\' 
      
  9. Upload SubordinateCA’s public certificate, CRL, and cps.txt files from C:\Pki to the S3 bucket folder named Subordinate that was created in Step 2: Setup S3 Bucket to Store Certificate Revocation Lists (CRLs) and Certificates by following the steps in How Do I Upload Files and Folders to an S3 Bucket.
    1. Make the Root folder public so everyone can download the CRL and CA certificates that you just uploaded. See how to make a folder public.

      Note: Be careful with what you put in this folder as all objects contained in this folder can be read by anyone. This is fine for CRLs and CA public certificates.

    2. The following screenshot shows SubordinateCA’s public certificate and CRL uploaded to an S3 bucket.

      Figure 58

  10. From Windows PowerShell (Admin) running on SubordinateCA, run the following command to load the Enterprise PKI MMC snap-in.
    
    & pkiview.msc
    

    You can then select both CAs and the status for both should be OK.

    Figure 59

You have finished setting up the Microsoft Enterprise Subordinate CA that is joined to your AWS Microsoft AD directory domain. Now you can use your subordinate Microsoft Enterprise Subordinate CA to create a certificate template so that your directory domain controllers can request a certificate to allow LDAPS for your directory.

Step 5: Create a certificate template

In this step, you will create a duplicate certificate template of a certificate template and publish that template to be issued on SubordinateCA. You create this new template (in this case, LDAPOverSSL) by duplicating an existing certificate template (in this case, Kerberos Authentication template).

Follow these steps to create a certificate template:

  1. Log in to SubordinateCA as CAAdmin.
  2. Launch Microsoft Windows Server Manager. Select Tools > Certification Authority.

    Figure 60

  3. In the Certificate Authority window, expand the SubordinateCA tree in the left pane. Right-click Certificate Templates, and choose Manage.

    Figure 61

  4. In the Certificate Templates Console window, right-click Kerberos Authentication and choose Duplicate Template.

    Figure 62

  5. The Properties of New Template window will pop up.

    Figure 63

  6. In the Properties of New Template window,
    1. On the Compatibility tab

      Figure 64

      1. Change Certification Authority to the OS that matches your CA. In this example, Windows Server 2016 is the highest available choice.
      2. If a Resulting changes window pops up, select OK.

        Figure 65

      3. Change Certification recipient to Windows 8.1 / Windows Server 2012 R2.

        Note: AWS Managed Microsoft AD is powered by Windows Server 2012 R2.

      4. If a Resulting changes windows pops up, select OK.

        Figure 66

    2. Switch to the General tab and change the Template display name to LDAPOverSSL.

      Figure 67

    3. Switch to the Security tab, and choose Domain Controllers in the Group or user names section. And verify the Allow check boxes for Read, Enroll, and Autoenroll in the Permissions for Domain Controllers section are checked.

      Figure 68

    4. Choose OK to create the LDAPOverSSL certificate template. Close the Certificate Templates Console window.
  7. In the Certificate Authority window, right-click Certificate Templates, and choose New > Certificate Template to Issue.

    Figure 69

  8. In the Enable Certificate Templates window, choose LDAPOverSSL, and then choose OK.

    Figure 70

You have finished creating a certificate template with server authentication and auto-enrollment enabled on SubordinateCA. Your AWS Microsoft AD directory domain controllers can now obtain a certificate through auto-enrollment to enable LDAPS.

Step 6: Configure AWS security group rules

In this step, you configure AWS security group rules so that your directory domain controllers can connect to the subordinate CA to request a certificate. To do this, you must add outbound rules to your directory’s AWS security group (in this case, sg-014fee4c22b6ff511) to allow all outbound traffic to SubordinateCA’s AWS security group (in this case, sg-06693e3b64a7e32f4 ) so that your directory domain controllers can connect to SubordinateCA for requesting a certificate. You also must add inbound rules to SubordinateCA’s AWS security group to allow all incoming traffic from your directory’s AWS security group so that the subordinate CA can accept incoming traffic from your directory domain controllers.

Follow these steps to configure AWS security group rules:

  1. Log in to the Management instance as Admin.
  2. Navigate to the EC2 console.
  3. In the left pane, choose Network & Security > Security Groups.
  4. In the right pane, choose the AWS security group (in this case, sg-6fbe7109) of SubordinateCA.
  5. Switch to the Inbound tab and choose Edit.
  6. Choose Add Rule. Choose All traffic for Type and Custom for Source. Enter your directory’s AWS security group (in this case, sg-4ba7682d) in the Source box. Choose Save.

    Figure 71

  7. Now choose the AWS security group (in this case, sg-4ba7682d) of your AWS Microsoft AD directory, switch to the Outbound tab, and choose Edit.
  8. Choose Add Rule. Choose All traffic for Type and Custom for Destination. Enter your directory’s AWS security group (in this case, sg-6fbe7109) in the Destination box. Choose Save.

    Figure 72

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

The AWS Microsoft AD domain controllers will automatically request a certificate based on the template created on the Microsoft Enterprise Subordinate CA in Step 5: Create a certificate template. It can take up to 30 minutes for the directory domain controllers to auto-enroll the available certificates. Once the certificates are issued to the directory domain controllers LDAPS will become functional. This completes the setup of LDAPS for the AWS Microsoft AD directory. The LDAP service on the directory is now ready to accept LDAPS connections!

Step 7: Test LDAPS access by using the LDP tool

In this step, you test the LDAPS connection to the AWS Microsoft AD directory by using the LDP tool. The LDP tool is available on the Management machine where you installed Active Directory Administration Tools. Before you test the LDAPS connection, you must wait up to 30 minutes for the Microsoft 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. Here are the steps to test the LDAPS connection:

  1. Log in to Management as Admin.
  2. Launch the Microsoft Windows Server Manager on Management and navigate to Tools > Active Directory Users and Computers.
  3. Switch to the tree view and navigate to corp.example.com > CORP > Domain Controllers. In the right pane, right-click on one of the domain controllers and choose Properties. Copy the DNS name of the domain controller.

    Figure 73

  4. Launch the LDP.exe tool by launching Windows PowerShell and running the LDP.exe command.

    Figure 74

  5. In the LDP tool, choose Connection > Connect.

    Figure 75

  6. In the Server box, paste the DNS name you copied in Step 2. Type 636 in the Port box. Choose OK to test the LDAPS connection to port 636 of your directory.

    Figure 76

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

    Figure 77

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

Summary

In this post, I walked through the process of enabling LDAPS for your AWS 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 Microsoft AD. To learn more about how to use AWS Microsoft AD, see the Directory Service documentation. For general information and pricing, see the Directory Service home page.

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.

– Vijay

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