Multi-domain AD and Users Who Aren't So Bright

[Phil Mayers]

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