Migrate your Windows PKI from Microsoft Active Directory Certificate Services to AWS Private CA Connector for Active Directory

When you migrate your Windows environment to Amazon Web Services (AWS), you might need to address certificate management for computers and users in your Active Directory domain. Today, Windows administrators commonly use Active Directory Certificate Services (AD CS) to support this task. In this post, we will show you how to migrate AD CS to AWS Private Certificate Authority by using the AWS Private CA Connector for Active Directory.

AWS Private CA provides a highly available private certificate authority (CA) service without the upfront investment and ongoing maintenance costs of operating your own private CA. Using the APIs that AWS Private CA provides, you can create and deploy private certificates programmatically. You also have the flexibility to create private certificates for applications that require custom certificate lifetimes or resource names. With AWS Private CA, you can create your own CA hierarchy and issue certificates for authenticating internal users, computers, applications, services, servers, and devices and for signing computer code.

Use cases for certificate services that integrate with Active Directory

AD CS is commonly used in enterprise environments because it integrates certificate management with Active Directory authentication, authorization, and policy management. A common use case for AD CS is certificate auto-enrollment. Using AD Group Policies, you can configure certificates to automatically be created for users as they log in to the domain, or you can configure computer certificates, which are associated with each workstation or server that joins the domain. You can then use these certificates for authentication or digital signature purposes. A common use case is for authentication of devices to protected networks, such as wired networks that require 802.1x authentication or wireless networks that are protected by WPA2/3 with EAP-TLS authentication. Auto-enrolled computer and user certificates are also commonly used to authenticate VPN connections.

Options to deploy certificate services that integrate with Active Directory on AWS

To migrate your Windows environment to the cloud, you probably want to retain the capabilities of a CA that integrates with Active Directory. Although you can migrate AD CS directly to AWS and run it on an Amazon Elastic Compute Cloud (Amazon EC2) instance running Windows, we will show you how to use AWS Private CA with the Connector for AD to provide an Active Directory integrated CA that offers the benefits of AD CS without the need to manage AD CS or hardware security modules (HSMs).

Why migrate your on-premises CA to AWS Private CA?

Migrating AD CS to AWS Private CA has several benefits. With AWS Private CA, you get simplified certificate management, eliminating the need for an on-premises CA infrastructure and reducing operational complexity. AWS Private CA provides a managed service, reducing the operational burden and providing high availability and scalability. Additionally, it integrates with other AWS services, so it’s simpler to manage and deploy certificates across your infrastructure. The centralized management, enhanced security features, and simplified workflows in AWS Private CA can streamline certificate issuance and renewal processes, enabling you to more efficiently achieve your security goals.

AWS manages the underlying infrastructure, which can help reduce costs, and automation features help prevent disruptions that expired certificates could cause. AWS Private CA operates as a Regional service with an SLA of 99.9% availability. For environments that require the highest level of availability, you can deploy CAs in multiple AWS Regions by following the guidance on redundancy and disaster recovery in the documentation.

AWS Private CA Connector for AD extends the certificate management of Private CA to AD environments. With the Connector for AD, you can use Private CA to issue certificates for AD users and computers joined to your domain. This includes integration with Windows Group Policy for certificate autoenrollment.

How do I migrate to the Connector for AD?

Transitioning from an existing AD CS server to the Connector for AD involves several steps.

Assessment and planning

Before you begin, identify the use cases for your existing AD CS server and how certificates are issued. In this post, we focus on certificates that are auto-enrolled by using a Group Policy, but you might have other use cases where you must manually enroll certificates by using the Web Enrollment server or APIs. These might include use cases for signing software packages or web server certificates for intranet applications. Start by creating a certificate inventory from your existing AD CS server.

To create a certificate inventory from your existing AD CS server

1. In the Microsoft CA console, select Issued Certificates.
2. From the Action menu, select Export List.
    
   

   Figure 1: Export a list of existing certificates

This produces a CSV file of the certificates that the server issued. To determine which certificates were created as part of an auto-enrollment policy and to identify special cases that require manual attention, sort this file by Certificate Template.

Set up AWS Private CA and the Connector for AD

To complete the initial setup of the Connector for AD, see Getting started with AWS Private CA Connector for Active Directory. When you complete the setup, you can start transitioning enrollment to the new CA.

Configure trust for the new CA

Depending on where you put the new private CA in your organization’s public key infrastructure (PKI) hierarchy, you might want to make sure that its certificate is imported into all of the client trust stores before you issue new certificates using the CA. For Windows devices, creation of the Connector for AD imports the CA certificate into Active Directory, and automatically distributes it to the trust stores of domain-joined computers.

For non-Windows devices, you need to evaluate other use cases for issued certificates on the network and follow vendor instructions for updating trust stores. For example, if you use client certificates for wired 802.1x and Wi-Fi Protected Access (WPA) enterprise authentication, you need to import the new root CA certificate into the trust stores of the RADIUS servers that you use for authentication.

Export the CA certificate

The next step is to export the certificate by using the AWS Management Console.

To export the certificate

1. Open the AWS Private CA console.
2. Navigate to your private CA.
3. Choose the CA certificate tab.
4. Select Export certificate body to a file.
   

   Figure 2: Export the CA certificate

Transition certificate enrollment to the new CA

After you configure AWS Private CA and the Connector for AD and update your trust stores as necessary, you can begin to transition certificate enrollment to the new CA. In Active Directory domains, certificates are typically created automatically by using an auto-enrollment Group Policy. To migrate enrollment to your new CA, you need to configure certificate templates with the appropriate properties to match your requirements, assign permissions to the templates, and configure the Group Policy to point the enrollment client on Windows devices to the new CA.

Configure certificate templates

Certificate templates define the enrollment policy on a CA. An Active Directory CA only issues certificates that conform to the templates that you have configured. Using the certificate inventory that you collected from your existing AD CS server, you should have a list of certificate templates that are in active use in your environment and that you need to replicate in the Connector for AD.

Start by noting the properties of these certificate templates on your existing AD CS server.

To note the properties of the certificate templates

1. Open the Certificate Authority console on your AD CS server.
2. Navigate to the Certificate Templates folder.
3. From the Action menu, select Manage. This opens the Certificate Templates console, which shows a list of the certificate templates available in Active Directory.
    
   

   Figure 3: Identify certificate templates

4. For each certificate that is in active use, open it and take note of its settings, particularly the following:
   • Template name, validity period, and renewal period from the General tab.
   • Certificate recipient compatibility from the Compatibility tab.
   • Certificate purpose and associated checkboxes in addition to whether a private key is allowed to be exported from the Request Handling tab.
   • Cryptography settings from the Cryptography tab.
   • The extensions configured from the Extensions tab.
   • Settings for certificate subject and subject alternate name from the Subject Name tab.
   • Review the Security tab for the list of Active Directory users and groups that have Enroll or AutoEnroll permissions. The other permission settings, which control which AD principals have the ability to modify or view the template itself, don’t apply to AWS Private CA because IAM authorization is used for these purposes.
      
     

     Figure 4: Certificate template properties

After you gather the configuration details for the certificate templates that are in active use, you need to configure equivalent templates within the Connector for AD.

To configure templates in the Connector for AD

1. Open the AWS Private CA console.
2. Navigate to Private CA Connector for AD.
3. Select your connector.
4. In the Templates section, choose Create template.
    
   

   Figure 5: Certificate template configuration in the Connector for AD

5. You can then begin configuring your certificate template by using the settings that you obtained from your existing AD CS server. For a complete description of the settings that are available in the certificate template, see Creating a connector template.
    
   

   Figure 6: Certificate template settings

6. Assign permissions to the template.

   You must manually enter the Active Directory Security Identifier (SID) of the group that you are assigning the Enroll or Auto-enroll permission to. For instructions on how to use PowerShell to obtain the SID of an Active Directory object, see Managing AD groups and permissions for templates.

   We recommend that you initially assign your certificate templates to a small test group that contains a set of Active Directory computers or users that will be used to test the new CA. When you are confident that the new CA issues certificates correctly, you can modify the permissions to include the full set of Active Directory user and computer groups that were assigned to the template on your original AD CS server.

Configure Group Policy for automatic certificate enrollment

With the Connector for AD configured with the required certificate templates, you are ready to configure the AD Group Policy to enable automatic enrollment of user and computer certificates. We suggest that you start with a test organizational unit (OU) in Active Directory, where you can put user and computer objects to make sure that enrollment is working properly. The existing AD CS server and the Connector for AD can continue to coexist until you are ready to replace the certificates.

In this example, you configure a new Group Policy object that is linked to an OU called Test OU, where you will place computer objects for testing. We recommend creating a new GPO so that you can incrementally extend the scope to OUs as you complete testing and gain confidence in certificate enrollment via the Connector for AD.

To configure a new Group Policy object

1. Within the Group Policy object, locate the settings for controlling enrollment under Computer Configuration  > Policies > Windows Settings > Security Settings > Public Key Policies.
    
   

   Figure 7: Active Directory Group Policy Editor

2. Configure the Certificate Services Client – Certificate Enrollment Policy to point clients at the URL of the Connector for AD:
   1. Set the Configuration Model to Enabled.
   2. Add a new item to the Certificate enrollment policy list.
       
      

      Figure 8: Certificate Services Client Group Policy settings

3. Enter the URL of your connector and leave the Authentication mode set to Windows Integrated. Then choose Validate.
   

   Note: You can find the URL of your connector in the AWS Private CA Connector for AD console under Certificate enrollment policy server endpoint.

   

   Figure 9: Connector details

4. After you save your configuration, remove the Active Directory Enrollment Policy from the list so that the Group Policy only references the Connector for AD. A completed configuration will look similar to the following:
    
   

   Figure 10: Certificate services client settings with Active Directory enrollment policy removed

5. From within the Group Policy editor, open the Certificate Services Client – Auto-enrollment policy to configure auto-enrollment of computer certificates. Set Configuration Model to Enabled, and select the following:
   • Renew expired certificates, update pending certificates, and remove revoked certificates
   • Update certificates that use certificate templates
      
     

     Figure 11: Certificate Services client auto-enrollment policy settings

After you configure the Group Policy, computers in OUs that the Group Policy is linked to will start automatically enrolling certificates by using AWS Private CA, subject to the permissions defined on the certificate templates. To review the progress of certificate enrollment, use private CA audit reports.

When you complete testing and gain confidence in your certificate roll-out, extend the scope of the GPO and Active Directory permissions on the certificate templates to cover additional users and computers.

Revocation and decommissioning

You can continue to review the Private CA audit reports to confirm progress with auto-enrollment of certificates from the new CA. If you have computers that infrequently connect to the network, this can take some time. As part of this process, address your use cases that aren’t covered by auto-enrollment, which you identified from your initial certificate inventory. These might include web server certificates for internal applications or code-signing certificates for distributing software packages. You can issue replacement certificates for these use cases by using the AWS Private CA APIs or CLI without depending on the Active Directory integration. For more information, see Issuing private end-entity certificates.

After the required certificates have been enrolled and you have confirmed that the services that depend upon those certificates are functioning correctly, it’s time to revoke issued certificates and decommission your existing AD CS server. Microsoft provides detailed documentation for properly revoking certificates and decommissioning an Enterprise CA, including clean-up of related AD objects.

Conclusion

In this post, we covered some use cases for Active Directory integrated certificate management in Windows environments and introduced the new AWS Private CA Connector for Active Directory. AWS Private CA and the Connector for AD can help you reduce operational overhead, enabling you to simplify the process of provisioning certificates while maintaining the Active Directory integration that you are accustomed to in a Microsoft AD CS environment. You learned how to evaluate your existing Microsoft CA and migrate to AWS Private CA with the Connector for AD, with a specific focus on auto-enrollment of certificates, which is commonly used in enterprise environments for device and end-user authentication.

To learn more about the services described in the post, see the documentation for Connector for AD, AWS Private CA , CA best practices and AWS Directory Services. You can get started creating CAs in AWS Private CA by using the console.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, start a new thread on the AWS Certificate Manager re:Post or contact AWS Support.