[OpenAFS] some simple openafs questions

[Jeffrey Hutzelman]

On Friday, July 25, 2003 09:59:38 +0200 Christian Ospelkaus
<christian@core-coutainville.org> wrote:

>> I do want klog to continue working with my server.
>>
>> In any case, is there any other reason to prefer one implementation -
>> Heimdal vs MIT - versus the other?
>
> If you compile applications with Kerberos support yourself, this may be
> easier with the MIT version. You need to distinguish between the KDC and
> the  client programs. As far as I know, a Heimdal KDC has the advantage
> that it  can also provide you with Kerberos 4 backwards compatibility.

You are confused.  Both implementations do support v4 clients.  The MIT
implementation includes a complete set of Kerberos v4 libraries.  Heimdal
contains some v4 features, which depend on building against the KTH krb4
distribution, which is packaged separately.  Both KDC's are capable of
responding to v4 requests (the Heimdal KDC may do this only if built
against kth-krb; I don't recall offhand).

However, note that this is not relevant to clients like klog, which do
_not_ speak the Kerberos v4 protocol.  The authentication utilities which
are included in the AFS distribution speak an AFS-specific protocol which
is used to communicate with the kaserver (the kaserver also answers
Kerberos v4 requests, but the only tools in OpenAFS that use this feature
are related to obtaining tokens on Windows machines).

If properly built and configured, the Heimdal KDC is capable of answering
requests from klog and other kaserver clients.  The MIT KDC does not
support this feature directly, but it is available through an add-on server
(fakeka), which is available as part of Ken Hornstein's migration toolkit.
The toolkit is available from
/afs/grand.central.org/contrib/security/afs-krb5.

> On the client side, the Heimdal programs provide excellent AFS
> integration.  For example, if I do a kinit, I get a V5 ticket, and it
> also transparently  gets an afs token. With MIT, you need to do a kinit
> to get a V5 ticket, and  then aklog from the openafs-krb5 package to
> obtain a token. I use a  configuration with a Heimdal KDC, the Heimdal
> client programs, the  libpam-krb5 PAM module (compiled against MIT
> libraries) for Kerberos  authentication at login and the
> libpam-openafs-session module for token  grabbing at login.
>
> Note that in order to make it all work that way, heimdal needs to be
> compiled  with AFS and kth-krb4 (which is the case with the Debian
> packages).
>
>> I take it this kaserver is a KRB 4 implementation? Is it part of openafs?
>> I can't see anything that looks like this in the openafs packages.
>
> It is Kerberos 4. I can't find it in the packages either. But it is part
> of  the sources of openafs.

As noted above, the kaserver isn't really Kerberos 4.  It's part of an
authentication unique to AFS, which uses a completely different wire
protocol from krb4.  It happens to be the case that the encrypted part of
an AFS token has the same format as the encrypted part of a Kerberos 4
ticket, which makes it possible for a client program like the v4 aklog to
translate between the two.  The kaserver does respond to standard Kerberos
4 requests, but in OpenAFS, only a few tools in the Windows client use this
functionality.

In any case, the kaserver is not packaged for Debian, because new
installations should not be using it.  You should instead set up a Kerberos
V KDC (MIT or Heimdal), and use an aklog like that found in the
openafs-krb5 package (though certainly, if you build Heimdal with kaserver
support or use the MIT KDC with fakeka, you can continue to use klog as
well).

>> Isn't this one for kaserver, though?

Correct -- the kpasswd in the Debian openafs-kpasswd package speaks the
kaserver password-changing protocol.  It is included for use on machines
which are clients of AFS cells still using the kaserver.  Otherwise, you
don't need it.

>> > openafs-ptutil
>>
>> This one doesn't seem to exist any longer.

I believe ptutil has been rolled into the openafs-dbserver package, where
the ptserver lives.  It was once a separate package because it was not part
of the upstream OpenAFS distribution.

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