Problem with case insensitive user names in AD

[Tim Alsop]

Douglas, Srinivas,

During my testing I have observed strange, inconsistent results, but
similar to the findings of yourself and Srinivas. See below :

I have found that you need to use the default enc type for user accounts
(e.g. RC4-HMAC), e.g. you do not have the "Use DES" flag set in the
account properties. If the "Use DES" flag is set, then some issues,
which MS have decided not to fix (to encourage use of non-DES ciphers)
become aparent related to case sensitivity of principal names.

In my test environment I have a Windows Server 2003 SP1 system running a
domain with Active Directory. All latest fixes are applied, by using
Windows Update.

In Windows logon screen, I enter account name USer at xxx.com. After logon,
principal name of TGT in cache (displayed using kerbtray) = user at XXX.COM
- This is correct because the principal name in the cache is based on
the case of account, as it is defined in AD.

In Windows logon screen, I enter account name USer, and select domain
XXX.COM. After logon, principal name of TGT in cache (displayed using
kerbtray) = USer at XXX.COM
- This is NOT correct because the principal name in the cache is based
on the case of the account name entered in logon screen, which might not
be the same each time the user logs on.

So, from the above, it looks like there is a bug in MS AD on Windows
Server 2003 SP1, that occurs only when a UPN is not used during user
logon to Windows.

However, on a different server running Windows Server 2003 SP1, with all
latest fixes applied, when I logon using UPN and non-UPN logon I get a
principal name in the Microsoft cache based on the case of the user as
defined in AD, and not in any way related to the case of user name
entered during initial logon. Clearly this is not the same as on my
other server, as I described above, but it is hard to know what the
differences are since they were both built the same way. 

Also, if I found if I run the same tests described above using a Windows
2000 DC that I have in my test environment, then both UPN and non-UPN
account name logon methods work as I would expect. e.g. the principal
name in cache after the logon is based on the case of account name in
AD, not using the case of the user account name entered at initial
Windows logon.

I would be interested to hear if anybody else has experienced the same
inconsistencies ?

This is all possible because MS Windows is specifying the canonicalize
flag in the Kerberos AS-REQ. This is recognised by AD and it allows a
principal name with a case other than the one requested to be used when
issuing the TGT. Some implementations of Kerberos do not set the
canonicalize flag in AS-REQ, and therefore the above may not be observed
if a non-Microsoft Kerberos library (e.g. MIT code or Java) is used to
request the TGT. With these implementations the case of the principal in
cache will be same as case of principal in AS-REQ.

You mentioned in your reply that you "use lower case account names for
users". This is fine, but what happens if a user enters any upper case
characters for their account during Windows logon ? Do you still see the
principal in Microsoft cred cache as <lower-case-name>@<REALM> or is it
<name-entered-on-logon-screen>@<REALM> ? It would be useful if you can
confirm this to see if you are getting same results as we are.

Thanks,
Tim


-----Original Message-----
From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On
Behalf Of Douglas E. Engert
Sent: 12 January 2007 16:42
To: Srinivas Cheruku
Cc: kerberos at mit.edu
Subject: Re: Problem with case insensitive user names in AD



Srinivas Cheruku wrote:
> Hi,
> 
> We have an environment consisting of Win2k and Win2k3 servers and 
> workstations with Window XP SP2.
> The users created in AD are with lower case user principal names. eg: 
> scheruku at XXX.COM

We ran into a problem like this too. Account names in AD are case
insensitive.
Kerberos principals are case sensitive. So windows will accept any case
and will return a ticket with some case. I think W2K3 is trying to
do the best it can in this case :-).

(Java had a problem with pre-auth and the salt with DES, as it assumed
it
know the principal with case and thus the salt. The salt is case
sensitive.
Java 1.6 fixed this.)

Our solution, use lower case account names for users.

This means you can not have two principal names in AD that differ
only by case.

> 
> While logging to Win2k3 AD using winlogon from WinXP, I have used the 
> user name in mixed case eg: Scheruku in the WinLogon screen for 
> authenticating.
> I have observed the following,
> 1. In the Windows Credential cache, the TGT is with the client
principal 
> name as Scheruku at XXX.COM though the correct client name (UPN) is 
> scheruku at XXX.COM
> 2. I checked using ethereal and the AS-REQ, contains :
>  2.1 Canonicalization flag set.
>  2.2 client name: Scheruku (as given in logon screen)
> 3. AS-REP
>  3.1 client name: Scheruku (as given in logon screen)
> 
> I think the TGT should be with the client name as that of
sAMAccountName 
> which is not the case.
> 
> Then I gave user name as Scheruku at csafe.local (instead of just
Scheruku) 
> in the Winlogon screen and authenticated to Win2k3 AD.
> I observed the following now :
> 1. In the Windows Credential cache, the TGT is with the client
principal 
> name as scheruku at XXX.COM
> 2. I checked using ethereal and the AS-REQ, contains :
>  2.1 Canonicalization flag set.
>  2.2 client name: Scheruku (as given in logon screen)
> 3. AS-REP
>  3.1 client name: scheruku (same as that of sAMAccountName)

What is the UserPrincipalName ? I believe W2K3 should be
trying to have the ticket match this even with case.

> 
> 
> 
> Thinking that there might be some issue with my Win2k3 AD, I tested
the 
> same with Win2k AD. i.e. I have used the user name in mixed case eg: 
> Scheruku and authenticated using WinLogon screen.
> I observed the following now :
> 1. In the Windows Credential cache, the TGT is with the client
principal 
> name as scheruku at XXX.COM
> 2. I checked using ethereal and the AS-REQ, contains :
>  2.1 Canonicalization flag set.
>  2.2 client name: Scheruku (as given in logon screen)
> 3. AS-REP
>  3.1 client name: scheruku (same as that of sAMAccountName)
> 
> I don't understand the reason why Win2k3 AD is working differently
when 
> compared with Win2k. Can anyone help me to resolve the problem with my

> Win2k3 server?
> 
> Thanks,
> Srini
> 
> 
> ________________________________________________
> 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
________________________________________________
Kerberos mailing list           Kerberos at mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos