PEAP/MSCHAPv2 with FreeRADIUS vs NPS

[Joe Garcia]

Alan DeKok <aland at 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.