[EXT] 802.1X - ldap AND users file

[Brian Julin]

cedric Delaunay <cedric.delaunay at insa-rennes.fr> Wrote:
> Devices users authenticate successfully using peap/mschapV2 and ldap backend
> outer identity is configured as anonymous

> I'd like to find how to force "accept" for a special user, based on
> "mods-config/files/authorize" file
> user is logged-in on device so that is real username is kown only by inner-tunnel
> user isn't known by ldap (that's why I try with "users" file)
> user's password may change so that I don't want to check it

I believe MSCHAPv2 implies that there is mutual authentication so it is not just
that the client proves it knows the password to the server, the server also proves
(in a these days cryptographically broken way) to the client that it also knows
the client's password.

You'll probably have to switch to EAP-TTLS-PAP for this client.  If you are lucky, you'll
be able to keep PEAP-MSCHAPv2 as the first offered protocol and the client can
be configured with EAP-TTLS-PAP and will do the correct negotiation.  But if you
are not, the client will have a buggy supplicant that won't negotiate properly, or (rather
unlikely) the presence of the EAP-TTLS-PAP fallback will be noticed by other clients and cause
some sort of issue.

If this special client is stationary on the wired network and has lower security risk, it would probably
be less trouble to set up mac auth bypass for it or use mac-based port security.

If your MSCHAP is terminating in actual Microsoft AD servers or if you have been
clever enough to export NT-Hashes out of AD and are using machine auth or "Use my
Windows Credentials" settings on the client side, you should be aware of
Microsoft's upcoming server-side deprecation of NTLM, but if I interpret what you described
correctly, you are instead authing against non-AD crypts or plaintexts stored in LDAP so AFAIK
Microsoft's client-side is going to continue to support that.