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

From: Tim Alsop <[email-masked]>
Date: Tue, 17 Feb 2004 22:00:27 -0000

Sam,

Can you explain your final comment, "I'll agree it does end up being more usable" ? What aspect of my findings, or MS Kerberos are you suggesting is more usable ?

Do you know if there is a patch available for Win2k to make it work the same way as XP and provide consistent principal names in the MS cache regardless of what is entered in GINA logon ?

Cheers, Tim.

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: 17 February 2004 22:01
To: Tim Alsop
Cc: [email-masked]
Subject: Re: Microsoft Kerberos account name case sensitivity issue ?

Kerberos principal names are case sensitive.  There are certain games a KDC can play with this.  I believe Microsoft violates the spec in their handling of this issue, but I'll agree it does end up being more usable.

---

From: Luke Howard <[email-masked]>
Date: Thu, 19 Feb 2004 08:01:27 +1100

Note that the RHS of a user principal name (UPN) need not match the
Kerberos realm of a user's account. See the referrals draft for
enterprise principal names -- these are the same thing as a UPN.

-- Luke

---

From: Tim Alsop <[email-masked]>
Date: Wed, 18 Feb 2004 21:10:22 -0000

Martin,

Thankyou for this info. It looks like it is even more broken than I first thought :-( We will have to work around these issues - knowing what they are is obviously very important, so I thank you again for adding extra info !

Regards,
Tim. 

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: 18 February 2004 17:34
To: [email-masked]
Cc: [email-masked]
Subject: Re: Microsoft Kerberos account name case sensitivity issue ?

Tim Alsop wrote:
> 
>  
> Has anybody else noticed a strange 'case sensitivity' issue with MS 
> Kerberos on Win2k workstations ?

I had observed this annoying behaviour with NTLM 6 years ago.
(authentication at the GSS-API is strictly name-based, so this is  a problem for portable gss-api based applications).

The issue with W2K is not only weird, it's actually quite broken, and little if any got fixed for XP/2003.

GetUserNameEx(NameUserPrincipal) returns your Kerberos principal
                                 name, only that the realm shows up with
                                 lowercase instead of the correct uppercase

GetUserNameEx(NameSamCompatible) returns your NT4-account name as it
                                 is visualized in ACLs

TranslateName(GetUserNameEx(NameUserPrincipal),
              NameUserPrincipal,NameSamCompatible)
			         will also return the NT4-account name

TranslateName(GetUserNameEx(NameSamCompatible),
              NameSamCompatible,NameUserPrincipal)
                                 returns an error "None Mapped"

and finally:

QueryCredentialsHandle(NAMES) returns your Kerberos principal name with
                              the realm correctly in uppercase
                              EXCEPT when the credential was created with
                              an explicitly supplied user/realm pair,
                              in which case you get whatever you supplied
                              and not what is in the TGT from the KDC.

This situation is pretty annoying for a Kerberos environment, but it is a real shame for something that calls itself "Directory"...

-Martin

---

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

David wrote :

SOLUTION:

If I understand your problem, QueryContextAttributes( NativeNames ) should give you the cPrinc associated with your client's SSPI context, and is much more likely to be what you want from a gssapi perspective.  

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.

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 ?

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 ?

Thanks, Tim.

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Feb 2004 15:11:19 +0100 (MET)

David,

davidchr wrote:
> 
> Microsoft Kerberos is intended to be case-preserving.  That's as close
> as we could get to the RFC without making enormous, counterproductive
> changes to Windows itself and the way people use it.  
> 
> Personally, I think it would be worthwhile to bring case-preservation
> into the standard itself (why would you ever have two realms differing
> only by case?), but that's just my humble opinion. 

Microsoft Kerberos doesn't look anywhere near case-preserving in the
scenarios that Tim and I mentioned.  It is actually case-ignorant.

case-preserving would mean that a single character of a name or realm
in the wrong case would lead to the error unknown user or unknown realm.

However, what Microsoft's implementation actually does is that it
performs a case-insensitive account name match on the KDC.

The ticket is issued with the **correct** Kerberos principal name,
Unfortunately that "case corrected" principal name is not available
anywhere at SSPI level.

> 
> As for the APIs you listed:
> 
> I think you've misunderstood what this name-format is intended for.  The
> output of NameUserPrincipal is a UserPrincipalName (described, among
> other places, at
> <http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prod
> technol/windows2000serv/reskit/distsys/part1/dsgch01.asp>).  Although
> the 'UPN' includes the string 'Principal', it should not be assumed to
> be the literal cPrinc associated with your TGT.  

I don't care what kind of awkward stuff Microsoft does with it's
directory.

I'm referring to
http://support.microsoft.com/default.aspx?scid=kb;en-us;266080
and Microsoft's claim to have followed rfc1964.

rfc1964 does cover name formats, and it includes the gssapi-specs
and architecture regarding name based authentication.

Obviously the SSPI calls that I mentioned are clearly broken under
this light.

> 
> We have a variety of name-types for different purposes, and not all (or
> even most) of them are related to gssapi or Kerberos.
> 
> I'm not sure why you brought up TranslateName, so I'm skipping those.

I brought up TranslateName() because it is part of the *SSPI*.

It is supposed to deal with name space translations between the
naming spaces of Microsoft's SSPs like NTLM SSP and Kerberos SSP.
Unfortunately the current implementation is entirely insufficient,
which is one possible kind of brokenness.

However the most confusing issue is that during W2K beta TranslateName()
actually DID a NameSamCompatible->NameUserPrincipal conversion!
(see your Email from 1999 below).

> [...]
> Don't use the QueryCredentialsAttributes API for this purpose because
> your credential handle doesn't necessarily reflect who you are going to
> authenticate as.  I can go into why this is (fascinating to me, probably
> very boring to you guys) if anyone cares.

Well, there seems to be an obvious misunderstanding.
QueryCredentialsAttributes(NAMES) should always be perfectly able to
tell who I am going to authenticate as (name based).

Maybe you're confusing the "who are you going to authenticate as"
with "for which identity will the remote Windows machine create
an access token", which is something entirely different conceptually.

I know that QueryCredentialsHandle() has grown a few bugs in the last
years, one of the most annoying that I came across was it's failure to
match an explicitly supplied Kerberos principal name against the
Kerberos name of the default credentials if the default credential
was created with a smartcard-based preauth.

This is from an Email reply that you sent me a few years back, and I
think it draws a different picture...
===== begin quote ======
: From: "David Lawler Christiansen (NT)" <[email-masked]>
: To: <[email-masked]>, <[email-masked]>
: Date: Fri, 25 Jun 1999 12:03:45 -0700
: Subject: RE: GSSPI to SSPI(Kerberos) wrapper
: ...
: Martin Rex wrote:
: : 1) I acquire *default* credentials for SSP "Kerberos",
: :    AcquireCredentialsHandle(pszPrincipal=NULL, pAuthData=NULL, OUTBOUND)
: :    QueryCredentialsAttributes(NAMES)
: :      ==>   "[email-masked]"
: :
: :    hmmm.
:
: QueryCredentialsAttributes is returning the kerberos principal name (e.g.
: username + realm name).  By convention (see RFC1510), Kerberos realms are
: generally in all-uppercase.  An NT Domain is also a kerberos realm, so we
: automatically uppercase it.
:
: : 2) I use GetUserNameEx(NameUserPrincipal)
: :      ==>   "[email-masked]"
: :
: :    huh?
:
: GetUserNameEx is returning the UPN for the principal, which is (if memory
: serves) case-insensitive, so it's probably returned all-downcase for
: consistency.
:
: : 3) I use these credentials to establish a security context and the
: :    acceptor calls QueryContextAttributes(NAMES)
: :      ==>   "SWDF\d019080"
: :
: :    WHAT?
:
: This is the NT username for the the context established (it's not
: necessarily the credential name, because you can map multiple principalnames
: and usernames to a single account).
:
:...
: : 5) TranslateName("SWDF\d019080",NameSamCompatible,NameUserPrincipal) works
: :    TranslateName("SWDF d019080",NameSamCompatible,NameUserPrincipal)
: :       goes to sleep for several seconds before it fails.
: :
: :    WHY? It should only do string operations!
:
:
: It's expecting the first portion of the name to be the domain (e.g.
: domainname\username, because you supplied NameSamCompatible).  So, it's
: searching for a domain named "SWDF d019080", which probably doesn't exist,
: but it takes awhile to make sure-- finding a domain that doesn't exist takes
: time.  :-)
===== end quote =====

> SOLUTION:
> 
> If I understand your problem, QueryContextAttributes( NativeNames )
> should give you the cPrinc associated with your client's SSPI context,
> and is much more likely to be what you want from a gssapi perspective.  

Now that is funny!

QueryContextAttributes(NativeNames) was added to SSPI after I had
complaint several times very loudly that such functionality was badly
needed for full Kerberos interoperability.  However QueryContextAttributes
is only available after having fully established a security context.
Therefore it is entirely inadequate for situations where one wants 
to know the principal associated with a credential or in order to
pre-populate name-based Kerberos ACLs.

Same discussion, this is the answer from Mike Swift to my reply on
the quoted Email above:
===== begin quote =====
: From: "Mike Swift (NT)" <[email-masked]>
: To: <[email-masked]>, <[email-masked]>
: Date: Mon, 28 Jun 1999 09:53:19 -0700
: Subject: RE: GSSPI to SSPI(Kerberos) wrapper
:
: QueryCredentialsAttributes does return the case sensitive name.
: GetUserNameEx does not. QueryContextAttributes returns an NT name, not a
: kerberos name.
:
: There is not an API yet to get the kerberos-style principal name from an
: accepted context. We have a bug filed on this and will fix it for the final
: release.
:
: There is not a cheap way to convert between SAM and Kerberos style names -
: there need be no syntatic relation between the two, so it can't be done by
: mere string manipulation. However, SAM names are valid in MS kerberos, so
: you can use them directly.
:
: ...
:
: -----Original Message-----
: From: Martin Rex [mailto:[email-masked]]
: Sent: Monday, June 28, 1999 6:38 AM
: To: [email-masked]
: Cc: [email-masked]; [email-masked]
: Subject: Re: GSSPI to SSPI(Kerberos) wrapper
:
: David Lawler Christiansen wrote:
: : QueryCredentialsAttributes is returning the kerberos principal name (e.g.
: : username + realm name).  By convention (see RFC1510), Kerberos realms are
: : generally in all-uppercase.  An NT Domain is also a kerberos realm, so we
: : automatically uppercase it.
:
: Huh?
: Kerberos realm names ARE CASE SENSITIVE.  On of the reasons is that
: the realm name is used as salt for the encryption.  You should never
: fiddle with the upper/lower case of a realm name.  Actually, a Kerberos
: principal name is case sensitive as well, so you shouldn't fiddle
: with that, either.  (see also Kerberos revisions document, section 7.1.)
: 
: You should not apply NT account naming rules to rfc1964 Kerberos principal
: names, or you will break interoperability with native Kerberos on other
: platforms!  Currently, the naming accross various SSPI calls looks
: completely inconsistent to me.  What API calls can I use to get
: a VALID rfc1964 Kerberos principal name for (a) the current user,
: and (b) the initiator of a security context?
: ...
===== end quote =====

-Martin