Restrict Microsoft Network Policy Server (NPS) to only trust client certificates from a given CA?
I’m working on an install of a Microsoft Network Policy Sever (NPS) / RADIUS server for controlling access to corporate Wi-Fi using 802.1x / WPA2-Enterprise – using client certificates for authentication.
We already have an internal AD-integrated enterprise root CA. Having auto-enrolled client certificates from here is perfect. The clients can also be configured to only accept server certificates from a given CA for server trust – such as shown here (borrowed from http://serverfault.com/questions/368229/802-1x-peap-gpo-that-trusts-self-signed-ca-certificate):
(This is also detailed at https://technet.microsoft.com/en-us/library/hh945104(v=ws.11).aspx.)
My concern here is the opposite, however. How can the NPS be restricted to only accept client certificates from our own CA? It doesn’t provide a similar dialog for “Validate client certificate”, in which I could hopefully choose only our own internal CA. Under the NPS network policy, Constraints, Authentication Methods, EAP Types – we can specify the server certificate that is presented.
Smart Card or other Certificate Properties
This server identifies itself to callers before the connection is completed. Select the certificate that you want it to use as proof of identity.
However, there is no setting visible as there is on the client side (above), which could be used to restrict which client certificate CAs are trusted.
With OpenVPN, FreeRADIUS, etc., specific trust anchors can be specified at the server-side. Call me paranoid, but should the same not be able to be configured within NPS? As-is, in addition to our own internal CA, we’re also trusting any certificates that may be issued by the default trusted root CAs (AddTrust, DigiCert, Equifax, Microsoft, Thawte, VeriSign, etc.). This may be acceptable for trusting external web servers, from internal servers where web browsing is forbidden / prevented. However, for purposes of client authentication on a wireless gateway – a breach by an otherwise unnecessary CA here could allow for unauthorized access to an internal network.
Removing other CAs from the NPS servers might work, but I question if this is supported?
I was also looking into if the root certificates could be removed for only the NPS Windows service account, while leaving the computer certificate store intact – but I believe this is addition by inheritance only, allowing only for additional trusts to be added but not removed? (Even if I’d publish a CRL for everyone else at this level, I’d need a process in place for any other root CAs that may later be added at the computer level.)
References
- https://social.technet.microsoft.com/Forums/office/en-US/a4a2ca77-541b-4158-811e-ce10a8aae107/nps-and-certificates-trust-list?forum=winserverNAP
- https://social.technet.microsoft.com/Forums/windowsserver/en-US/5b6db5e8-efc3-48ed-a201-d6039ab0969c/any-way-to-tell-which-client-side-computer-certificate-does-nps-server-use-for-validating-?forum=winserversecurity
- https://framebyframewifi.net/2016/06/13/hardening-tls-for-wlan-802-1x-authentication/
- http://serverfault.com/questions/714172/what-are-the-risks-of-adding-third-party-root-ca-certificate-into-ntauth-store
- How feasible is it for a CA to be hacked? Which default trusted root certificates should I remove?
Conclusion
- Are there any options to restrict which user certificate CAs are trusted – similar to other RADIUS providers, or as available for client-> server trust (but for server -> client trust)?
- Especially if no good options for the above, are there any other mitigating factors that can / should be considered? (I don’t see any available options for multi-factor authentication here, etc. – though we’d want to keep anything here transparent to end-users.) If nothing else, possibly some sort of authentication proxy that could filter the EAP requests before even being presented to NPS?