Simplify WorkSpaces Certificate-Based Authentication with AWS Private CA Connector for AWS Managed Microsoft AD

I have referenced this post: Simplify certificate-based authentication for AppStream 2.0 and WorkSpaces with AWS Private CA Connector for Active Directory

However, while the original post focuses on On-premises AD + AD Connector, this guide provides the specific additional steps and considerations required for AWS Managed Microsoft AD.

Overview

This document guides you through a simplified process for establishing Certificate-Based Authentication (CBA) using the AWS Private CA Connector for AD, eliminating the need to deploy and manage a complex AD CS (Active Directory Certificate Services) infrastructure.

Walkthrough

Prerequisites

• AWS Console with required IAM permissions to perform commands for the AWS Services used.

• Functional WorkSpaces deployment integrated with a SAML 2.0 identity provider.

• Configure the https://aws.amazon.com/SAML/Attributes/PrincipalTag:UserPrincipalName attribute in your SAML assertion. This attribute is required for CBA and must map to the User Principal Name (UPN) in Active Directory.

• Add the sts:TagSession permission to your IAM role trust policy used with your SAML 2.0 configuration.

• Plan and design your Certificate Authority hierarchy based on your needs.

• Note: Configuration steps assume a one-level CA hierarchy. A single AWS Private CA instance is deployed in short-lived mode.

---

Step 1: Create a public repository to host the certificate revocation list (CRL)

1. Create an Amazon S3 bucket, keep ACLs disabled, and block all public access.

2. Create a CloudFront distribution:

   1. Navigate to the CloudFront console.
   2. Create a Distribution.
   3. For Origin Domain, select the S3 Bucket created in Step 1.
   4. For Origin access, select Origin access control settings (recommended).
   5. Choose Create control setting and then Create distribution.

3. Create the S3 bucket policy:

   1. Navigate to the S3 Console and select your bucket.
   2. Under the Permissions tab, edit the Bucket Policy.
   3. Enter the following policy (Replace placeholders with your values):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "acm-pca.amazonaws.com"
            },
            "Action": ["s3:PutObject", "s3:PutObjectAcl", "s3:GetBucketAcl", "s3:GetBucketLocation"],
            "Resource": ["arn:aws:s3:::S3-BUCKET-NAME/*", "arn:aws:s3:::S3-BUCKET-NAME"],
            "Condition": {
                "StringEquals": { "aws:SourceAccount": "AWS-ACCOUNT-NUMBER" }
            }
        },
        {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect": "Allow",
            "Principal": { "Service": "cloudfront.amazonaws.com" },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::S3-BUCKET-NAME/*",
            "Condition": {
                "StringEquals": { "AWS:SourceArn": "arn:aws:cloudfront::AWS-ACCOUNT-NUMBER:distribution/CLOUDFRONT-DISTRIBUTION" }
            }
        }
    ]
}

---

Step 2: Create AWS Private CA

Create a ca_config.txt file, formatted with the following information and replacing information in bold with your organizational information:

{
   "KeyAlgorithm":"RSA_2048",
   "SigningAlgorithm":"SHA256WITHRSA",
   "Subject":{
      "Country":"YOUR-COUNTRY",
      "Organization":"YOUR-ORG",
      "OrganizationalUnit":"YOUR-OU",
      "State":"YOUR-STATE",
      "Locality":"YOUR-LOCALITY",
      "CommonName":"CA-NAME"
   }
}

2. Create a revoke_config.txt file, formatted with the following information. Replace the following bolded placeholders.

• Note: Ensure HTTPS is not included in the FQDN for CustomCname.

{
   "CrlConfiguration":{
      "Enabled":true,
      "ExpirationInDays":7,
      "S3BucketName":"YOUR-S3-BUCKET-NAME",
      "S3ObjectAcl":"BUCKET_OWNER_FULL_CONTROL",
        "CustomCname":"CLOUDFRONT-DISTRIBUTION-FQDN"
   }
}

3. Enter the following AWS CLI command to create the short-lived Root AWS Private CA. You may use AWS CloudShell for a terminal environment.

• Note: These values are required and must be not altered. Upload the ca_config.txt and revoke_config.txt files to AWS CloudShell before you run the command.

aws acm-pca create-certificate-authority \
      --certificate-authority-configuration file://ca_config.txt \
      --revocation-configuration file://revoke_config.txt \
      --certificate-authority-type "ROOT" \
      --idempotency-token 01234567 \
      --tags Key=euc-private-ca,Value= \
      --usage-mode SHORT_LIVED_CERTIFICATE

4. Navigate to the AWS Private Certificate Authority Console and select private certificate authorities.
   1. Choose your PCA and Click Actions and then Click Install CA Certificate
   2. Click Confirm and install

---

Step 3: Create PCA Connector for AD

1. Navigate to the AWS Private CA Connector for AD console.
2. Choose Create connector and select AWS Managed Microsoft Active Directory.
3. Choose your directory and select a Security Group.

• Note: Ensure the Security Group allows All Traffic to the VPC where the AD is located.

4. Choose your Private CA and click Create connector.

---

Step 4: Create certificate template

The PCA connector includes common certificate templates used for AD applications. The Kerberos Authentication certificate template is the most current certificate template designated for domain controllers that allow virtual smart card and CBA logon.

1. Navigate to the AWS Private CA Connector for Active Directory console.
2. Choose the connector you just created from the Connectors for Active Directory list and then choose View details.
3. On the details page for the connector, find the Templates section and then choose Create template.
4. On the Create template page, in the Template creation method section, choose Start from a predefined template (default) and select Kerberos Authentication from the list.
5. In the Template settings section, provide the following information:
   1. Template name: Kerberos Authentication
   2. Template schema version: Template version 2
   3. Client compatibility: Windows 8 and up / Windows Server 2016 and up
6. In the Certificate settings section, use default settings.
   Note: When using AWS Private CA in Short-lived certificate mode, you must configure Validity and Renewal periods to match:
   1. Validity Period: 7 days
   2. Renewal period: 1 Days
7. In the Groups and permissions section, click on Add new groups and permissions to configure the required groups and enrollment settings as needed. The example below allows all domain controllers in a particular domain request a certificate from AWS Private CA. Note: Security identifier (SID) value is specific to your domain. You can run PowerShell command Get-ADGroup -Identity “Domain Controllers” on a directory administration EC2 instance to get the SID.
   1. Display name: Domain Controllers
   2. Security Identifier: S-1-5-##-##########-##########-##########-516
   3. Enroll: Allow
   4. Auto-enroll: Allow
8. Use default settings for all other sections.
9. Choose Create template.

Step 5: Verify Integration

1. Verify Certification Authority Object in Active Directory

When the new connector is successfully created, a new certificationAuthority object for AWS Private CA is automatically generated in Active Directory.

1. Open the Active Directory Sites and Services management console.
2. On the View menu, select Show Services Node.
3. Expand Services > Public Key Services, and then select Certification Authorities.
4. Confirm that the object for AWS PCA appears as acm-pca-ID.

2. Verify Root Certificate in Trusted Root Certification Authorities

The AWS Private CA Root Certificate must be added to the trusted root store for the domain.

1. On a domain-joined machine (e.g., a WorkSpace), open the Certificates management console for the local computer (certlm.msc).
2. Expand Trusted Root Certification Authorities and select the Certificates folder.
3. Locate the AWS PCA certificate based on its Common Name and open it.
4. Go to the Certification Path tab and validate that the Certificate Status is: "This certificate is OK."

3. Enable CA Enrollment Policy

Enable Managed AD certificate autoenrollment by running the following command in AWS CLI or Cloudshell:

aws ds enable-ca-enrollment-policy \
    --pca-connector-arn MyPcaConnectorAdArn \
    --directory-id MyDirectoryId

Note: MyPcaConnectorAdArn and MyDirectoryId are placeholders. Use your actual PCA Connector AD ARN and directory ID.

This can take time to propagate, so wait at least 30 minutes before continuing. Upon completion the managed AD should receive a new group policy titled AWS ManagedAD PCA GPO.

4. Verify Domain Controller Certificate Enrollment

Domain controller certificates are installed automatically via auto-enrollment. To verify this remotely:

1. Open the Certificates management console (certlm.msc) on an AWS Managed Microsoft AD administration instance.
2. Right-click on Certificates (Local Computer), select Connect to another computer, and enter the FQDN of your Domain Controller.
3. Expand Personal and select the Certificates folder.
4. Locate the certificate issued to the Domain Controller (based on its FQDN) and confirm the following:
   • It was issued by AWS Private CA.
   • It uses the Kerberos Authentication template.
5. Open the certificate, navigate to the Certification Path tab, and validate that the Certificate Status is: "This certificate is OK."

5. Verify Enterprise Store Deployment

Run the following commands on a domain-joined machine (e.g., a WorkSpace) to confirm that the Root certificate has been correctly published to both the NTAuth and Root enterprise stores:

# Verify the NTAuth enterprise store
certutil -viewstore -enterprise NTAuth 

# Verify the Root enterprise store
certutil -viewstore -enterprise Root

Note: Certificate auto-enrollment takes time based on different factors like domain replication, group policy and other processes. In some cases, this can take over eight hours.

---

Step 6: Enable CBA for WorkSpaces

1. Navigate to the WorkSpaces Console > Directories.
2. Select your directory and choose Actions > Update Directory Settings.
3. Under Certificate-based authentication, toggle it to Enabled.
4. Save the settings. WorkSpaces will now attempt to use certificates for user logon.

---

Troubleshooting: Analysis of Authentication Failures

If CBA authentication fails, check the Security.evtx log on the WorkSpace for Event ID 4625. Identify the failure code and refer to the Microsoft documentation for detailed explanations.

Also, you can create a new workspace for a new user to ensure CBA authentication succeed.

---

Workaround: Manually publish the Root Certificate to NTAuthCA

When using AWS Managed Microsoft AD, the Root CA certificate should be automatically published to the NTAuth enterprise store by the PCA Connector for AD. However, if you run the following command during Step 5 - Verify Enterprise Store Deployment and the certificate is not present in the NTAuth store:

certutil -viewstore -enterprise NTAuth

You can manually publish the Root Certificate as a workaround:

1. Open certlm.msc on your AD admin instance.

2. Export your Root CA certificate as a .cer file from Trusted Root Certification Authorities.

   Note: If you don't see the Root CA certificate under Trusted Root Certification Authorities, reboot your AD admin instance.

3. Run PowerShell as Administrator:

certutil -dspublish -f "C:\Path\To\Certificate.cer" NTAuthCA

4. After publishing, verify again:

certutil -viewstore -enterprise NTAuth

---

Conclusion

You have successfully implemented Certificate-Based Authentication for WorkSpaces using AWS Private CA Connector for AD, bypassing the complexity of traditional AD CS.