AWS Security Blog

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

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.


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 Managed 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 Managed 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 Managed Microsoft AD over untrusted networks.

To enable server-side LDAPS, you need to add a Microsoft Enterprise Certification Authority (CA) server to your AWS Managed Microsoft AD domain and configure certificate templates for your domain controllers. After you have enabled LDAPS, AWS Managed 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 Managed Microsoft AD.

In this post, I show you how to enable server-side LDAPS for your AWS Managed Microsoft AD directory. You must choose one of three options to deploy the CA architecture: automated deployment, manual deployment, or cross-forest PKI enrollment using your existing on-premises PKI infrastructure. Thus, the procedure involves either six or seven of the following steps, depending on the deployment path you choose.

  1. Delegate permissions to CA administrators.
  2. Set up an S3 bucket to store certificate revocation lists (CRLs) and certificates.
  3. Automated deployment option: Deploy a Microsoft Offline Root CA and Microsoft Enterprise Subordinate CA to your AWS Managed Microsoft AD directory using the Microsoft Public Key Infrastructure Quick Start.
  4. Manual deployment option: Deploy a Microsoft Offline Root CA.
  5. Manual deployment option: Deploy a Microsoft Enterprise Subordinate CA to your AWS Managed Microsoft AD directory.
  6. Create a certificate template to be issued to domain controllers.
  7. Cross-forest PKI enrollment option: Use your existing on-premises Microsoft PKI infrastructure to enable LDAPs on AWS managed Microsoft AD.
  8. Configure AWS security group rules to allow the AWS Managed Microsoft AD directory to communicate with the Microsoft Enterprise Subordinate CA.
  9. 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 Managed 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 Managed Microsoft AD.

How you enable LDAPS on AWS Managed 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 Managed Microsoft AD now supports both encryption standards when you enable LDAPS on your AWS Managed Microsoft AD domain controllers.

You enable LDAPS on your AWS Managed 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 Managed Microsoft AD requires you to add a Microsoft Enterprise CA to your AWS Managed 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 Managed 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 Managed Microsoft AD domain controllers, an automatic certificate enrollment model is required. Therefore, AWS Managed 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 Managed 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 Managed Microsoft AD directory

The rest of this post is composed of the steps for enabling LDAPS for your AWS Managed 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 Managed Microsoft AD directory – To create a directory, follow the steps in Create an AWS Managed 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 Managed 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 Managed 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 Managed 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 Managed 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 Managed Microsoft AD domain and configure it as a subordinate CA.
  2. Set up an S3 bucket to store the 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 Managed 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.

    Note: You can complete the activities described in Steps 3 and 4 through automated or manual deployment.

  5. Create a certificate template to be issued to domain controllers (in this case, LDAPOverSSL) with auto-enrollment configured so that your AWS Managed Microsoft AD directory domain controllers can obtain certificates through auto-enrollment to enable LDAPS.
  6. If you choose the cross-forest PKI enrollment option to deploy the CA architecture, use your existing on-premises Microsoft PKI infrastructure to enable LDAPs on AWS Managed Microsoft AD.
  7. Configure AWS security group rules so that AWS Managed Microsoft AD directory domain controllers can connect to the Enterprise Subordinate CA to request certificates.
  8. 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 Managed 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 Managed Microsoft AD directory to this security group. If you have established 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.

    Note: If you plan to follow Step 3, automated deployment option, you must also add the user to the AWS Delegated Administrators group. If the user is not a member of this group, the deployment will fail.

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

Step 2: Set up 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.

If you will use automation to deploy the CA architecture, proceed to the next step: Step 3, automated deployment option. If you will deploy the CA architecture manually, skip to Step 3, manual deployment option. If you will use cross-forest PKI enrollment to deploy the CA architecture, skip to Step 5: Create a certificate template.

Step 3, automated deployment option: Install and configure an offline CA and add a Microsoft Enterprise CA to your AWS Managed Microsoft AD

Note: This option assumes that you do not have a Root CA deployed. If you have a Root CA, skip to Step 4, manual deployment option: Add a Microsoft Enterprise CA to your AWS Managed Microsoft AD.

Step 3a, automated deployment option: Create an AWS Secrets Manager secret to store the CAAdmin service account information

In this step, you store the CAAdmin account credentials in an AWS Secrets Manager secret. This secret is used in the automation that creates the CA infrastructure.

Note: if you prefer, you can use the Admin account instead of the CAAdmin account.

  1. Sign in to the AWS Management Console and open the AWS Secrets Manager console.
  2. Choose Store a new secret.
  3. On the Store a new secret page, under Select secret type, choose Other type of secrets.
  4. Under Specify the key/value pairs to be stored in the secret, do the following:
    1. In the first field, enter username, and in the same row, in the next field, enter CAAdmin.
    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 the password for CAAdmin.
    4. Under Select the encryption key, choose DefaultEncryptionKey. Secrets Manager always encrypts the secret when you choose this option. You can also choose a key that you created.
    5. Choose Next.
  5. Under Secret name, enter a name for the secret.
  6. Leave the default settings for the remaining fields and choose Next.
  7. For Configure automatic rotation, choose Disable automatic rotation, and then choose Next.
  8. 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.
  9. Choose your newly created secret from the list, and take note of the Secret ARN value. You will need it in the next section.

Step 3b, automated deployment option: Deploy an offline Root CA and Microsoft Enterprise Subordinate CA using the Microsoft Public Key Infrastructure Quick Start template

In this step, you deploy an Offline Root CA and Microsoft Enterprise Subordinate CA 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 – do not change the default values for any of the fields that are not explicitly mentioned here:

  1. Sign in to the AWS Management Console and open the AWS CloudFormation console.
  2. Choose Create Stack.
  3. For Prepare template, choose Template is ready.
  4. For Template source, choose Amazon S3 URL.
  5. For Amazon S3 URL, choose https://aws-quickstart.s3.amazonaws.com/quickstart-microsoft-pki/templates/microsoft-pki.template.yaml
  6. Select Next.
  7. Specify stack details:
    • VPC CIDR: Enter the CIDR of the VPC where your AWS Managed Microsoft AD directory resides.
    • VPC ID: Enter the VPC where your AWS Managed Microsoft AD directory resides.
    • CA(s) Subnet ID: Enter the subnets in the VPC where your AWS Managed Microsoft AD directory resides.
    • Domain Members Security Group ID: Enter the security group that allows communication with the AWS Managed Microsoft AD directory.
    • Key Pair Name: Enter the name of an EC2 key pair in your account.
    • Active Directory Domain Services Type: AWSManaged

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

    • Domain FQDN DNS Name: Enter the DNS name of the AWS Managed Microsoft AD directory.
    • Domain NetBIOS Name: Enter the NetBios name of the AWS Managed Microsoft AD directory.
    • IP the Instance will use for DNS (Must be accessible): Enter the IP address of one of the AWS Managed Microsoft AD directory domain controllers.
    • IP the Instance will use for DNS (Must be accessible): Enter the IP address of one of the AWS Managed Microsoft AD directory domain controllers.
    • Secret ARN Containing CA Install Credentials: Enter the AWS Secrets Manager Secret created in Step 3a, automated deployment option.
    • CA Deployment Type: Two-Tier
    • Use S3 for CA CRL Location: Yes
    • CA CRL S3 Bucket Name: Enter the name of the bucket created in Step 2: Set up S3 bucket to store certificate revocation lists (CRLs) and certificates.
  8. Select Next.
  9. 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.
  10. Choose Create stack.

It should take 20 to 30 minutes for the CAs to deploy. After the CloudFormation build has deployed successfully, proceed to Step 7: Configure AWS security group rules.

Step 3, manual deployment option: Install and configure an offline CA

Note: If you already have a Root CA, skip 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, manual deployment option: Install Standalone Root CA

    1. Set up an Amazon EC2 instance joined to your AWS Managed 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, manual deployment option: 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: Set up 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: Set up S3 bucket to store certificate revocation lists (CRLs) and certificates by following the steps in Uploading objects.
    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, manual deployment option: Add a Microsoft Enterprise CA to your AWS Managed Microsoft AD directory

In this step, you set up a Microsoft Enterprise Subordinate CA and join it to your AWS Managed 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, manual deployment option: Install Enterprise Subordinate CA

  1. Set up an Amazon EC2 instance joined to your AWS Managed 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 Managed 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 Downloading an object. 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: Set up 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, manual deployment option: 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: Set up 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: Set up 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: Set up S3 bucket to store certificate revocation lists (CRLs) and certificates by following the steps in Uploading objects.
    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 Managed 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. If you already deployed the CA using either automated or manual deployment methods, skip to Step 7. However, if you want to deploy the CA using your existing on-premises PKI infrastructure, proceed to Step 6.

Step 6, cross-forest PKI enrollment option: Use your existing on-premises Microsoft PKI infrastructure to enable LDAPs on AWS Managed Microsoft AD

Prerequisites

  1. An existing self-managed Active Directory environment with two-tier Microsoft PKI infrastructure.
  2. An existing two-way forest trust between AWS Managed Microsoft AD and your self-managed AD.

Step 6a: Configure your on-premises firewall

You must configure your on-premises firewall so that the following ports are open to the CIDRs for all subnets used by the VPC that contains your AWS Managed Microsoft AD and also from the private IP of the RSAT instance that you are going to use to manage the AWS Managed Microsoft AD.

  • TCP 135 (RPC)
  • TCP 1024 – 65535 (RPC randomly allocated high TCP ports)
  • TCP/UDP 53 (DNS)
  • TCP/UDP 88 (Kerberos authentication)
  • TCP/UDP 389 (LDAP)
  • TCP 445 (SMB)

Step 6b: Prepare your on-premises CA

In this step, you prepare your on-premises Enterprise Subordinate CA for cross-forest certificate enrollment by enabling LDAP referral.

  1. Log in to your on-premises Enterprise CA.
  2. Open a command prompt as an administrator and run the following command:
    certutil -setreg Policy\EditFlags +EDITF_ENABLELDAPREFERRALS
    
  3. To restart the certificate service, run the following command:
    net stop certsvc && net start certsvc
    

Step 6c: Create and publish the certificate template

In Step 5, you created and published the certificate template in the on-premises Enterprise Subordinate CA. To add enroll and auto-enroll permissions on the certificate template so that AWS Managed Microsoft AD Domain controllers can auto-enroll the certificate, complete the following steps.

  1. Connect to the Subordinate CA using RDP with an on-premises CA admin.
  2. Open the Run dialog box, enter certtmpl.msc, and select OK.
  3. In the Certificate Templates Console window, right-click the LDAPoverSSL certificate template that was created in Step 5 and choose Properties.
  4. Choose the Security tab and then choose Add.
     
  5. Change the location to the AWS Managed Microsoft AD domain. For Enter the object names to select, enter Domain Controllers, choose Check names, and then choose OK.
     
  6. On the Properties of New Template screen, choose the Security tab, and under Group or user names, select Domain controllers (amazondomains\Domain Controllers). In the Permissions for Domain Controllers section, check the boxes in the Allow column for Read, Enroll, and Autoenroll, choose Apply, and then choose OK.
     

Step 6d: Configure AWS Managed Microsoft AD

In Step 6d, you perform multiple operations to configure the amazondomains.com domain for cross-forest certificate enrollment.

Step 6d-1: Add an on-premises Enterprise CA computer object in the Cert Publishers group of the amazondomains.com domain
  1. Take RDP to the RSAT instance with the AWS Managed Microsoft AD Admin user.
  2. Open the Run dialog box, enter dsa.msc, and choose OK.
  3. Navigate to amazondomains.com > Users, right click the group named Cert Publishers, and select Properties.
     
  4. In the Cert Publishers Properties box, choose the Members tab and then choose Add.
     
  5. In the Select Users, Computers, Service Accounts, or Groups box, provide the following details:
    • For Select this object type, choose Object Types, and then choose Computers.
    • For From this location, choose Locations and then choose onprem.example.com.
    • For Enter the object names to select, enter the name of the computer where the Subordinate CA is installed, select Check Names, and then select OK.
       
  6. Choose Apply and then choose OK.
Step 6d-2: Share the Root CA certificate with the RSAT instance
  1. Take RDP to the on-premises server where the Root CA is configured as a local administrator of the server.
  2. Upload the Root CA certificate (.crt files) from the c:\windows\system32\certsrv\certnroll folder to the S3 bucket created in Step 2 by following the steps in Uploading objects.
Step 6d-3: Publish the Root CA certificate in AWS Managed Microsoft AD
  1. Take RDP to the RSAT instance with the Admin user.
  2. Download the Root CA certificate from the S3 bucket by following the documentation in Downloading an object, and then save the certificates in a new folder named c:\certconfig.
  3. To publish the certificate in the amazondomains.com domain, open the command prompt as an administrator and run the following commands. Replace <placeholder values> with your values.
    certutil -dspublish -f <root-ca-cert-filename.cer> RootCA
    certutil -addstore -f root <root-ca-cert-filename.crt>
    

    For the example in this post, I ran the following commands:

    certutil -dspublish -f c:\certconfig\RootCA_RootCA.crt RootCA
    certutil -addstore -f root c:\certconfig\RootCA_RootCA.crt
    
Step 6d-4: Publish the Subordinate CA certificate in AWS Managed Microsoft AD
  1. Take RDP to the RSAT instance with the Admin user.
  2. To publish the Subordinate CA certificate in the amazondomains.com domain, open the command prompt as an administrator and run the following commands. Replace <placeholder values> with your values.
    certutil -config <Computer-Name>\<Enterprise-CA-Name> -ca.cert <enterprise-ca-cert-filename.cer>
    certutil -addstore -f CA <enterprise-ca-cert-filename.cer>
    certutil -dspublish -f <enterprise-ca-cert-filename.cer> NTAuthCA
    certutil -dspublish -f <enterprise-ca-cert-filename.cer> SubCA
    

    For the example in this post, I ran the following commands:

    certutil -config SubordinateCA.onprem.example.com\onPremSubordinateCA -ca.cert c:\certconfig\subcacert.cer
    certutil -addstore -f CA c:\certconfig\subcacert.cer 
    certutil -dspublish -f c:\certconfig\subcacert.cer NTAuthCA
    certutil -dspublish -f c:\certconfig\subcacert.cer SubCA
    
Step 6d-5: Download and run the PKIsync script from Microsoft to sync CA objects from the on-premises AD to AWS Managed Microsoft AD.
  1. Download the PKISync.ps1 script from Microsoft.
  2. At the top of the code section, select Copy code.
  3. In Notepad or a similar text editor, paste the code, and save the file with the name PKISync.ps1.
  4. Upload the PKISync.ps1 file to the S3 bucket.
  5. Take RDP to the RSAT instance of AWS Managed Microsoft AD and download the PKISync.ps1 file from the S3 bucket to the folder c:\certconfig.
  6. Open Powershell as an administrator and run the following command.
    Set-Location C:\Certconfig
    
Step 6d-6: To copy the certificate template from the on-premises domain to AWS Managed Microsoft AD, run the following command. Replace <placeholder values> with your values.
.\PKISync.ps1 -sourceforest <onPrem domain DNS> -targetforest <AWS managed AD domain DNS> -type Template -cn <certificate template common name> -f

For the example in this post, I ran the following command:

.\PKISync.ps1 -sourceforest onprem.example.com -targetforest amazondomains.com -type Template -cn LDAPoverSSL -f
Step 6d-7: To copy the OID from the on-premises domain to AWS Managed Microsoft AD, run the following command. Replace <placeholder values> with your values.
.\PKISync.ps1 -sourceforest <onPrem domain DNS> -targetforest <AWS managed AD domain DNS> -type Oid -f

For the example in this post, I ran the following command:

.\PKISync.ps1 -sourceforest onprem.example.com -targetforest amazondomains.com -type Oid -f
Step 6d-8: To copy the Enterprise CA object from the on-premises domain to AWS Managed Microsoft AD, run the following command. Replace <placeholder values> with your values.
.\PKISync.ps1 -sourceforest <onPrem domain DNS> -targetforest <AWS managed AD domain DNS> -type CA -cn <enterprise CA sanitized>

For the example in this post, I ran the following command:

.\PKISync.ps1 -sourceforest onprem.example.com -targetforest amazondomains.com -type CA -cn onPremSubordinateCA -f

Step 7: 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 Managed 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 Managed 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 Managed Microsoft AD directory. The LDAP service on the directory is now ready to accept LDAPS connections!

Step 8: 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 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 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.

Summary

In this post, I walked through the process of enabling 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.

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, Jeremy, and Chanakya

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