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.