On 27/11/15 09:44, Franks Andy (IT Technical Architecture Manager) wrote:

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

Altering the in-packet username or the username on the ntlm_auth command line is futile; as you've indicated, the client does the crypto on the basis of the UPN, and that's what you need to pass to ntlm_auth so that it can be in turn passed to the DC and mixed into the chal/resp verification/calculation correctly. I was under the impression that ntlm_auth should work with a UPN where LHS != samaccountname, but it's really a Samba question - I'd suggest asking on the Samba list. I don't have any easy way to test locally I'm afraid.

On Nov 27, 2015, at 4:44 AM, Franks Andy (IT Technical Architecture Manager) <Andy.Franks@sath.nhs.uk> wrote:

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.

i.e. Someone has made a policy decision which ignores how the protocols work. That can't end well.

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@domai" and samaccountname is "surnameinitial" we have issues.

Yup.

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,

You don't need to do ntlm_auth for pap. You can do LDAP "bind as user" directly.

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).

It works because "ntlm_auth for pap" is just "name / password" lookups.

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.

Because the MS-CHAP data *also* contains the UPN name. And the MS-CHAP calculates are based on that UPN name. So you can't say "check name smithb with bob.smith credentials". The MS-CHAP calculations just won't work.

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.

You can't. It's impossible.

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..

Add the UPN name as an account name in Active Directory. Maybe AD allows aliases for account names. It is just *impossible* to do what you want. Authentication protocols are designed to prevent "bob" from logging in using the credentials for "doug". This situation is no different. Alan DeKok.