Alan DeKok <aland@deployingradius.com> writes:
Which one?
The client? A no-name embedded one used with SCADA devices that have to be controlled from central servers. If it was up to me they'd just be FreeRADIUS, but unfortunately some have to be NPS since there's lots of different vendors involved.
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.
Agreed :-). I don't think it's the admins though, they've configured it to do PEAP and as far as they're aware that's what they're getting, it's NPS that's adding the strangeness.
You'll need to look at the full log from eapol_test to see why it works.
Already done that, we've taken Wireshark captures, the eapol_test and FreeRADIUS logs, and diagnostics from the client, and made things identical to what eapol_test sends (as far as we can tell, there may be stuff inside the PEAP tunnel that we can't see and aren't not aware of). We've really tried everything we can think of, so it may be a case of someone seeing this and remembering some obscure magic they used to get it to work.
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.
What wpa_supplicant does is ignore the message and re-send the Identity Response it's just sent, which continues the negotiation. This is one of the bits that reverse-engineering the flow from eapol_test/wpa_supplicant helped with. So for anyone else who's faced with this, when doing PEAP/MSCHAPv2 with NPS, when you're expecting to get the MSCHAPv2 Challenge if instead you get an EAP vendor-specific undocumented Microsoft blob back, re-send the Identity Response a second time and then you'll get the MSCHAPv2 Challenge you should have got the first time. JG.