This blog post is about a recent issue I had to troubleshoot. The original mission was quite simple and something I am very much used to: deploy 802.1x authentication on the Wi-Fi infrastructure using EAP-TLS (currently the best recommended option that uses certificates on both the RADIUS servers and the wireless clients). Infrastructure is fairly common with Microsoft NPS servers playing as RADIUS servers and the internal PKI running on ADCS (Active Directory Certificate Services).
But there was another constraint that I do not usually deal with: there are multiple Windows domains running inside the company and inter-domain EAP-TLS authentication needs to work. This constraints comes from the fact that users and servers are not in the same domains. So this means that users/computers from the BLUE domain and with a BLUE certificate need to be able to authenticate on a NPS server which is part of the RED domain and, therefore, using a RED certificate.
After I had finished configuring everything (or so I thought…), I stumbled on an authentication issue. Here is the error log from the NPS server when a client tries to authenticate:
Error 295: A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider
A quick packet capture on the wireless clients showed that the NPS server was sending an Access-Reject as a result of this issue.
Of course trust relationships were established between domains so the RED NPS can look users and computers up on the BLUE domain (it is a very important step because NPS is not only authenticating but checking the user or computer object actually exists in the directory).
Right away, I opened the Certificate store on the RED NPS servers to make sure the BLUE Root CA was imported in the “Trusted Root CA”, which was the case.
But here is the point I was missing. You need to import the BLUE Root CA inside a specific store called the NTAuthCertificates store. There are two methods to achieve this:
- Method 1 – GUI: on the RED ADCS server, start pkiview.msc and import the BLUE Root CA inside the NTAuthCertificates store
- Method 2 – CLI: on the RED ADCS server, use the following CLI command to import the BLUE Root CA inside the NTAuthCertificates store
certutil -dspublish {CAcert.cer} NTAuthCA
I then suggest you check the import was successfull using the following command on the NPS server:
certutil -enterprise -verifystore NTAuthYou should first see the RootCA of the RED domain and then the BLUE RootCA you imported into NTAuth:
Important: if you don’t see the Root CA, you might need to reload the NPS server.
I decided to write this blog post because I struggled to find this last bit of information on this issue. I hope this will be of some help for others!
Of course, for authenticating users and computers of the BLUE domain, we are missing a few other things and you will also need to generate and install a certificate from the BLUE domain (signed bu the BLUE Root CA) on the RED NPS. And then configure a specific policy rule on NPS that will make use of this certificate. But the goal of this blog post is not to go into details on configuring authentifcation on NPS but rather talk about that specific NTAuthCertificates store in a multi-domain Microsoft environment.
A reference blog that helped me during my research: https://www.gradenegger.eu/en/the-request-for-a-certificate-fails-with-the-error-message-a-certification-chain-processed-correctly-but-one-of-the-ca-certificates-is-not-trusted-by-the-policy-provider-0x800b0112-21/