## Useful NPS & certificate stuff (for myself)

Came across an odd problem at work the other day involving NPS and Wireless APs. We have an internal wireless network that is set to authenticate against Microsoft NPS using certificates. The setup is quite similar to what is detailed here, with the addition of using an internal CA issued certificates for NPS to authenticate the users (as detailed here or here for instance).

All wireless clients stopped being able to connect to the wireless. That’s when I realized the logs generated by NPS (at C:\Windows\System32\Logfiles) are horrendous. One option is to change the log format to “IAS (Legacy)” and “Daily” and use a script such as the one here to analyze. Side by side it is also worth changing the format to “DTS Compliant” as that produces a better readable XML output. All of this stuff is in the “Accounting” section BTW:

Pro Tip: If you go with the XML format and use Visual Studio code, you can prettify the XML as mentioned here

From the logs we could see entries like this:

    <Authentication-Type data_type="0">5</Authentication-Type>    <Packet-Type data_type="0">3</Packet-Type>    <Reason-Code data_type="0">259</Reason-Code>

In this case the packet type data of 3 means the access was rejected, and the reason code 259 means CRL check failed. (Nope, I don’t know these codes of the top of my head! My colleague who did the troubleshooting came across this. If you use the PowerShell script I mentioned above that converts some of the codes to readable values, but it too missed error 259). If you want to read more about the flow of traffic an why rejection might happen, this article is a good read.

We didn’t really get to the bottom of this issue (it looks to be one of those random issues) but I spent some time reading up on certificates and NPS etc. so want to put that info here. Mainly, certutil. This tool can be used to check CRLs etc. I still haven’t gotten to the bottom of the above issue (why NPS couldn’t retrieve CRLs) but I picked up a bit of CRL stuff while troubleshooting so wanted to note that somewhere.

The command certutil /crl (from an admin command prompt on the CA) causes it to publish the CRL. In my case it was via LDAP, and the command returned no errors. You can find the CRL URL from any certificate. In my case it was a long LDAP URL that looked something like this: ldap:///CN=blahblah,xxxxl?certificateRevocationList?base?objectClass=cRLDistributionPoint.You can use certutil /url with the URL to query it. You can also use ADSI Edit to view the configuration partition and go to the URL to see the last modified timestamp etc.

The certutil command has many more useful switches (like in this blog post and this wiki entry – the latter has many more examples). For example you can export a certificate to a file and then run a command such as certutil /verify /urlfetch \path\to\certificate.cer. This will verify the certificate up the chain, and also check the CRL specified in the certificate.

It is also possible to export a CRL from the CA: certutil /getcrl \path\to\file.crl. You can also view the exported CRL via a command like: certutil /dump \path\to\file.crl. Lastly you can import it to a different server via: certutil /addstore CA \path\to\file.crl

In our case we ended up exporting the CRL from the CA and importing to the NPS server to quickly workaround the issue.

Later I learnt that there’s a reg key which can be used to disable CRL checking by NPS. Not that you want to do that permanently, but useful as a quick fix. Another thing I learnt is that there’s a reg key that controls how long the NPS server caches the TLS handle of authenticated computers. By default it is 10 hours, but can be extended.