In a previous post, we have seen how we can provide client certificate authentication.
That was pretty simple, because we used an enterprise CA, an adfs server and a user account, all in the same domain.
An other challenge is to use Client Certificate provided by a Standalone Certification Authority (in an other forest or in a workgroup, and of course not integrated in the Active Directory).
The global architecture I wanted to test is the following :
Here is how I have achieved this scenario, with the troubleshooting method
First think to do is to request the StandAlone CA (named USER CA in my case) for an User Certificate. I have configured my StandAlone CA to authorize domain users to request user certificates. Automatically, with the User Template, I receive a Client Authentication Certificate.
- The CDP mentionned in the Certificate Properties must be accessible from the ADFS Server.
- The Subject must be a valid path in the Active Directory (in my case : (E = firstname.lastname@example.org,CN = James Kirk,OU = Users,OU = Corporation,DC = labiam,DC = corp) OR the subject alternative name must contain a Principal Name that is the UPN of the user (for example : Principal Nameemail@example.com). This is the User Mapping that IIS uses to find the user in the Active Directory. If that is not the case, you may encountered a “Logon failure: unknown user name or bad password”
Now, I have a Certificate. If I try to signin on my Federation Service, I receive a “403 – Forbidden: Access is denied.”
Not an ADFS error, but an IIS error. We can use the Failed Request Tracing logs to see what is happening. To enable Failed Request Tracing :
- Check that you have installed the IIS Tracing Module
- In the IIS Management Console, under the Default Web Site, click on the Failed request tracing and Enable
- You can now define your filter. In my case, my filter is concerning the 403 return code
If we look in the last Tracing log, we can see the following issue : Access Denied
I add the Certification Authority Certificate Chain in the Trusted Root Certification Authorities, and signin again. Now I have the following message :
Yes ! an ADFS error. Have a look on the ADFS Server Event Viewer. There are 2 events :
- Source : AD FS 2.0, Event ID 111, 364
The Federation Service encountered an error while processing the WS-Trust request.
Microsoft.IdentityModel.SecurityTokenService.FailedAuthenticationException: MSIS3019: Authentication failed. —> System.IdentityModel.Tokens.SecurityTokenValidationException: ID4070: The X.509 certificate ‘Efirstname.lastname@example.org, CN=James Kirk, OU=Users, OU=Corporation, DC=labiam, DC=corp’ chain building failed. The certificate that was used has a trust chain that cannot be verified. Replace the certificate or change the certificateValidationMode. ‘A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider.
My Certificate is detected, but the authentication failed. After a quick search, I find that the thumbprint of the root CA Certificate must be located in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ EnterpriseCertificates\NTAuth\Certificates registry key.
The NTAuth Certificate Store are trusted to both issue authentication (logon) certificates for any user in the forest and enable logon for smart cards, Internet Information Services (IIS) mapping, and Extensible Authentication Protocol-Transport Layer Security (EAP-TLS).
Sounds good. First, I have to extract the public key of my Certification Authority. We can do that with the Certificate MMC, and export the certificate without the private key.
Then, use the CertUtil command to add the .cer into the NTAuth Certificate Store :
certutil -enterprise -addstore NTAuth <CertificationAuthorityKey.cer>
And that’s it, authentication is successfull and I can access to my Claims Aware App :
To summarize, what we need :
- A StandAlone Certification Authority that deliver Client Authentication Certificate with an alternative name containing the UPN of the user
- No needs to import the delivered certificate in User Object in Active Directory
- Add the Certification Authority Certificate Chain in the Trusted Root Certification Authority of your ADFS Server (and on the client computer)
- Add the public key of the root CA in the NTAuth Enterprise Store
- Publish the CRL