Setting up smart card authentication
Last updated
Last updated
Certificate-based authentication is provided by Access Manager, with the optional support for requiring smart-card authentication.
Certificates must contain a principal name attribute in their Subject Alternative Names which specifies the user's UPN as found in Active Directory.
Limited support is available for use of altSecurityIdentities in cases where certificates are used without a UPN, however these are not supported outside the forest where AMS is located.
To use smart card authentication, where the smart cards are issued by an Active Directory-integrated certificate authority, configure Access Manager as follows.
Open the Lithnet Access Manager Service Configuration Tool
From the App configuration/User authentication, select Smart card or other certificate as the authentication provider
Select Require smart card login extended key usage
Select Trust only Enterprise CAs registered in this domains NTAuth store
More advanced scenarios are supported through the use of being able to provide your own additional mandatory EKUs, or restricting authentication to specific issuers. Seek advice from your internal team that manages smart card issuance to if you are not sure if any of these settings are required.
In line with the certificate-based authentication changes announced by Microsoft in KB5014754, Access Manager by default now only accepts certificates containing the user's SID in an extension with OID 1.3.6.1.4.1.311.25.2.
If you are using older-style certificates, you need to select Enable weak identity bindings and select enable UPN mapping.
If you do not use the SID or UPN fields in the certificate, and use the altSecurityIdentities capability in Active Directory to support certificates without a UPN, you'll need to perform some additional steps in AMS to enable this support.
The caveat with this implementation is that this only works in the forest that the AMS service is located within. As web-based certificate authentication happens at the TLS level, AMS is unable to prompt for a username or domain hint. Therefore, AMS can only search the local global catalog for the altSecurityIdentity values.
In line with the Microsoft implementation for altSecurityIdentities, AMS searches the directory for a user match in the following order
(*) Use of these altSecurityIdentity types requires that certificate issuer validation against the NT Auth store is enabled
(^) These altSecurityIdentity types are considered 'weak bindings' and require the use of the
Enable weak identity bindingsoption.
In certain scenarios - such as Access Manager running behind a TLS-terminating load balancer - certificate authentication may not work out of the box. Because the TLS connection is re-encrypted before it reaches Access Manager, the client certificate is not passed along to the server itself.
However, some load balancers or reverse proxies include a feature called 'Certificate Forwarding', where the load balancer validates the certificate, and passes the user's public key along as a header to the backend server (in this case, Access Manager).
This option allows you to specifiy a header which Access Manager will use to extract user certificates from for authentication.
It is important to note that, unless properly secured, any user may send this header to the Access Manager server - allowing impersonation. Therefore, Access Manager requires that you specify particular load balancers or proxies you expect to be using this feature. By default, even when enabled, Access Manager will reject all certificate headers unless the allowlists are populated.
Configure the server to receive client certificates with the ssl_verify_client directive.
Configure the X-Client-Cert header to be forwarded to Access Manager.
This forwards the $ssl_client_escaped_cert variable, which is a URL-encoded version of the client certificate:
You can follow this guide to insert to forward the client certificate as a header to Access Manager.
