Subject: RE: Microsoft Kerberos account name case sensitivity issue ?

From: Tim Alsop <[email-masked]>
Date: Thu, 19 Feb 2004 22:52:38 -0000

David,
 
Let me explain what I am trying to do in a different way just to make sure the requirement is 100% clear :
 
A typical customer wants to implement SSO so that when they log onto a win2k/xp workstation they can access an application that is secured via gss-api. The application server typically runs on a unix server, but this does not matter for the purposes of this discussion.
 
Here are the steps :
 
1. A user is created in AD with account logon name of [email-masked] <mailto:[email-masked]> 
2. The user at a workstation logs onto the COMPANY.COM realm (company.com domain) using their account name of FredBloggs and appropriate password.
3. The logon completes and in their credential cache contains the the tgt and service tickets for the user principal name of [email-masked] <mailto:[email-masked]> 
4. They start the client application which sets up a GSS security context with the server application. The server is then able to decrypt the service ticket and determine the principal name of the authenticated user at the workstation.
5. The server application uses the authenticated name of the user at the workstation to determine the authorisation rules for the application.
6. If the principal name is always [email-masked] <mailto:[email-masked]>  in this case then the application can correctly determine authorisation for Fred Bloggs since this user is uniquely recognised by their name as it was created by the AD administrator ([email-masked] <mailto:[email-masked]> ).
 
Now, the above breaks when Win2k is used and the user logs on with Fredbloggs in the GINA. When this happens the principal name will be [email-masked] <mailto:[email-masked]>  so the application will not recognise this person as Fred Bloggs, however this is the same person that could also log on with FredBloggs in logon screen, or FREDBLOGGS - each name has same password and belongs to the same person.
 
If an XP workstation is used something different occurs to make the principal name in the cred cache for the logged on user appear as it is defined in AD. This is what we need to happen with Win2k.
 
I hope there is a patch/registry update or some other solution to Win2k. It is well known that user account names on Windows logon are not case sensitive, but passwords are case sensitive. The most consistent name for the principal should be the case of the name as defined in AD, not based on what the user enters during the logon screen.
 
I haven't traced the AS-REQ/AS-REP yet to see what message is being sent to AD during a logon, but this might expose where the problem is in Win2k when we compare with an XP logon. Do you agree ?
 
Thanks, Tim.

  _____  

From: Actually davidchr [mailto:[email-masked]] 
Sent: 19 February 2004 22:22
To: Tim Alsop
Cc: [email-masked]; [email-masked]
Subject: RE: Microsoft Kerberos account name case sensitivity issue ?

comments inline:
 
---
This message is provided "AS IS" with no warranties, and confers no rights.
This message may originate from an unmonitored alias ("davespam") for spam-reduction purposes.  Use "davidchr" for individual replies.
Any opinions or policies stated within are my own and do not necessarily constitute those of my employer.
This message originates in the State of Washington (USA), where unsolicited commercial email is legally actionable (see  <http://www.wa-state-resident.coml/> http://www.wa-state-resident.com).
Harvesting of this address for purposes of bulk email (including "spam") is prohibited unless by my expressed prior request.  I retaliate viciously against spammers and spam sites.

  _____  

Comment : 

So, how do I make Win2k work the same as XP ? If you log onto a domain account from a Win2k workstation and then log onto the same domain account from an XP workstation, but enter the case of the account name incorrectly in the logon screen. After logon the kerbtray application displays the principal name differently and not consistent with the case of the account in AD, unless XP is used. I therefore conclude that Win2k is broken and XP is working as expected in a consistent manner regardless of what case is used during logon.

[DavidChr]  Although I wouldn't use the term "broken" myself, I'd say that your assessment is essentially correct.  IIRC, the design was changed slightly after Win2k to provide something more case-preserving in nature.  It's been several years, and my memory has played tricks on me in the past, so take this explanation with a grain of salt.  I may have more information soon, as we finish scrutinizing this aspect of the behaviors of the various releases. 

So, why does Microsoft kerbtray and hence SSPI present the principal name differently and inconsistently ? Surely the unique case used when the account is created in AD should be used for the principal name ?

[DavidChr] It depends on what you mean by "used".  The current intent is to give you the case you asked for-- if you AS-REQ for [email-masked] <mailto:[email-masked]> , that's the cPrinc that should come back in the AS-REP (case-exact), and should ultimately show up in your ticket cache.  

As stated, Win2K behaved differently, and I don't know if there's a way to make it behave the way you're expecting, but I'll sniff around.  Does this present a significant hardship for you?

How does this relate to your suggestion to use QueryContextAttributes ? Surely the problem occurs before we start a context, when the AS-REQ and AS-REP is processed, or when tgt is stored in cache during a win2k domain account logon process ?

[DavidChr]  That's what we were originally thinking, but this assumption collapses in subsequent releases, because sometimes you may authenticate as someone else depending on what server you're authenticating to.  For example, WinXP provides a very useful feature called the Credential Manager, which allows you to say:

If I connect to *.daves_home_network.org, I want to authenticate as [email-masked] <mailto:[email-masked]> , using this password.

If I connect to *.microsoft.com, I want to authenticate as [email-masked] <mailto:[email-masked]>  using my smartcard.

...and because of this feature (and others), we might obtain additional AS/TGSs to support context establishment, which might have a different client principalname than the one you used to logon with.  For this reason and from an SSPI/GSSAPI perspective, you should never ask "who am I?" but instead ask "who do you think I am?" :-)

-Dave

---

From: "Paul W. Nelson" <[email-masked]>
Date: Thu, 19 Feb 2004 18:30:57 -0600

On my setup -
    MIT 1.3.1 on my *nix client
Windows 2003 Active Directory on my domain controller

In every case, my ticket cache gets my user principal name with the case I
type in.

*** Warning: The rest of this message has more to do with Active Directory
than Kerberos***
I guess the real question is how the server uses the userPrincipalName for
authorization.  I would think that if the server were running on UNIX, it
would have to look up the the user info using LDAP, then make security
decisions on the names or SID returned.

The lookup filter would need to look like this:
    (|(userPrincipalName=xxx)(sAMAccountName=yyy))
where xxx is the principal name from the ticket, and yyy is the part of the
principal name up to the at sign.  This lookup will be case insensitive, but
the result will have the ³correct² case for the userPrincipalName.

Notice that I have to look for sAMAccountName also.  User records in AD DONT
have to have the userPrincipalName field populated.  They MUST have a
sAMAccountName however.  The KDC in AD will allow you to TGT with a case
insensitive sAMAccountName (I know  I¹ve been burned by this).

I don¹t think you can count on the case of the user principal name
regardless of what client you use.  You probably just got lucky with XP
because it looks up the username first, then gets TGT with the
userPrincipalName.  Windows users can log on with either the sAMAccountName
or userPrincipalName from their LDAP record.

My conclusion is that this really isn¹t about case sensitivity in a UPN, but
in what you have to do with a UPN to determine authorization.

Here is my kinit/klist output

[Paul-Nelsons-Computer:Libraries/LdapKerb/build] root# kdestroy
[Paul-Nelsons-Computer:Libraries/LdapKerb/build] root# kinit
[email-masked]
Password for [email-masked]:
Warning: Your password will expire in 5 days.
[Paul-Nelsons-Computer:Libraries/LdapKerb/build] root# klist
Ticket cache: API:Initial default ccache
Default principal: [email-masked]

Valid starting     Expires            Service principal
02/19/04 18:14:06  02/20/04 04:14:03  krbtgt/[email-masked]
        renew until 02/20/04 18:14:06

Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached
[Paul-Nelsons-Computer:Libraries/LdapKerb/build] root# kinit
[email-masked]
Password for [email-masked]:
Warning: Your password will expire in 5 days.
[Paul-Nelsons-Computer:Libraries/LdapKerb/build] root# klist
Ticket cache: API:Initial default ccache
Default principal: [email-masked]

Valid starting     Expires            Service principal
02/19/04 18:14:18  02/20/04 04:14:16  krbtgt/[email-masked]
        renew until 02/20/04 18:14:18

Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached
[Paul-Nelsons-Computer:Libraries/LdapKerb/build] root# kinit
[email-masked]
Password for [email-masked]:
Warning: Your password will expire in 5 days.
[Paul-Nelsons-Computer:Libraries/LdapKerb/build] root# klist
Ticket cache: API:Initial default ccache
Default principal: [email-masked]

Valid starting     Expires            Service principal
02/19/04 18:14:35  02/20/04 04:14:34  krbtgt/[email-masked]
        renew until 02/20/04 18:14:35

Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached
[Paul-Nelsons-Computer:Libraries/LdapKerb/build] root#
-- 
Paul W. Nelson
Thursby Software Systems, Inc.
> 
> From: Tim Alsop <[email-masked]>
> Date: Thu, 19 Feb 2004 22:52:38 -0000
> To: Actually davidchr <[email-masked]>, Tim Alsop
> <[email-masked]>
> Cc: [email-masked], [email-masked]

> A typical customer wants to implement SSO so that when they log onto a
> win2k/xp workstation they can access an application that is secured via
> gss-api. The application server typically runs on a unix server, but this does
> not matter for the purposes of this discussion.
>  
> Here are the steps :
>  
> 1. A user is created in AD with account logon name of [email-masked]
> 2. The user at a workstation logs onto the COMPANY.COM realm (company.com
> domain) using their account name of FredBloggs and appropriate password.
> 3. The logon completes and in their credential cache contains the the tgt and
> service tickets for the user principal name of [email-masked]
> 4. They start the client application which sets up a GSS security context with
> the server application. The server is then able to decrypt the service ticket
> and determine the principal name of the authenticated user at the workstation.
> 5. The server application uses the authenticated name of the user at the
> workstation to determine the authorisation rules for the application.
> 6. If the principal name is always [email-masked] in this case then
> the application can correctly determine authorisation for Fred Bloggs since
> this user is uniquely recognised by their name as it was created by the AD
> administrator ([email-masked]).
>  
> Now, the above breaks when Win2k is used and the user logs on with Fredbloggs
> in the GINA. When this happens the principal name will be
> [email-masked] so the application will not recognise this person as
> Fred Bloggs, however this is the same person that could also log on with
> FredBloggs in logon screen, or FREDBLOGGS - each name has same password and
> belongs to the same person.
>  
> If an XP workstation is used something different occurs to make the principal
> name in the cred cache for the logged on user appear as it is defined in AD.
> This is what we need to happen with Win2k.
>  
> I hope there is a patch/registry update or some other solution to Win2k. It is
> well known that user account names on Windows logon are not case sensitive,
> but passwords are case sensitive. The most consistent name for the principal
> should be the case of the name as defined in AD, not based on what the user
> enters during the logon screen.
>  
> I haven't traced the AS-REQ/AS-REP yet to see what message is being sent to AD
> during a logon, but this might expose where the problem is in Win2k when we
> compare with an XP logon. Do you agree ?
>  
> Thanks, Tim.
> 
> 
> This message may originate from an unmonitored alias ("davespam") for
> spam-reduction purposes.  Use "davidchr" for individual replies.
> This message originates in the State of Washington (USA), where unsolicited
> commercial email is legally actionable (see http://www.wa-state-resident.com
> <http://www.wa-state-resident.coml/> ).
> Harvesting of this address for purposes of bulk email (including "spam") is
> prohibited unless by my expressed prior request.  I retaliate viciously
> against spammers and spam sites.
>  
> 
>> 
>> Comment : 
>> So, how do I make Win2k work the same as XP ? If you log onto a domain
>> account from a Win2k workstation and then log onto the same domain account
>> from an XP workstation, but enter the case of the account name incorrectly in
>> the logon screen. After logon the kerbtray application displays the principal
>> name differently and not consistent with the case of the account in AD,
>> unless XP is used. I therefore conclude that Win2k is broken and XP is
>> working as expected in a consistent manner regardless of what case is used
>> during logon.
> 
> [DavidChr]  Although I wouldn't use the term "broken" myself, I'd say that
> your assessment is essentially correct.  IIRC, the design was changed slightly
> after Win2k to provide something more case-preserving in nature.  It's been
> several years, and my memory has played tricks on me in the past, so take this
> explanation with a grain of salt.  I may have more information soon, as we
> finish scrutinizing this aspect of the behaviors of the various releases.
>> 
>> So, why does Microsoft kerbtray and hence SSPI present the principal name
>> differently and inconsistently ? Surely the unique case used when the account
>> is created in AD should be used for the principal name ?
> 
> [DavidChr] It depends on what you mean by "used".  The current intent is to
> give you the case you asked for-- if you AS-REQ for [email-masked],
> that's the cPrinc that should come back in the AS-REP (case-exact), and should
> ultimately show up in your ticket cache.
> 
> As stated, Win2K behaved differently, and I don't know if there's a way to
> make it behave the way you're expecting, but I'll sniff around.  Does this
> present a significant hardship for you?
>> 
>> How does this relate to your suggestion to use QueryContextAttributes ?
>> Surely the problem occurs before we start a context, when the AS-REQ and
>> AS-REP is processed, or when tgt is stored in cache during a win2k domain
>> account logon process ?
> 
> [DavidChr]  That's what we were originally thinking, but this assumption
> collapses in subsequent releases, because sometimes you may authenticate as
> someone else depending on what server you're authenticating to.  For example,
> WinXP provides a very useful feature called the Credential Manager, which
> allows you to say:
> 
> If I connect to *.daves_home_network.org, I want to authenticate as
> [email-masked], using this password.
> 
> If I connect to *.microsoft.com, I want to authenticate as
> [email-masked] using my smartcard.
> 
> ...and because of this feature (and others), we might obtain additional
> AS/TGSs to support context establishment, which might have a different client
> principalname than the one you used to logon with.  For this reason and from
> an SSPI/GSSAPI perspective, you should never ask "who am I?" but instead ask
> "who do you think I am?" :-)
> 
> -Dave 
>

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 19 Feb 2004 19:54:10 -0600

Although this discussion is interesting, Can we please ask this topic 
be moved off this list. This list is for issues related to the IETF 
KRB-WG. This discussion is becomming a how to use Windows. 

Thanks. 

-- 

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