Subject: Re: Incompatibilities between Microsoft W2K3 and Kerberos 5

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

Actually davidchr wrote:
> 
> > [mailto:[email-masked]] On Behalf Of 
> > Martin Rex
> > 
> > Sam Hartman wrote:
> > > 
> > > 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.
> > 
> > Huh?  public?  They only need to acquire a ticket with the 
> > canonical name
> > instead of the arbitrary case user input--I really don't care 
> > when they
> > do this without telling me unless the authentication succeeds.
> 
> Unless your brand of "canonicalization" is an arbitrary up- or
> down-case, canonicalizing the cPrinc would require a roundtrip to some
> trusted authority.  That authority must require authentication.  

Nope.  During logon there is always one or the other possibility of DoS,
so I discount DoS.  The canonicalization that we require here doesn't
need to be authenticated, and the response must differ from the request
only in case -- in order to address this logon problem.

> 
> If you're recommending we use the user's TGT to do this, it results in
> us getting multiple TGTs for the sole purpose of canonicalizing the
> principal's case.  That's a bit expensive for something so trivial,
> wouldn't you say?  It's unreliable too-- there are race conditions (the
> principal may be deleted between the calls, or it might be renamed...
> The case could change, or the password) as well as other concerns.  It
> isn't worth it.

Hey, that is a one time overhead and the result can be easily long-term
cached by the LSA (if the authentication succeeds).  By default the
LSA caches a lot more account information, including the canonical
account name.

> 
> > > 
> > > They also don't want the host to be authorized to do this
> > > mapping without user credentials.
> > 
> > Double-plus-huh?
> > 
> > For domain authentications to work with a Windows NT workstation
> > the workstation must already be a member of that domain (or another,
> > trusted domain).  
> 
> Clarification: s/domain authentication to work with/someone to
> authenticate to/
> 
> Obviously, an unjoined workstation can still use Kerberos to another,
> joined host.

So the situation that you've created with W2K3 is:
(a) if an unjoined workstation is used and the user tries to log on
    using an non-Microsoft KDC managed account he must enter
    the user name case-corrrect or will get an authentication failure
(b) if an unjoined workstation is used and the user tries to log on
    using a Microsoft KDC managed account, he may enter an arbitrarily
    cased account name and will receive a ticket.  However this ticket
    will get him rejected by all gss-api based and kerberized apps in
    case he did not coincidentally spell the username exactly as it
    is stored in the ACLs of those kerberized or gssapi-based apps.

This doesn't sound like independent interoperable implementations
of the same Kerberos protocol spec to me!

Do you distinguish it visually on the logon screen the situation
where I select a Microsoft-KDC-managed REALM name versus a
non-Microsoft-KDC-managed REALM name *before* an authentication
is attempted?

I think I'm not impressed.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Mar 2004 20:01:54 -0600

> > The case could change, or the password) as well as other concerns.  It

I don't buy the race conditions argument because you already have to do
a TGS-REQ anyways to get a ticket for the computer principal to validate
the TGT with.  Yes, getting a second TGT means doing a new AS exchange
and the password may have expired, the user been deleted and so on, but
those aren't races -- if the password's expired, change it and start
again, and if the principal's been deleted, well that's where you stop
and fail the login attempt.

> LSA caches a lot more account information, including the canonical

Plus Windows is already doing lots of stuff at logon time and doing this
one bit more, while it might, I suppose, be the straw that breaks the
camel's back (i.e., brings out the worst in users), shouldn't be so bad.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 12 Mar 2004 03:15:01 +0100 (MET)

> and fail the login attempt.

Similar for renamed accounts--if it changes during the replace operation,
fail the complete logon.  Actually that would be a security benefit,
because the logon could have been delayed exactly this time by all
sorts of other reasons (busy machine,swapping) causing the exact same
failure.

And then there's LSA which is caching tons of account information already
(probably including the canonical name), so a local canonicalization
check is possible.  And when the canonical account name is inside of
the ticket, then we can save the extra TGT roundtrip for all cases
where the user happened to have used the canonical representation,
even when we don't have a local cached copy before the AS_REQ to
compare to.

> camel's back (i.e., brings out the worst in users), shouldn't be so bad.

I don't think there will be a performance issue considering the
possibilities use cached canonical names almost all of the time.

And if you really think there is--you could create an account property
to toggle this (maybe a REALM-global flag as well for ease of use by those
who need it badly).

-Martin