account name case + win2k3 sp1?

[Tim Alsop]

Douglas,

Thank you. Changing the password for the account in domain that was not
working fixed the problem, now with both domains the case of the account
name entered during logon is not used to construct the client principal
name ... Hurray !

Thanks again,

Tim 

-----Original Message-----
From: Douglas E. Engert [mailto:deengert at anl.gov] 
Sent: 06 July 2005 23:36
To: Tim Alsop
Cc: kerberos at mit.edu
Subject: Re: account name case + win2k3 sp1?



Tim Alsop wrote:

> Hi,
>  
> We have previously observed, that when MS AD is running on Windows 
> 2000 or 2003, when an account has the DES key flag set, the client 
> principal name in cred cache on an XP workstation, after user logon is

> based on the case of the name entered at logon screen, rather than 
> using the case of the account's SAMAccountName attribute + the domain 
> name (in
> uppercase) from AD directory. We were also aware that when no DES key 
> flag was set on an account the correct behaiviour was observed, such 
> that the principal name case was based on the case used to create the 
> account in AD, and the case of the userid entered on XP logon screen 
> was ignored. For example, a user logs onto their workstation, and 
> enters USeRname into the account field, and enters the appropriate 
> password, then after logon their ticket cache shows their tgt client 
> principal name as username at REALM. This is the desired behaiviour 
> because the tgt principal name should not be based on the case of 
> account name entered when user logs on. We accept that there is an 
> issue when DES flag, and this was confirmed by MS as a bug, but MS 
> have no desire to fix this. We are 100% happy with this.
>  
> However, recently we discovered an issue when Windows 2003 SP1 Active 
> Directory is used. In this environment we are finding that the case of

> the userid entered at the workstation during logon is used to 
> determine the client principal name case (even if an account doesn' t 
> have the DES flag set on) rather than using a consistent case, based 
> on SAMAccountName (which is what we observed before when using AD on 
> Windows 2003 before SP1 was installed).
>  
> To make the situation even stranger, we tried with another Windows 
> 2003
> SP1 domain, and we are finding it is working as expected, so is there 
> an issue with the way SP1 is installed, or perhaps a registry setting 
> we need to be aware of that is different on our 2 domains ?
>  
> Does anybody observe the same ? if so, do you know whether there is a 
> specific fix in SP1 which we can remove to make this work as it did 
> prior to SP1 ?
>  

We ran into a similar problem with Java and mixed case account names.
This had to do with pre_auth and the salt. The Java code assumed it knew
the correct salt, and pre_auth type i.e. using the principal name as
typed by the user and tried to bypass the initial AS_REQ.
The KDC would then return KDC_ERR_PREAUTH_FAILED, assuming it had
previously sent the salt to the user with the KDC_ERR_PREAUTH_REQUIRED.

So is pre_auth_required set the same on both domains?

Has the case of the principals changed without changing the passwords?
i.e. the salt needs to remain the same even if the principal name
changes.

What does ethereal show in the AS_REQ, AS_REP and KRB_ERROR packets?

(Our approach was to say principals are all lower case, and we changed
the few mixed case names and had the passwords reset at the same time.)


> Thanks, Tim
>  
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444