Joe Garcia joe27256 at
Tue Jul 13 14:47:32 CEST 2021

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.


More information about the Freeradius-Users mailing list