cedric Delaunay <cedric.delaunay@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.