PEAP/MSCHAPv2 with FreeRADIUS vs NPS
This is possibly more an NPS question than a FreeRADIUS one but possibly someone here might know what to do, we're using a third-party embedded RADIUS client to authenticate to both FreeRADIUS and NPS with PEAP/MSCHAPv2. The client is sending completely standard PEAP messages to both, but while the exchange with FreeRADIUS works fine, with NPS it's rejected with either Reason Code 1/An internal error occurred or Reason Code 66/The user attempted to use an authentication method that is not enabled on the matching network policy. The NPS server admins insist that it's configured correctly and claim that since eapol_test authenticates to it the problem is at our end. Whatever NPS is doing it's quite weird and required reverse-engineering wpa_supplicant to figure out, for example it sends back an undocumented vendor-specific EAP request (vendor ID = 311/Microsoft, vendor type = 34, data = 00 00 00 01) when we're expecting an MSCHAPv2 Challenge while FreeRADIUS behaves as expected. At the moment we're stuck with finger-pointing, from our point of view whatever NPS is doing isn't anything like what the spec says and things work fine with FreeRADIUS so NPS is broken, from their point of view eapol_test works with NPS and so there's something wrong with our client. If this situation is ringing any bells with someone I'd be interested in any information we can use to move forward, and can provide more details on any part of the PEAP exchange if required. JG.
On Jul 13, 2021, at 8:47 AM, Joe Garcia <joe27256@gmail.com> wrote:
This is possibly more an NPS question than a FreeRADIUS one but possibly someone here might know what to do, we're using a third-party embedded RADIUS client to authenticate to both FreeRADIUS and NPS with PEAP/MSCHAPv2.
Which one?
The client is sending completely standard PEAP messages to both, but while the exchange with FreeRADIUS works fine, with NPS it's rejected with either Reason Code 1/An internal error occurred or Reason Code 66/The user attempted to use an authentication method that is not enabled on the matching network policy.
i.e. NPS gives completely useless errors. Wonderful.
The NPS server admins insist that it's configured correctly and claim that since eapol_test authenticates to it the problem is at our end. Whatever NPS is doing it's quite weird and required reverse-engineering wpa_supplicant to figure out, for example it sends back an undocumented vendor-specific EAP request (vendor ID = 311/Microsoft, vendor type = 34, data = 00 00 00 01) when we're expecting an MSCHAPv2 Challenge while FreeRADIUS behaves as expected.
NPS is weird. If the NPS admins want to do PEAP, then they should do PEAP. Sending a different magic EAP type is just stupid.
At the moment we're stuck with finger-pointing, from our point of view whatever NPS is doing isn't anything like what the spec says and things work fine with FreeRADIUS so NPS is broken, from their point of view eapol_test works with NPS and so there's something wrong with our client. If this situation is ringing any bells with someone I'd be interested in any information we can use to move forward, and can provide more details on any part of the PEAP exchange if required.
You'll need to look at the full log from eapol_test to see why it works. eapol_test also works with FreeRADIUS, so that's an indicator that eapol_test is good, not that NPS is good. I can't find anything in wpa_supplicant which handles a magic Microsoft EAP type. So it's not clear what's going on there. Alan DeKok.
participants (2)
-
Alan DeKok -
Joe Garcia