5

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 https://serverfault.com/questions/368229/802-1x-peap-gpo-that-trusts-self-signed-ca-certificate):

enter image description here

(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

Conclusion

  1. 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)?
  2. 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?
Improve this question
1
  • Microsoft pretends here or here that client certificates must be issued by the domain's enterprise CA. I assume this is valid only when I enforce AD membership?
    – user185953
    Commented Jul 30, 2020 at 17:04

3 Answers 3

Reset to default
4
  1. 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)?

No, NPS simply does not support this (!) - as per incident number 117021015302705 that was opened 2017-02-10 with Microsoft Support.

The only advice they were able to offer was to remove the default root CAs from the server(s), as I had eluded to in the question - but would not expand upon if this would be considered supported, nor what issues could arise from this within Windows itself.

If anyone at Microsoft runs across this and can further escalate or respond to this, please do - either through this post, the original incident, or my contact information on the incident.

This is an answer, but a disappointing one. I'm still hoping for some competing answers / additional options - especially any thoughts around potential mitigating factors that could be considered. (I still think some sort of an authentication proxy that could be added in-line with NPS could work well architecturally as a work-around, if such a thing existed.)

Improve this answer
1

I'm not an NPS expert but if you're using RADIUS with EAP-TLS you can configure your EAP-TLS policy to require a custom Enhanced Key Usage. Only certificates issued by your private PKI would contain this custom EKU so only those certificates would be accepted. You'd create the custom EKU on your CA and add it as an Application Policy to your certificate template, then add that custom EKU to your EAP-TLS settings on the RADIUS server. As an aside, Enterprise Root CAs are a horrible idea from a security perspective.

Improve this answer
3
  • 1
    I'm not entirely convinced that a custom EKU would be as good as restricting the server-side trust to a specific CA cert, but this would at least be something. However, I can't see that there are any options for enabling certificate restrictions for client auth within NPS - CA cert, EKU, or otherwise - hence the question here.
    – ziesemer
    Commented Feb 17, 2017 at 13:45
  • 1
    I'd also be curious to hear more about your security concerns with Enterprise Root CAs.
    – ziesemer
    Commented Feb 17, 2017 at 13:46
  • 1
    I see I can configure this on 802.1x clients (i.e. for validating the server), but I can't see a similar option on the NPS (i.e. for validating the clients)
    – user185953
    Commented Jul 30, 2020 at 15:08
1

If you're using domain CA, NPS, and auto-enrollment, then I'm assuming your clients are domain members. You could set the Network Policy condition to require a domain group (Domain Users/Computers or a custom "Trusted Users/Devices" AD group).

Technically, the domain member could still connect via a foreign cert from a Trusted CA, but it will protect from an outsider with a foreign cert.

enter image description here

Improve this answer
1
  • 1
    Is this separately authenticating the computer account? Or is it just looking at if the name of the computer in the presented certificate is a member of the specified group? Intriguing idea, at least!
    – ziesemer
    Commented Jan 22, 2020 at 2:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .