Enable mTLS authentication in AD Connector for use with smart cards - AWS Directory Service

Enable mTLS authentication in AD Connector for use with smart cards

You can use certificate-based mutual Transport Layer Security (mTLS) authentication with smart cards to authenticate users into Amazon WorkSpaces through your self-managed Active Directory (AD) and AD Connector. When enabled, users select their smart card at the WorkSpaces login screen and enter a PIN to authenticate, instead of using a username and password. From there, the Windows or Linux virtual desktop uses the smart card to authenticate into AD from the native desktop OS.


Smart card authentication in AD Connector is only available in the AWS GovCloud (US-West) region, and only with WorkSpaces. Other AWS applications are not supported.


To enable mTLS authentication using smart cards for the Amazon WorkSpaces client, you need an operational smart card infrastructure integrated with your self-managed AD. For more information on how to set up smart card authentication with Amazon WorkSpaces and AD, see the Amazon WorkSpaces Administration Guide.

Before you enable smart card authentication for WorkSpaces, please review the following considerations:

CA certificate requirements

AD Connector requires a certificate authority (CA) certificate, which represents the issuer of your user certificates, for smart card authentication. AD Connector matches CA certificates with the certificates presented by your users with their smart cards. Note the following CA certificate requirements:

  • Before you can register a CA certificate, it must be more than 90 days away from expiration.

  • CA certificates must be in Privacy-Enhanced Mail (PEM) format. If you export CA certificates from inside Active Directory, choose Base64-encoded X.509 (.CER) as the export file format.

  • All root and intermediary CA certificates that chain from an issuing CA to user certificates must be uploaded for smart card authentication to succeed.

  • A maximum of 100 CA certificates can be stored per AD Connector directory

  • AD Connector does not support the RSASSA-PSS signature algorithm for CA certificates.

User certificate requirements

User certificates presented to AD Connector must include the userPrincipalName (UPN) of the AD user in the subjectAltName (SAN) field of the certificate.

Certificate revocation checking process

In order to perform smart card authentication, AD Connector must check the revocation status of user certificates using Online Certificate Status Protocol (OCSP). To perform certificate revocation checking, an OCSP responder URL must be internet-accessible. If using a DNS name, an OCSP responder URL must use a top-level domain found in the Internet Assigned Numbers Authority (IANA) Root Zone Database.

AD Connector certificate revocation checking uses the following process:

  • AD Connector must check the Authority Information Access (AIA) extension in the user certificate for an OCSP responder URL, then AD Connector uses the URL to check for revocation.

  • If AD Connector cannot resolve the URL found in the user certificate AIA extension, or find an OCSP responder URL in the user certificate, then AD Connector uses the optional OCSP URL provided during root CA certificate registration.

    If the URL in the user certificate AIA extension resolves but is unresponsive, then user authentication fails.

  • If the OCSP responder URL provided during root CA certificate registration cannot resolve, is unresponsive, or no OCSP responder URL was provided, user authentication fails.


AD Connector requires an HTTP URL for the OCSP responder URL.

Other considerations

Before enabling smart card authentication in AD Connector, consider the following items:

  • AD Connector uses certificate-based mutual Transport Layer Security authentication (mutual TLS) to authenticate users to Active Directory using hardware or software-based smart card certificates. Only common access cards (CAC) and personal identity verification (PIV) cards are supported at this time. Other types of hardware or software-based smart cards might work but have not been tested for use with the WorkSpaces Streaming Protocol.

  • Smart card authentication replaces username and password authentication to WorkSpaces.

    If you have other AWS applications configured on your AD Connector directory with smart card authentication enabled, those applications still present the username and password input screen.

  • Enabling smart card authentication limits the user session length to the maximum lifetime for Kerberos service tickets. You can configure this setting using a Group Policy, and is set to 10 hours by default. For more information on this setting, see Microsoft documentation.

Enabling smart card authentication

To enable smart card authentication, use the following steps to import your certificate authority (CA) certificates into AD Connector using the AWS Directory Service API or CLI. And then enable smart card authentication for WorkSpaces on your AD Connector.

STEP 1: Enable Kerberos constrained delegation for the AD Connector service account

To use smart card authentication with AD Connector, you must enable Kerberos Constrained Delegation (KCD) for the AD Connector Service account to the LDAP service in the self-managed AD. directory.

Kerberos Constrained Delegation is a feature in Windows Server. This feature enables administrators to specify and enforce application trust boundaries by limiting the scope where application services can act on a user’s behalf. For more information, see Kerberos constrained delegation.

  1. Use the SetSpn command to set a Service Principal Name(SPN) for the AD Connector service account in the self-managed AD. This enables the service account for delegation configuration.

    The SPN can be any service or name combination but not a duplicate of an existing SPN. The -s checks for duplicates.

    setspn -s my/spn service_account
  2. In AD Users and Computers, right-click on the AD Connector service account and select Properties.

  3. Choose the Delegation tab.

  4. Choose the Trust this user for delegation to specified service only and Use any authentication protocol radio buttons.

  5. Choose Add and then Users or Computers to locate the domain controller.

  6. Choose OK to display a list of available services used for delegation.

  7. Choose the ldap service type and click OK.

  8. Click OK again to save the configuration.

  9. Repeat this process for other domain controllers in AD. Alternatively you can automate the process using PowerShell.

STEP 2: Register the CA certificate in AD Connector

To register your CA certificate in AD Connector, use the following CLI command:

aws ds register-certificate --directory-id your_directory_id --certificate-data file://your_file_path --type ClientCertAuth --Client-Cert-Auth-Settings '{"OCSPUrl":"http://your_OCSP_address"}'

For the certificate data, point to the location of your CA certificate. To provide a secondary OCSP responder address, use the optional ClientCertAuthSettings object. The response provides a certificate ID.

STEP 3: Verify your CA certificate registration status

To verify the status of a CA certificate registration or a list of registered CA certificates, run the following command:

aws ds list-certificates --directory-id your_directory_id

If the status value returns Registered, you have successfully registered your certificate.

STEP 4: Enable smart card authentication for WorkSpaces

To enable smart card authentication for WorkSpaces in AD Connector, use the following CLI command:

aws ds enable-client-authentication --directory-id your_directory_id --type SmartCard

If successful, AD Connector returns an HTTP 200 response with an empty HTTP body.