Subject: RE: Incompatibilities between Microsoft W2K3 and Kerberos 5

From: Tim Alsop <[email-masked]>
Date: Fri, 12 Mar 2004 17:05:08 -0000

Douglas,

I care about the principal name in the credential cache because I am acquiring creds from MS cache using our GSS-API library and the service ticket presented to the application server will therefore contain the principal name from the local workstation cache. I have tried other utilities to look at cred cache and they all show the same result.

It also appears that Martin's tests showed similar issues, but he didn't use kerbtray. 

We can conclude that Win2k workstation with Win2k3 AD causes issues with principal name case and name case is not presented the same as if Win2k AD is used instead. My spreadsheet shows this very clearly.

Thanks, Tim.

-----Original Message-----
From: Douglas E. Engert [mailto:[email-masked]] 
Sent: 12 March 2004 17:12
To: Tim Alsop
Cc: [email-masked]
Subject: Re: Incompatibilities between Microsoft W2K3 and Kerberos 5

Are you sure you are not seeing problems with Kerbtray? Have you loked a the actual AS_REQ, AS_REP, TGS_REQ and TGS_REP?  I have seen problems with the routines used by kerbtray. 

In PKERB_RETRIEVE_TKT_RESPONSE  they talk about "ServiceName", TargetName" and "ClientName"
and these are translated to unicode. It is also not clear if ClientName came from the ticket although it says it did. 

> Tim Alsop wrote:
> 
> Martin,
> 
> I think this problem only occurs if the Win2k workstation is used and DES keys are used. If you change the account to support the default cipher (e.g. RC4) the problem does not occur.
> 
> Please see attached matrix showing the outcome of my tests with Win2k KDC and Win2k or XP workstations.
> 
> Admitedly I haven't yet completed the same tests with Win2k3 KDC, so it is possible that something else is broken as you suggest. Do the results in my attached spreadsheet match your findings ?
> 
> Thanks, Tim.
> 
> -----Original Message-----
> From: Martin Rex [mailto:[email-masked]]
> Sent: 11 March 2004 18:37
> To: [email-masked]
> Subject: Incompatibilities between Microsoft W2K3 and Kerberos 5
> 
> Did anyone else notice changes that went into Microsoft W2K3 Kerberos that are breaking Kerberos interoperability?
> 
> After Tim Alsop's message on the ietf-krb-wg mailing list and several custumer problem messages in the past couple of days with Windows 2003 machines I checked what is actually going on.
> 
> The results appear devastating:
> 
> A Windows 2003 KDC will perform a case-insensitive match of the requested kerberos principal name against the account database and issue tickets in exactly the case-format that was in the request.
> 
> The Winlogon of Windows 2003 will not canonicalize the username that was entered in the logon screen either.
> 
> This is an extremely severe interoperability problem, since Kerberos principal names are CASE-SENSITIVE and have always been.  This is required by both, the Kerberos specs and rfc1964.
> 
> So if "joeuser" logs on as "JoeUser" today he will authenticate to 
> servers with the kerberos principal name "JoeUser", and if he logs on with "Joeuser" tomorrow, he will authenticate to servers with the Kerberos principal name "Joeuser".  That is going to break all Kerberos-based applications.
> 
> Right now, I can only issue a strong warning to our customers to
> **NOT** use or upgrade to W2K3 if they want to use Kerberos-based Single Sign-On with our application, but to remain on Windows 2000 (I haven't checked XP, but this particular problem appears to be a bug of the W2K3 KDCs).
> 
> Did I miss the discussion on how case-independent account-naming could be done in Kerberos?  Certainly it must NOT be done using arbitrary-cased kerberos principal names in tickets, breaking all the installed base of kerberized or gssapi based apps.
> 
> -Martin
> 
> 
> 
>                               Name: AD and SAP Tests v2.xls
>    AD and SAP Tests v2.xls    Type: Microsoft Excel Worksheet (application/vnd.ms-excel)
>                           Encoding: base64

-- 

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

---

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 12 Mar 2004 11:33:06 -0600

> Tim Alsop wrote:
> 
> Douglas,
> 
> I care about the principal name in the credential cache because I am acquiring creds from MS cache using our GSS-API library and the service ticket presented to the application server will therefore contain the principal name from the local workstation
> cache. I have tried other utilities to look at cred cache and they all show the same result.
> 

What I was trying to get at, is this a problm with the LSA on Win2k workstaiton storing the
ClientName from the GINA, and not from the ticket as claimed? It appears from your spreadsheet that the
XP clients store  the correct client name. 

--

---

From: Martin Rex <[email-masked]>
Date: Fri, 12 Mar 2004 19:21:54 +0100 (MET)

Just to make sure this is not missed:

The problem seem to arise if one uses a W2K3 Active Directory,
and it affects *ALL* memeber machines, W2K *and* W2K3.

I get tickets with the kerberos principal verbatim from
the login screen issued on both W2K-member servers and W2K3-member servers.
(I haven't checked, but I would expect WinXP to behave likewise.)

I tested with the domain still at W2K mixed mode.  My guess is that it
also happens at W2K3 native mode (I just don't have such an environment
for testing).

The (native) kerberos prinicpal name that is extracted from the service
ticket upon authentication (=AcceptSecurityContext() completes) is
the one that is causing the trouble.  QueryContextAttributes(NATIVE_NAMES)
does retrieve exactly that name.  And this will be the name that
all kerberized or gssapi-based Apps will get to see, whether they
run on any Kerberos-capable Windows or Unix.

-Martin

Douglas E. Engert wrote:
> > We can conclude that Win2k workstation with Win2k3 AD causes issues
> > with principal name case and name case is not presented the same as
> > if Win2k AD is used instead. My spreadsheet shows this very clearly.
> 
> What I was trying to get at, is this a problm with the LSA on Win2k
> workstaiton storing the ClientName from the GINA, and not from the
> ticket as claimed? It appears from your spreadsheet that the

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 12 Mar 2004 12:51:59 -0600

> and it affects *ALL* memeber machines, W2K *and* W2K3.

Right, which means that fixing the client to take extra steps to
properly canonicalize the principal _after_ getting the initial TGT (and
then getting a second TGT with the canonical principal name) is probably
out of the question.

I've argued before (at least as far back as late 2001) that the KDC can
do this sort of aliasing thing for service principals.  I can see that
Martin would have a problem with that where GSS-API initiator
applications use ACLs to authorize the acceptor -- though this is hardly
a common usage.  But certainly it seems like asking for trouble when
applying this kind of aliasing to client principal names.

And note that what W2K3 AD is doing is within the letter of Kerberos V,
even though principal names are case sensitive, because this doesn't
change the case sensitivity of principals -- it's more like
automatically creating duplicate principals in the KDB.

I speculate that MS wanted to help users who can't be bothered
capitalizing their principal names properly.  But this has caused more
trouble than it's solved.

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 12 Mar 2004 20:37:36 +0100 (MET)

> automatically creating duplicate principals in the KDB.

I strongly disagree.

There are two independent flaws, and both should be fixed!
The W2K Active Directory seemed to have hidden the flaw of the
clients that request TGTs so far.  But the change in W2K3 Active Directory
made it visible.

I think that it is a really bad idea if a KDC does case-insensitive
account name matching against its KDB, and that it is a violation
of the Kerberos architecture (although maybe not the words of
a particular spec).

In Kerberos "joeuser", "JoeUser" and "JOEUSER" are all distinct principals.
Now if you use some kadmin protocol to create "joeuser" or to change
properties of "joeuser", that will in Microsoft's case create/change
the users JoeUser and JOEUSER as well.

Now what should be fixed?
I think that both, the mapping of NT account names into Kerberos
principal names should be fixed for all Microsoft clients that
perform login and permit/accept case-insensitive NT account names
(Winlogon/GINA and LogonUser APIs).  And the Microsoft W2K3 AD should
be fixed so that it behaves like the W2K AD regarding client name
canonicalization.

Fixing the Microsoft AD to not allow case-insensitive account name
matching (although theoretically correct) would break the installed
base of W2K/XP/W2K3, so that is impossible.

Getting the AD-fix into W2K3sp1 would be the best possible solution,
because this likely get it installed on most W2K3 domain controllers.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 12 Mar 2004 13:41:05 -0600

> > automatically creating duplicate principals in the KDB.

Well, I agree that they're violating the spirit of the spec :)

Nico
--