Client Certificate Authentication with AD Mapping
To implement Client Certificate Authentication with AD Mapping, the environment must be prepared outside of the Thinfinity Workspace console. If these steps aren’t followed, the AD Mapping feature will fail even if the settings in your tool are correct.
Prerequisites for Client Certificate and AD Mapping
- Trusted Root CA: The Root Certificate Authority (CA) that issued the client certificates must be installed in the Trusted Root Certification Authorities store on the Thinfinity Workspace server.
- Client Certificate Availability: Users must have their unique client certificates (usually in
.pfxor.p12format) installed in their local “Current User” certificate store or browser. - Active Directory User Mapping: Each user’s certificate must be linked to their AD account. This is typically done via the
altSecurityIdentitiesattribute.- How to check: In AD Users and Computers, enable Advanced Features, open a User, go to the Attribute Editor tab, and verify the certificate mapping is present.
- Certificate Revocation List (CRL) Access: The Thinfinity Workspace server must be able to reach the CRL distribution point (usually via HTTP or LDAP) to verify that a client certificate hasn’t been revoked.
- Matching UPN/Email: Ensure the Subject or Subject Alternative Name (SAN) in the client certificate matches the User Principal Name (UPN) or email address in Active Directory for seamless mapping.
If a user is prompted for a certificate but still sees a login password prompt, it usually means the certificate was accepted by the server (Binding), but the AD Mapping failed because the user object in Active Directory does not have the certificate’s identity linked to it.
Troubleshooting Certificate and AD Mapping Errors
When a certificate handshake fails, the error messages can be cryptic. The following table will save you hours of trial and error.
If users cannot connect or are not being automatically logged in, check the Thinfinity logs for the following common scenarios:
| Error/Symptom | Potential Cause | Solution |
|---|---|---|
| “403.7 - Client Certificate Required” | The browser did not send a certificate, or the user selected Cancel on the certificate picker. | Ensure the user has their .pfx file installed in the Personal store of their local machine. |
| “Certificate Chain Invalid” | The Thinfinity Workspace server does not recognize the Authority that issued the client certificate. | Import the Root CA certificate into the “Trusted Root Certification Authorities” store on the Thinfinity Workspace server. |
| “The certificate is revoked” | The certificate has been marked as invalid by the CA, or the server cannot reach the CRL/OCSP link. | Verify internet/LDAP access for the server or check the certificate’s expiration date. |
| User prompted for password (Mapping failure) | The certificate was accepted, but Thinfinity Workspace couldn’t find a matching user in Active Directory. | Verify that the certificate thumbprint or Subject is mapped in the user’s altSecurityIdentities attribute in AD. |
| “Store not found” | The Store name entered in the Binding configuration is misspelled or inaccessible. | Ensure you are using standard codes like MY or ROOT and that the service has permission to read the store. |
How to Test Without Impacting Users
To perform a quick test:
- Isolate the Handshake: Disable Require AD Mapping but keep Require Client Certificate enabled.
- Verify Access: If the user can reach the login page after selecting a certificate, the Handshake/Store configuration is correct.
- Re-enable Mapping: Turn Require AD Mapping back on. If it fails now, the issue is strictly with the Active Directory configuration (the link between the certificate and the user object).
Some browsers (like Chrome and Edge) cache the certificate choice. If a user selects the wrong certificate, they may need to restart their browser or clear their “SSL State” in Windows Internet Options to be prompted again.
For details on how to connect to a remote AD, see AD Cache Tab.