PEAP/MSCHAPv2 with FreeRADIUS vs NPS
aland at deployingradius.com
Tue Jul 13 16:23:00 CEST 2021
On Jul 13, 2021, at 9:57 AM, Joe Garcia <joe27256 at gmail.com> wrote:
> 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.
> 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
Can you send them to me offline? Ideally also with some test certs / private keys, so that I can decode the packet traces and see what's up.
> 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 don't recall seeing any of this before.
> What wpa_supplicant does is ignore the message and re-send the
> Identity Response it's just sent, which continues the negotiation.
Ah. That's reasonable, I guess. But sending a crappy EAP type is still stupid.
> 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.
That just depresses me.
More information about the Freeradius-Users