On 02/03/2012 05:23 PM, NdK wrote:
*or* win uses the username to calculate the response. Since users *can* actually log in to their accounts using their mail address... Maybe win caches (or looks up) the real username?
Sure. If the client uses the "right" values as input to the crypto hash, then it will work. Obviously it has to be able to "know" the right values, so this only works on domain members.
Exactly. And this name is mixed into the challenge/response. If you try to use email addresses, the client will calculate:
Just like the domain that 'ntdomain' strips. Or the others form of domain I'm already stripping.
Not quite. The MSCHAP spec says you must strip leading DOMAIN\ before performing the crypto. Microsoft clients also strip trailing @domain.com, which makes sense. So, a "compliant" client and server will not include domains. FreeRADIUS is a bit complex in this area, because of the age of the code involved. But basically: 1. "with_ntdomain_hack = yes" on the mschap module strips leading DOMAIN\ 2. Otherwise, you have to populate Stripped-User-Name yourself Really, with_ntdomain_hack should be renamed "strip_domain", should strip either leading DOMAIN\ or trailing @domain.com, and should default to "on". I need to write a patch for 3.0 which does this.
expected_response = crypto(challenge, samaccountname, stored_password) Maybe they also calculate an alternative_response considering one (or
Maybe.
more) alternate username forms. Or, simply, win looks up real username and domain when an email address is used and uses it to calculate its response.
Possibly.
the 'base name' would be user.name3, but the old UPN gets set for user.name2 and u.name now "points" to user.name3 . So the mail address is 'constant' even if the 'internal identity' changes. That person keeps logging in as u.name@unibo.it .
That sounds complicated. We login with our SamAccountName. We don't login with our email address, and we don't login with some kind of AD mapping.
Maybe that's a stupid thing, but it's how things work here and I have no control on that. I can only try to keep the best possible user experience.
Maybe. I think you're doing something complicated and weird, and I don't think you should be surprised if it doesn't work well in some cases. I don't think userPrincipalName is meant to be used that way. But if it works for you, hey, go for it.