UPN and mschap issues
Franks Andy (IT Technical Architecture Manager)
Andy.Franks at sath.nhs.uk
Fri Nov 27 10:44:16 CET 2015
I'm a bit stuck again. FR 3.1.0.
For various reasons, we've had to start changing our AD samaccountname and upn values to be slightly different. We can't get around this.
When they were the same, the various canonicalization routines stripped off the domain and the result was the same, username == samaccountname == stripped upn.
This worked fine with ntlm and mschap based auth, even if the user was logged into the machine with their UPN (the default for PEAP-EAP-MSCHAP is that it uses the logged in credentials with Windows). Now, since the UPN format is "firstname.surname at domain<mailto:firstname.surname at domain>" and samaccountname is "surnameinitial" we have issues.
The LDAP lookup is fine with an "OR" operator on the filter so PEAP-EAP-TLS and EAP-TLS work, and I can do a (nasty) UPN -> Samaccountname lookup via an LDAP xlat when matching the UPN format so NTLM auth is fine for PAP, as long as we tell it to use the new user name (I update Stripped-User-Name and tell ntlm_auth to use that, not sure if that's a horrible thing to do).
Anything inside the EAP tunnel doesn't like you playing with the username though, so we can't do UPN based MSCHAPv2 lookup - UPN format doesn't work, as far as I can tell, with the ntlm_auth program and I can't update the username. I can force the mschap auth process to use an alternative user name, but the hash then doesn't work, and I can't work out how to update the mschap:user-name.
All this is nasty. Has anyone ever done anything better? I can't really find many people being successful with ntlm_auth and upn format, I can't do ldap - mschapv2 auth afaik, so maybe I just state that we can't do upn -> mschapv2 and stick to certs?
Maybe there's something really obviously simple that I'm missing..
Sorry for the disjointed ramble.
More information about the Freeradius-Users