Simplify certificate-based authentication for AppStream 2.0 and WorkSpaces with AWS Private CA Connector for Active Directory

In this post, we explain how the AWS Private CA Connector for Active Directory simplifies and accelerates the configuration of certificate-based authentication (CBA) for Amazon AppStream 2.0 and Amazon WorkSpaces. We provide an overview of AWS Private Certificate Authority and Active Directory Certificate Services in this context. We discuss the benefits of using the AWS Private CA as a replacement for Active Directory Certificate Services and include configuration steps.

If you are using a SAML 2.0 Identity Provider (IdP) with AppStream 2.0 or WorkSpaces, you can use CBA to improve the login user experience. CBA eliminates the user prompt for the Active Directory domain password. This allows single sign-on from the SAML 2.0 IdP into the AppStream 2.0 instance or WorkSpace. To learn more about CBA, visit How to configure CBA for WorkSpaces and How to configure CBA for AppStream 2.0.

Overview

The role of AWS Private CA and Active Directory Certificate Services

CBA in AppStream 2.0 and WorkSpaces relies on a combination user certificates and virtual smart cards. This allows passwordless authentication to Windows machines that are members of an Active Directory domain. There are two key infrastructure components required to make this possible.

AWS Private CA is used to issue and manage the user certificates. AppStream 2.0 and WorkSpaces services request user certificates from the AWS Private CA automatically during the session authentication process. Users are then authenticated to Active Directory using a virtual smart card provisioned with the certificates. The AWS Private CA may be used as the root or a subordinate CA for the certificate chain, depending on the CA hierarchy required.

Active Directory Certificate Services (AD CS) is what enables the Active Directory domain for virtual smart card login. Specifically, Active Directory Certificate Services provides the Public Key Infrastructure (PKI), including the Active Directory integrated Certificate Authority (or Enterprise CA). The Certificate Authority is used to issue and manage domain controller certificates. These certificates enable the Key Distribution Center (KDC) to prove its identity to other members of the domain, as required for CBA and virtual smart card login.

1. 1. DC/Kerberos certificates are automatically issued and installed on all domain controllers via certificate auto-enrollment with AD CS.
  2. AWS Private CA is configured as subordinate CA to AD CS Root CA. AWS Private CA certificate is then manually published to AD RootCA and NTAuthCA stores.
  3. CA certificate chain is replicated automatically to all domain machines via AD.
  4. Users authenticate with SAML 2.0 provider.
  5. Federated user is authorized to access AppStream 2.0 / WorkSpaces resource.
  6. Based on attributes in the SAML assertion, WorkSpaces/AppStream is issued a user certificate, signed by AWS Private CA.
  7. AppStream 2.0 / WorkSpaces service publishes the user certificate to the Windows machine.
  8. AppStream 2.0 / WorkSpaces agent seamlessly authenticates user to Active Directory using the user certificate.

AWS Private CA Connector for AD as a replacement for Active Directory Certificate Services

The Connector for AD allows AWS Private CA to take on the role of an Active Directory integrated Enterprise CA. It deploys Active Directory Certificate Services to provide the required certificate templates and enrollment services to machines in your Active Directory. This approach greatly simplifies the implementation effort by not having to deploy Active Directory Certificate Services infrastructure. It reduces operational overhead and increases security with CA private keys stored in FIPS 140-2 Level 3 validated hardware security modules (HSMs).

1. 1. AWS Private CA is configured and integrated with AD via the connector. As an Enterprise CA, its CA certificate is automatically published to the AD RootCA and NTAuthCA stores. DC/Kerberos certificates are automatically issued and installed on domain controllers via certificate auto-enrollment with AWS Private CA.
  2. CA certificate chain is replicated automatically to all domain machines via AD.
  3. Users authenticate with SAML provider.
  4. Federated user is authorized to access AppStream 2.0 / WorkSpaces resource.
  5. Based on attributes in the SAML assertion, AppStream 2.0 / WorkSpaces is issued a user certificate, signed by AWS Private CA.
  6. AppStream 2.0 / WorkSpaces service publishes the user certificate to the Windows machine.
  7. AppStream 2.0 / WorkSpaces agent seamlessly authenticates user to Active Directory using the user certificate.

Walkthrough

In this walkthrough, you will configure AWS Private CA, the AWS Private CA Connector for Active Directory, and certificate-based authentication for AppStream 2.0 or WorkSpaces .

Prerequisites

AWS Console with required IAM permissions to perform commands for the AWS Services used.
Functional AppStream 2.0 or 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. For more information, see Create Assertions for the SAML Authentication Response.
- Add the sts:TagSession permission to your IAM role trust policy used with your SAML 2.0 configuration if it is not already present. This permission is required to use certificate-based authentication. For more information, see Create a SAML 2.0 Federation IAM Role.
Self-Managed Active Directory
- AWS Managed Active Directory is not supported.
AWS Directory Service AD Connector
- You can use existing connector configured with WorkSpaces directories or create a new one for this purpose. Note: Active Directory service account will require additional permissions listed in “Step 3: Create PCA Connector for AD” below.
Plan and design your Certificate Authority hierarchy based on your needs
- Note: Configuration steps included in this blog assume a one-level CA hierarchy for simplicity. A single AWS Private CA instance is deployed in short-lived mode to serve as the Root CA and to issue certificates.
- Refer to AWS Private CA documentation for guidance when deploying in production environments where separate administration controls and a full chain of trust is required.
- Short-lived mode is recommended specifically for use with AppStream 2.0 and WorkSpaces CBA.

Configuration steps

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

Create an Amazon Simple Storage Service (Amazon S3) bucket, keep ACLs disabled, and block all public access.
Create a CloudFront distribution:

1. Navigate to the Amazon CloudFront console.
2. Create a Distribution.
3. For Origin Domain, select the S3 Bucket created as the Origin domain specified in the first step.
4. For Origin access, select Origin access control settings (recommended).
5. Choose Create control setting.
6. Choose Create distribution.

Create the S3 bucket policy:

1. Navigate to the Amazon S3 Console.
2. Select the S3 bucket that you created at the beginning of this step.
3. Choose the Permissions tab.
4. Select the Bucket Policy, choose Edit.
5. Enter as the following. Replace S3-BUCKET-NAME, AWS-ACCOUNT-NUMBER, and CLOUDFRONT-DISTRIBUTION with your values. Then, choose Save.

{
    "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"
   }
}

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"
   }
}

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

Step 3: Create PCA Connector for AD

Follow these steps to create and a configure a connector using the AWS Management Console. AWS CLI create-connector command or the CreateConnector API action can also be used.

Navigate to the AWS Private CA Connector for Active Directory console.
On the first-time service landing page or the Connectors for Active Directory page, choose Create connector.
Under Select your Active Directory type, choose On-premises Active Directory with AWS AD Connector.
Under Select your directory, choose your directory from the list.
Under Select security groups for VPC endpoint, choose a security group from the list or create new one.
Under Prerequisites, download and run the PowerShell script to delegate permissions to your service account. For more information about the required permissions, see Prerequisites.
In the Private certificate authority section, choose a private CA from the list.
After providing the required information and reviewing your choices, choose Create connector. This opens the Connectors for Active Directory details page where can view the progress of your connector as it is created.
Note the Certificate enrollment policy server endpoint URL as you will be using it in Step 4 below.

Step 4: Configure Active Directory policies

Group policy is used to configure certificate auto-enrollment settings for domain controllers, including the URL to reach the AWS Private CA Connector endpoint. Follow the group policy configuration steps in AWS Private CA documentation.

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

Navigate to the AWS Private CA Connector for Active Directory console.
Choose the connector you just created from the Connectors for Active Directory list and then choose View details.
On the details page for the connector, find the Templates section and then choose Create template.
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.
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
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
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 domain controller to get the SID.
1. Display name: Domain Controllers
2. Security Identifier: S-1-5-##-##########-##########-##########-516
3. Enroll: Allow
4. Auto-enroll: Allow
Use default settings for all other sections.
Choose Create template.

Step 6: Verify AWS Private CA and Active Directory integration

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

Open the Active Directory Sites and Services management console.
On the View menu, select Show Services Node.
Expand Services, expand Public Key Services, and then select the Certification Authorities
Confirm the object for AWS PCA shows as acm-pca-ID.

The PCA Root Certificate is added to the trusted root certification authorities for the domain.

On a domain-joined machine, open the Certificates management console for the local computer (certlm.msc).
Expand Trusted Root Certification Authorities and select the Certificates
Locate the AWS PCA certificate based on the common name and open it.
Choose Certification Path tab and validate Certificate Status is This certificate is OK.

Domain controller certificates are installed through auto-enrollment.

Open the Certificates management console on a domain controller for the local computer.
Expand Personal and select the Certificates
Locate certificate based on the domain controller’s FQDN and confirm it has been issued by AWS PCA and using Kerberos Authentication template.
Open certificate, choose Certification Path tab and validate Certificate Status is This certificate is OK.

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 7: Enable CBA for WorkSpaces or AppStream 2.0

Follow the administration guide for enabling certificate-based authentication with AppStream 2.0 or WorkSpaces now that AWS Private CA is an Enterprise CA in your Active Directory domain.

AWS CloudTrail is used to verify AppStream 2.0 or WorkSpaces services are requesting user certificates from AWS Private CA. In CloudTrail Event history, you can view GetCertificate and IssueCertificate event names from acm-pca.amazonaws.com event source made by the EcmAssumeRoleSession user name. These events are recorded for every WorkSpaces or AppStream 2.0 certificate-based authentication request.

Cleaning up:

If you no longer need the resources that were created following this blog, follow the steps below.

In the AppStream 2.0 or WorkSpaces console, disable Certificate-Based Authentication in the directory configuration.
In the AWS Private CA Connector for Active Directory console, delete the connector that was created in step 3.
Delete Active Directory GPO that was created in step 4.
Revoke certificates on PCA that have been issued to domain controllers.
Delete certificates installed on domain controller issued by AWS Private CA.
Remove certificationAuthority object from Active Directory.
In AWS Private CA Console, delete the Private CA you created in step 2.
In CloudFront Console, delete the CloudFront Distribution you created in step 1.
In the S3 Console, delete the S3 bucket you created in step 1.

Conclusion

In this post, you learned how the AWS Private CA Connector for Active Directory can be used to simplify the configuration of CBA with AppStream 2.0 and WorkSpaces. The main benefit of using the connector for this use case is to avoid having to deploy and manage Active Directory Certificate Services.

To learn more about services mentioned in the blog, refer to the Connector for AD, AWS Private CA , CA best practices, and AWS Directory Services documentation. You can get started creating CAs with AWS Private CA using the AWS Management console.

	Roberto is a Solutions Architect and End User Computing Specialist at AWS, with over 20 years of IT industry experience. He helps customers in all phases of the cloud adoption journey, with strategy, design, and the deployment of AWS-optimized solutions.
	Jeremy Schiefer is a Principal Security SA with Amazon Web Services. He is a member of the end-user compute community and has authored several blogs and workshops. Jeremy is passionate about security, 3D printing, and Internet of things (IoT).

Desktop and Application Streaming