[OpenAFS] Fw: it would be nice to have an administrators guide
Sun, 25 Dec 2016 16:10:13 -0600
On Fri, Dec 23, 2016 at 02:00:20AM +0000, Ted Creedon wrote:
> it would be nice to have an administrators guide on how to set up the keys for openafs 1.8 + heimdal 7.1
> the intermixture of ad, heimdal & mit is confusing to say the least.
> could you provide one?
The main difference between the key setup for 1.6 and the key setup for 1.8
is that 1.6 uses a kerberos keytab named rxkad.keytab to store the server-private
keys (a regression introduced as part of the fix for OPENAFS-SA-2013-003 ),
whereas for 1.8 the keys an OpenAFS-specific file KeyFileExt is used.
Buried in the 1.8.0 release notes is an item that the 'akeyconvert' utility
reads rxkad.keytab and writes out the corresponding bits to KeyFileExt.
So, the short answer to your question would be to start with the quick start
guide for Unix (http://docs.openafs.org/QuickStartUnix/index.html) for the
cell setup instructions, including creating rxkad.keytab in the
"Starting the BOS Server" section, and then running 'akeyconvert' after
I do not run any heimdal-based realms or cells, so I cannot really provide
heimdal-specific instructions, but the main point of integration between
kerberos and OpenAFS is that there should be a kerberos principal
afs/<cell>@REALM in the kerberos realm to be used for the cell. Kerberos
keys with strong (i.e., AES) encryption types should be used for that
principal, and a keytab created for it with name rxkad.keytab in the
OpenAFS server configuration directory (i.e., /etc/openafs/server on Debian).
After creating the rxkad.keytab, run 'akeyconvert' on that system, and copy
the resulting KeyFileExt to any additional AFS server machines in the cell.
Users of the cell need to have user principals in order to be able to use
aklog (or klog.krb5 is that is desired), and the PTS entries with the
corresponding names need to exist in the protection database in order
for those AFS users to be able to have filesystem permissions granted to them.
Please reply back if there are parts that need further clarification.
 This is a regression because it forces most AFS binaries to be linked
against libkrb5, whereas traditionally one could operate AFS independently
of kerberos except for aklog (if desired) and asetkey.