Windows with Krb5

[Jeffrey Hutzelman]

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.



Anyway, the important point about NT and fakeka is exactly as you
described -- NT doesn't use the kaserver interface at all for
authentication; it uses the krb4 protocol.  This also means that if you
are using ka-forwarder instead of running KDC's on the same machines as
AFS dbservers, it won't work.  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.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA