[OpenAFS] Fw: it would be nice to have an administrators guide
Mon, 26 Dec 2016 11:37:17 +0000
So far by using the eclipse IDE , I've added afslog=3Dtrue to [appdefaults]
I'll implement your directions after a quick nap
-afslog doesn't cooperate, I'll figure that out today.
From: Benjamin Kaduk <email@example.com>
Sent: Sunday, December 25, 2016 2:10:13 PM
To: Ted Creedon
Subject: Re: [OpenAFS] Fw: it would be nice to have an administrators guid=
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 key=
s 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-p=
keys (a regression introduced as part of the fix for OPENAFS-SA-2013-003 [0=
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 star=
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 th=
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.