account name case + win2k3 sp1?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

account name case + win2k3 sp1?

Tim Alsop
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@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 ?
 
Thanks, Tim
 
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: account name case + win2k3 sp1?

Douglas E. Engert


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@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           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

RE: account name case + win2k3 sp1?

Tim Alsop
In reply to this post by 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:[hidden email]]
Sent: 06 July 2005 23:36
To: Tim Alsop
Cc: [hidden email]
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@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           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444



________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos