Problem with case insensitive user names in AD

[Douglas E. Engert]

Tim Alsop wrote:
> 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.

AFS is service still using DES. Are you referring to the way the DES salt
is handled?

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

Don't see this on XP Pro client to DC running W2k3 R2 SP1.
Principal always comes back as lower case.

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

Yes looks strange.

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

kerbtray always shows lower case.



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