Windows with Krb5

[Kevin Rowland]

Jeffrey Hutzelman wrote:
> 
> On Tue, 24 Apr 2001, Kevin Rowland wrote:
> 
> > The NT client doesn't use fakeka for it's authentication. It uses
> > udp/750 (standard K4). Because of that, the first enctype that is stored
> > in the KDC for a user is the one that will be used (I think). What we
> > did was make sure the our kdc.conf listed the 'des-cbc-crc:afs3' enctype
> > first. This seemed to satisfy the NT clients. UMICH has made some
> > modifications to the K4 libraries to make them act more like a kaServer,
> > but since we have no K4 salted keys (only afs3 style) besides the K5
> > keys in the KDC, we just ordered them with afs3 at the top.
> >
> > Question: Does anyone see that as being a problem? So far everything
> > seems fine in our testing. Since K5 allows for the client to specify
> > which enctype it supports, the issue seemed to only affect K4 style
> > authentications...
> 
> Note that the ':afs3' is _not_ part of the enctype; it describes the
> string-to-key algorithm or "salt type".  The krb5 protocol does _not_
> provide a way for clients to specify this.  It does provide a way for the
> KDC to tell you what the salt string is, but that assumes that the
> string-to-key algorithm doesn't change -- and for afs3, it does.
> 
> The net effect is that if you have krb5 clients that don't support the AFS
> string-to-key, you might have problems.  I don't recall what the best
> solution is to this problem; perhaps someone more familiar with the krb5
> implementation can comment on this.

Ahhh... yes... good point. Win2K comes to mind :-) Win2K supports the
des-cbc-crc and des-cbc-md5 enctypes but does not support the afs3 salt.
I had done my Win2K interop testing before I switched the order of the
keysalt list in the kdc.conf file. I just verified that with the afs
salted des key listed first, Win2K cannot properly handle the KDC's
AS-REP.

> <...snip...>
> To work around this, configure NT clients
> to believe that your KDC's are AFS database servers.  These extra
> "database servers" will be used for Kerberos authentication, and then
> timed out as vlservers fairly quickly.  This setup has worked well for us
> in production more or less since the NT client was released.

I believe this works for you because you (UMICH) inserted code into
kerberos_v4.c that searches for an afs3 salted key *before* a v4 style
in response to a K4 request. This situation, otherwise, would not work
(as it didn't for us -- which is what prompted me to try switching the
keysalt list order). Am I missing something? Looks like I need to
revisit the kerb_get_principal() code and incorporate that in to see if
we can make both the AFS-NT client *and* Win2K clients happy...

Is anyone else using/not using this workaround and using both Win2K
domain trust to MIT REALM and the AFS-NT client?

-- kevin

/-------------------------------------------------------------------\
| Kevin Rowland                          Phone:   (219)631-4745     |
| Sr. Systems Engineer                   Email: krowland@nd.edu     |
| Office of Information Technology       G208 Hesburgh Library      |
| University of Notre Dame               Notre Dame, IN   46556     |
\-------------------------------------------------------------------/