Subject: Incompatibilities between Microsoft W2K3 and Kerberos 5

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

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

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 11 Mar 2004 11:12:32 -0800

Martin, regretfully we were not able to verify Tim findings, although
interesting as it sounds. The name canonicalization behavior is not
changed on ws2k3.

Here is the referral draft we recently published:

http://www.watersprings.org/pub/id/draft-ietf-krb-wg-kerberos-referrals-
03.txt

Thanks, Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Thursday, March 11, 2004 10:37 AM
To: [email-masked]
Subject: Incompatibilities between Microsoft W2K3 and Kerberos 5

-Martin

---

From: Luke Howard <[email-masked]>
Date: Fri, 12 Mar 2004 09:20:20 +1100

>interesting as it sounds. The name canonicalization behavior is not

It did, but on the TGS-REQ (not AS-REQ). See below:

% kinit [email-masked]
[email-masked]'s Password: 
% kgetcred --canonicalize host/[email-masked]
% klist
Credentials cache: FILE:/tmp/krb5cc_1002
        Principal: [email-masked]

  Issued           Expires          Principal                       
Mar 12 09:17:45  Mar 12 19:17:45  krbtgt/[email-masked]    
Mar 12 09:17:59  Mar 12 19:17:45  host/[email-masked]

As I recall with Windows 2000 a TGS-REQ with the canonicalize bit
set would have returned DIZZY$ (in this example).

-- Luke

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 11 Mar 2004 15:12:14 -0800

This is slightly different. 

IIRC, what Tim mentioned earlier is the client name canonicalization
behavior, that behavior is not changed on ws2k3.

On ws2k3 we do not canonicalize the server name (and as you pointed out
here win2000 indeed does that).

Thanks,

Larry

-----Original Message-----
From: Luke Howard [mailto:[email-masked]] 
Sent: Thursday, March 11, 2004 2:20 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; [email-masked]
Subject: RE: Incompatibilities between Microsoft W2K3 and Kerberos 5

  Issued           Expires          Principal                       

-- Luke

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 11 Mar 2004 16:50:11 -0800

What Sam described below is correct, and Martin, let's not jump on it
until we have more information, and we have not seen the changes Tim
described w.r.t. ws2k3. We believe our client name canonicalization
behavior is not changed on ws2k3 from that of win2k.

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Thursday, March 11, 2004 4:31 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: Incompatibilities between Microsoft W2K3 and Kerberos 5

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    >>  I.E.  the client may perform cannonicalization, possibly by
    >> consulting some external directory.  But in the IETF Kerberos
    >> world, the KDC must either return what the client requested or
    >> return an error.

    Martin> Great--that's what I've been asking for all along!
I may be getting this a bit wrong so I'd appreciate it if Microsoft
people would join in.

They don't want to make the mapping from what the user types in to the
canonical name public.  IN particular, they want to require that the
user authenticate before they get access to this mapping.

They also don't want the host to be authorized to do this mapping
without user credentials.

Their model doesn't allow them to ACL things this way in the
directory.

    Martin> i.e. a user account create as JoeUser will receive tickets
    Martin> for [email-masked] [email-masked]
    Martin> all in all 128 distinct Kerberos principals.  And that is
    Martin> the result of how a user enters his case-insensitive
    Martin> NT-account name on the logon screen.
    Martin> For gss-api based or traditional kerberized apps these are
    Martin> 128 distinct users.  I see this as a severe usability
    Martin> problem.
    >>  What would you have them do instead?

    Martin> Canonicalize the NT account name which the user typed in
    Martin> locally and use that to request tickets from the KDC.
    Martin> That seems to work well on W2K, so I really don't
    Martin> understand why they broke it in W2K3.

If it can be made to work I agree it would be an improvement.

---

From: Martin Rex <[email-masked]>
Date: Fri, 12 Mar 2004 02:17:53 +0100 (MET)

Actually davidchr wrote:
> > Canonicalize the NT account name which the user typed in 
> > locally and use
> > that to request tickets from the KDC.  That seems to work well on W2K,
> > so I really don't understand why they broke it in W2K3.
> 
> How could a workstation securely and performantly canonicalize a
> principalname BEFORE making an AS-REQ if that workstation does not
> ALREADY have access to KDC data?  

There are plenty of straightforward solutions.
(a) once you have the non-canonical TGT, you can replace it with
    the canonical version, all before applications are started
    that might have problems with the non-canonical TGTs
(b) if not changed from the default, NT workstations cache account
    information.  Using such cached data it should be possible
    to obtain "canonical" TGTs most of the time.
    Even when disabling the caching of account data, the caching
    of canonical user principal shouldn't be a security problem
    (since they can only differ in case anyway).

> 
> We request name canonicalization under most circumstances WITH the
> AS-REQ, which is, to my knowledge, what you're after despite it being a
> violation of the spec.  If you have more questions about this, please
> contact Larry or myself (davidchr-a.t-microsoft-d.o.t-com).
> 
> I'm pretty sure I discussed this with you two weeks ago, Martin.  If you
> have or had issue with my solution or explanation, you know how to reach
> us.  Why you're spamming the list with this today is beyond me.

Maybe because there is an AWFULLY large installed base of MS Kerberos
and I even heard from universities running MIT Kerberos KDC that they
would prefer to use Microsoft's Kerberos library client-side in
case that was possible since that would reduce their software
maintenance efforts (they'll have to constantly update Microsoft Windows
machines anyways, so why not get the Kerberos software maintenance for free).

Am I naive to expect Microsoft to care at least a little bit
about their customers?

-Martin

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 11 Mar 2004 18:03:58 -0800

[email-masked] wrote:
> In any case, the real question is: why does the LSA appear to store
the 
> name that you entered at logon rather than the canonical name?

We turn off NC if the account is marked as "DES-only", but that behavior
is not changed in all our released OSes (that is win2k and ws2k3).

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Luke Howard
Sent: Thursday, March 11, 2004 5:46 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Incompatibilities between Microsoft W2K3 and Kerberos 5

>Understood.  But for Kerberos it is not OK if the KDC changes the name
>in the AS Reply to be different than what was presented in the AS
>Request.

But that is exactly the behaviour that the referrals draft describes,
and the Windows clients depend on. When the name canonicalize bit is
set in an AS-REQ, the name in the response can be different and it IS
different.

If you do a UPN logon (user@domain), then the AS-REQ contains:

	Client Name: [email-masked]
		Type: Enterprise Principal
		Name: [email-masked]
	Realm: DSG.PADL.COM

where Realm is the workstation's default realm (I believe MS would
like to omit this in a future version). There is no requirement that
the realm be the same as the RHS of the enterprise principal name,
or indeed that the RHS be a Kerberos realm.

If you do not do a UPN-style logon (by not entering an @ symbol in
the logon dialog), then the AS-REQ contains:

	Client Name: lukeh
		Type: Principal
		Name: lukeh
	Realm: PADL-DSG

where the realm is the NetBIOS domain selected from the object picker.

In either case the name returned in the AS-REQ is the canonical name,
which is the client's SamAccountName. The realm is the canonical realm
of the domain in which the account exists.

In the following example directory entry:

	dn: CN=Martin Rex,CN=Users,DC=sap,DC=com
	objectClass: user
	sAMAccountName: martin
	userPrincipalName: [email-masked]

Martin can login as [email-masked] or martin, and the canonical
principal name returned in the AS-REP will be [email-masked].

As was recently pointed out in this mailing list, the returned client
name is not protected and so Windows actually extracts the canonical
client name from the authorization data.

In any case, the real question is: why does the LSA appear to store
the name that you entered at logon rather than the canonical name?

-- Luke

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 11 Mar 2004 18:21:51 -0800

You can turn off NC by marking the account "DES-only". There is no
change w.r.t. cname NC.

I would be happy to provide information off the list upon request.

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nicolas
Williams
Sent: Thursday, March 11, 2004 5:42 PM
To: Sam Hartman
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Incompatibilities between Microsoft W2K3 and Kerberos 5

On Thu, Mar 11, 2004 at 08:32:41PM -0500, Sam Hartman wrote:
> They do not want to make that information in the directory public.
> 
> so, the issue is that you type in fOo to your workstation.  The
> principal is actually foo.

I feel some sympathy for Martin here -- just what is wrong with users
having to know the proper capitalization of their names?  :)

> Somehow, your workstation needs to look up that mapping and get you
> credentials.

Technically, once they have the TGT they could do the lookup and then
get another TGT with the right capitalization.

> Microsoft wants to design the set of protocols between the client and
> domain controller such that you cannot find out that mapping without
> also proving that you are actually foo.

See above.

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Fri, 12 Mar 2004 14:00:22 +1100

My question is: when the name canonicalize bit is set, what name 
does a Windows 2003 KDC place in a TGT, rather than the unencrypted
part of the AS-REP? 

This is independent of the name the LSA credentials cache stores,
which I think is what Tim is talking about. Either it is the name
the client sent in the AS-REQ, the name from the service ticket
to the local machine (in which case it is really the same question
as above), or it is extracted from the authorization data / AS-REP.

Logging onto a Windows 2003 domain controller it appears that the
kerbtray name is always that which the user logged in as, which
appears to contradict Tim's spreadsheet for XP / W2K SP4.

Starting to get a bit confused :-)

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Fri, 12 Mar 2004 21:54:18 +1100

>does a Windows 2003 KDC place in a TGT, rather than the unencrypted

Hmm, it appears that Martin is right: in a Windows 2003 domain, when
the canonicalize bit is set, name canonicalization is only performed
on the realm, not the client name.

eg. kinit --canonicalize AdministratoR@PADL-NT returns a ticket for
[email-masked], whereas I believe Windows 2000 would have
returned a ticket for [email-masked]. (I don't actually
have a Windows 2000 domain to check against right now.)

(NB: PADL-NT is the NetBIOS name of NT.PADL.COM, and --canonicalize
sets the NC flag in the AS-REQ.)

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Fri, 12 Mar 2004 22:51:50 +1100

BTW, I would agree with Martin that the Windows 2000 behaviour makes
much more sense, because without it is difficult to do name based
authorization, because the service must be aware of all the client's
aliases (which could conceivably differ in more than just case).

Surely the behaviour of the canonicalize KDC option is to allow the KDC
to canonicalize the name? I understand that the name in the AS-REP is
not protected but it seems to me that the name in the ticket should be
canonicalized if the client so requested.

The referrals draft says:

   If the "canonicalize" KDC option is set, then the KDC MAY change the 
   client principal name and type in the AS response and ticket 
                                         ^^^^^^^^^^^^^^^^^^^^^^

-- Luke

---

From: Tim Alsop <[email-masked]>
Date: Fri, 12 Mar 2004 14:07:38 -0000

Hi,

I previously only tested with Win2k AD so today I made same tests using a Win2k3 server instead, but using same workstations. See below for details :

Win2k Client (SP4)
XP Client (no fixes)

I joined both of the above workstations to a standalone 2k3 domain controller.

I then create an account in AD where 'user logon name' and 'pre-win2k' logon name are same. I tested with 'user1' and 'uSer1' which were the same names I used when testing with Win2k AD. I also tried having DES flag set on, and using default cipher (RC4-HMAC).

The results were mostly the same as when I tried with Win2k AD, apart from when I used Win2k workstation - in this case I got same results regardless of whether I had the DES flag set on or off. This, I think is the same problem that Martin and Luke have observed since they were using default cipher and Win2k workstation. So, it looks like the version of AD makes a big difference, but works correctly with XP logon. This is not consistent with statement from Microsoft that there were no changes in 2k3 AD related to this functionality. Clearly there is an issue related to handling of Win2k workstation logon that needs to be fixed so it is consistent with the behaivior seen when using Win2k AD. We cannot expect everybody to upgrade to XP when using Win2k3 AD !!!

I also noticed (see attached spreadsheet) that there is something wrong with the 'ticket enc. type' when using Win2k3 AD. Can you explain why this is different with what I see when using Win2k AD ? I wasn't expecting this - would expec them to be same ...

Regards, Tim.

-----Original Message-----
From: Luke Howard [mailto:[email-masked]] 
Sent: 12 March 2004 11:52
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Incompatibilities between Microsoft W2K3 and Kerberos 5

BTW, I would agree with Martin that the Windows 2000 behaviour makes much more sense, because without it is difficult to do name based authorization, because the service must be aware of all the client's aliases (which could conceivably differ in more than just case).

Surely the behaviour of the canonicalize KDC option is to allow the KDC to canonicalize the name? I understand that the name in the AS-REP is not protected but it seems to me that the name in the ticket should be canonicalized if the client so requested.

-- Luke

---

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

Douglas,

Ok, I understand your conclustion, however if this is the case why does a win2k workstation login to Windows 2000 AD based domain controller and work correctly ? Surely the logon from a workstation should be same regardless of which version of Active Directory is deployed on the network ?

Thanks, Tim.

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

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

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. 

> Thanks, Tim.
> From: Douglas E. Engert [mailto:[email-masked]]
> Sent: 12 March 2004 17:12
> To: Tim Alsop
> Cc: [email-masked]
> 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.
> >
> > From: Martin Rex [mailto:[email-masked]]
> > Sent: 11 March 2004 18:37
> > To: [email-masked]
> > 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.
> 
> >
> > 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.
> 
> >
> > **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

-- 

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

---

From: Tim Alsop <[email-masked]>
Date: Fri, 12 Mar 2004 18:25:01 -0000

Martin,

I think you will find (based on my test results) that WinXP will not behave likewise.

Also, when I did my tests with Win2k3 AD I used native mode, not mixed mode.

So, it looks like we have same conclusions. I agree with your findings. Now, we just need a fix/solution !!

Tim. 

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: 12 March 2004 18:22
To: [email-masked]
Subject: Re: Incompatibilities between Microsoft W2K3 and Kerberos 5

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 XP 
> clients store the correct client name.

---

From: "Paul Leach" <[email-masked]>
Date: Fri, 12 Mar 2004 12:04:53 -0800

> Sent: Friday, March 12, 2004 11:12 AM
> To: Paul Leach
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Paul Leach wrote:
> > Let me toss in an observation which I vaguely recall had 
> something to 
> > do with how the present situation arose, but can't remember 
> the details:
> > 
> > Imagine you have two systems, one of which is case-insensitive, and 
> > the other is case-sensitive. How can you get names entered on the 
> > former to be usable by the latter? By being case-preserving.
> 
> We have a different situation with Kerberos.
> Currently W2K3 AD breaks Single Sign-On with kerberized or 
> gssapi based applications (which can only key on kerberos 
> principal names) because of an inappropriate translation of 
> Windows NT account names into Kerberos principal names.

I don't see how you can claim that it would be "broken" because end users
must type their name with the correct casing in order to allow apps that are
case-sensitive to work properly. Well, duh.

As I see it, then only issue is that because of the way things work now,
when they type their name incorrectly w.r.t. the case-sensitive name
checker, they find out about it at access check time, rather than at logon
time.

That would indeed be a usability issue. But the current algorithm produces
correct results with correct inputs.

---

From: Luke Howard <[email-masked]>
Date: Sat, 13 Mar 2004 11:17:03 +1100

Tim,

I did some more testing of XP against W2K3. I noted the following four
cases:

+---------------------------+--------------+-------------------+--------------+-----+
| AS-REQ name               | AS-REQ realm | AS-REP name       | AS-REP realm | DES +
+---------------------------+--------------+-------------------+--------------+-----+
| [email-masked] | NT.PADL.COM  | Administrator     | NT.PADL.COM  | NO  +
+---------------------------+--------------+-------------------+--------------+-----+
| AdministratOR             | PADL-NT      | AdministratOR     | NT.PADL.COM  | NO  +
+---------------------------+--------------+-------------------+--------------+-----+
| [email-masked]         | NT.PADL.COM  | [email-masked] | NT.PADL.COM  | YES +
+---------------------------+--------------+-------------------+--------------+-----+
| lukeH                     | PADL-NT      | lukeH             | NT.PADL.COM  | YES +
+---------------------------+--------------+-------------------+--------------+-----+

So, only in the case that a user does a UPN logon (where a user@domain name
is entered into the logon dialog), does it appear that the name is canonicalized
as it was with Windows 2000 ("correctly").

Interestingly the UPN logon behaviour with UF_USE_DES_KEY_ONLY appears to
contradict the referrals draft:

   The KDC will recognize this name type and then transform the 
   requested name into the true principal name. The true principal name 
   can be using a name type different from the requested name type. 
   Typically the returned principal name will be a KRB-NT-PRINCIPAL. 
   The returned name will be the same in the AS response and in the 
   ticket. The KDC will always return a different name type than KRB-
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   NT-ENTERPRISE-PRINCIPAL. This is regardless of the presence of the 
   ^^^^^^^^^^^^^^^^^^^^^^^^
   "canonicalize" KDC option. 

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Sat, 13 Mar 2004 11:18:25 +1100

To clarify -- the name type for all names with an "@" symbol is
KRB-NT-ENTERPRISE-PRINCIPAL.

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Sat, 13 Mar 2004 11:27:04 +1100

>Imagine you have two systems, one of which is case-insensitive, and the
>other is case-sensitive. How can you get names entered on the former to be
>usable by the latter? By being case-preserving.

Right, and you want to case-preserve the user's name in the directory,
not the name they enter at logon time, otherwise it is difficult for
case-sensitive services to do name-based authorization.

The client name canonicalization as implemented in the Windows 2000 KDC
provided exactly this. It appears that this is no longer the case for the
Windows 2003 KDC if you do not login with your UPN.

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Mon, 15 Mar 2004 14:29:11 +1100

Some background: Windows clients joined to a domain always request name
canonicalization by setting the "canonicalize" KDC option in the AS-REQ.
This option is described in draft-ietf-krb-wg-kerberos-referrals-xx.txt.

The principal use of client name canonicalization, at least as described
by early revisions of the referrals draft, is to lookup "global" names
(such as [email-masked]) in a name service. In this case, the client
sends a name type of KRB-NT-ENTERPRISE-PRINCIPAL in the AS-REQ and the
reply contains the user's canonical name.

In Active Directory, these "global" names are called User Principal Names
or UPNs, and the name service is the global catalog (GC). A user can always
logon with a UPN of "user@realm" but they can also be assigned an alternate
UPN. In this case the "realm" need not be a DNS domain or Kerberos realm,
merely a "UPN suffix" that registered in Active Directory. Users can thus
logon with familiar names (e.g. e-mail addresses) or retain existing logon
names as realms are reorganized. (This description is meant to be illustrative
only; another implementation might impose different constraints on the "realm"
component of names of type KRB-NT-ENTERPRISE-PRINCIPAL.)

Client name canonicalization can also be used where the name type is not
KRB-NT-ENTERPRISE-PRINCIPAL; the AS-REP will still contain the canonical
name. In the case of Active Directory, this allows the AS-REP to contain
the case-preserved name, even though the name attribute is case-
insensitive. (Canonical names are always single part, being the value of
the sAMAccountName attribute in Active Directory.) This behaviour is
pretty much mandatory for case-sensitive name based authorization to be
useful, as Martin has discovered.

Windows 2000 clients always set the "canonicalize" KDC option in AS-REQ.
(As it happens this also has the side-effect of turning on server name
canonicalization, but as an AS-REQ is usually for the well known TGS,
it's safe to discuss it with respect to client name canonicalization.)

The Windows 2000 KDC will always perform client name canonicalization
when the the "canonicalize" KDC option was set (except as discussed
below with respect to DES-only principals). Hence, if you logged on as
"AdministraTOR", the principal in the AS-REP (and in the TGT) would be
"Administrator".

(The Windows KDC also performs name canonicalization on the realm part,
and this cannot be turned off; when you logon as a non-qualified name,
i.e. not a UPN logon, then Windows will do an AS-REQ for cname=user,
crealm=BAR, where BAR is the NetBIOS name of the domain; the AS-REP will 
always contain the DNS qualified realm name.)

The referrals draft also implies that, if a KRB-NT-ENTERPRISE-PRINCIPAL
name is sent in the AS-REQ, the KDC should be behave as if the
"canonicalize" KDC option was requested.

The behaviour of the Windows 2003 KDC changed to effectively match
an OLDER version of the referrals draft, where the only way name
canonicalization would be perform was if a KRB-NT-ENTERPRISE-PRINCIPAL
name was sent, i.e. the KDC option was ignored for the purpose of
client name canonicalization.

This explains Martin's problem, and it appears to be a known regression
(Larry can comment further). A workaround to always logon with your
UPN.

Finally, there is an exception to the honouring of the "canonicalize"
option, and this explains what Tim initially reported. When an account
is set for DES-only, then the Windows KDC will not canonicalize the
name returned in the AS-REP, even if the client set the "canonicalize"
KDC option or sent a KRB-NT-ENTERPRISE-PRINCIPAL name. This happens for
both Windows 2000 or 2003. In this case it seems like marking accounts
that will initially authenticate against Windows as DES-only is not a
good idea; moreover, associating the "DES-only" attribute with more
than just restricting a client's enctypes will likely cause problems
as non-Windows Kerberos implementations support RC4 and AES, if the
extra behaviour is required for interoperability.

(Interestingly, the KDC will still internally canonicalize names of
type KRB-NT-ENTERPRISE-PRINCIPAL for the DES-only case; this is not
compatible with the referrals draft.)

The other change in Windows 2003 was that, in a TGS-REQ, the server
name is not canonicalized regardless of the setting of the
"canonicalize" option. But that is not relevant to this discussion.

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Mon, 15 Mar 2004 20:28:18 +1100

Just to clear up/summarize a few things from re-reading my post:

Client name canonicalization can be requested in the AS-REQ by
either sending a principal whose name type is KRB-NT-ENTERPRISE-PRINCIPAL
or setting the "canonicalize" KDC option.

When a name is "canonicalized", the principal in the AS-REP and the
ticket therein may have a different name to that requested by the
client. Indeed, the KDC should not return an enterprise principal
in an AS-REP (although Windows does for UF_USE_DES_KEY_ONLY). This
latter requirement is described in the referrals draft.

The difference between Windows 2000 and Windows 2003 is that the
latter only honours the name type in determining whether to perform
name canonicalization.

+==================+==================+=====+===============+=================+
| KDC              | Input name type  | DES | Canon KDC opt | Canon performed |
+==================+==================+=====+===============+=================+
| Windows 2000     | ENTERPRISE-PRINC | NO  | NO            | YES (???)       |
+------------------+------------------+-----+---------------+-----------------+
| Windows 2000     | PRINCIPAL        | NO  | NO            | NO              |
+------------------+------------------+-----+---------------+-----------------+
| Windows 2000     | ENTERPRISE-PRINC | NO  | YES           | YES             |
+------------------+------------------+-----+---------------+-----------------+
| Windows 2000     | PRINCIPAL        | NO  | YES           | YES             |
+------------------+------------------+-----+---------------+-----------------+
| Windows 2000     | ENTERPRISE-PRINC | YES | NO            | NO              |
+------------------+------------------+-----+---------------+-----------------+
| Windows 2000     | PRINCIPAL        | YES | NO            | NO              |
+------------------+------------------+-----+---------------+-----------------+
| Windows 2000     | ENTERPRISE-PRINC | YES | YES           | NO              |
+------------------+------------------+-----+---------------+-----------------+
| Windows 2000     | PRINCIPAL        | YES | YES           | NO              |
+==================+==================+=====+===============+=================+
| Windows 2003     | ENTERPRISE-PRINC | NO  | NO            | YES (???)       |
+------------------+------------------+-----+---------------+-----------------+
| Windows 2003     | PRINCIPAL        | NO  | NO            | NO              |
+------------------+------------------+-----+---------------+-----------------+
| Windows 2003     | ENTERPRISE-PRINC | NO  | YES           | YES             |
+------------------+------------------+-----+---------------+-----------------+
| Windows 2003     | PRINCIPAL        | NO  | YES           | NO (*)          |
+------------------+------------------+-----+---------------+-----------------+
| Windows 2003     | ENTERPRISE-PRINC | YES | NO            | NO              |
+------------------+------------------+-----+---------------+-----------------+
| Windows 2003     | PRINCIPAL        | YES | NO            | NO              |
+------------------+------------------+-----+---------------+-----------------+
| Windows 2003     | ENTERPRISE-PRINC | YES | YES           | NO              |
+------------------+------------------+-----+---------------+-----------------+
| Windows 2003     | PRINCIPAL        | YES | YES           | NO              |
+==================+==================+=====+===============+=================+

(*) denotes behaviour different between Windows 2000 and Windows 2003.

(???) denotes a combination I haven't tested.

>compatible with the referrals draft.)

This doesn't make sense, what I meant to say was:

When UF_USE_DES_KEY_ONLY is set on a user account, name canonicalization
will not be performed regardless of whether the "canonicalize" KDC
option was set or the principal in the AS-REQ was KRB-NT-ENTERPISE-PRINCIPAL.
(See table above.)

The referrals draft says that you should not return an enterprise
principal in an AS-REP and hence this behaviour seems to contradict
that.

-- Luke

---

From: Sam Hartman <[email-masked]>
Date: Mon, 15 Mar 2004 22:21:36 -0500

>>>>> "Actually" == Actually davidchr <[email-masked]> writes:

    >> I feel some sympathy for Martin here -- just what is wrong with
    >> users having to know the proper capitalization of their names?
    >> :)

    Actually> SIDE NOTE: if anyone genuinely doesn't understand why we
    Actually> at Microsoft have no hope of implementing a
    Actually> case-sensitive logon scheme even if we wanted to, and/or
    Actually> why we have no desire to do it even if we could, please
    Actually> contact me off-list for an explanation so I can avoid
    Actually> spamming the list.

I certainly understand this.  I'm not entirely convinced that you
wouldn't be better off implementing features to make name based
authorization work better.  However I completely understand that
case-sensitive is just wrong.