Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.420 (Entity 5.420)
Subject: Missing fakeka documentation
X-RT-Original-Encoding: iso-8859-1
Content-Length: 1526

fakeka's man page could use some additional details about what's
required for it to work and some expansion of the details already
mentioned.  I can probably contribute the additional documentation, but
I want to get this into a ticket while it's all fresh in my mind.

First, while it mentions that you need des:v4 or des:afs3, that could be
expanded a bit.  Specifically, AFS klog first tries an :afs3 salt using
the cell name as the realm for the salt, and then tries :v4 (no salt). 
If your Kerberos realm and AFS cell names match, either des-cbc-crc:afs3
or des-cbc-crc:v4 keys will work.  If the realm names do not match, you
have to use des-cbc-crc:v4 keys.  Only users with those keys will be
able to klog using fakeka.  It's worth mentioning explicitly that
des-cbc-crc:normal will not work and that that's the v5 salt.

Second, the AFS key must exist in the Kerberos KDC database as a DES key
(the salt doesn't matter), and that must match (including kvno) what's
in the KeyFile on the AFS servers.  This principal may be "afs" if the
realm and cell names match, but generally should be afs/cell.name.

Third, if the Kerberos realm name and AFS cell name do not match, you
must also create a krbtgt/CELL.NAME principal in your KDC database with
a DES key (any salt).  The key can be random and doesn't have to be
synchronized with anything else; it just has to exist for klog to work
properly because klog first does an Authenticate call to get a krbtgt
and then does a GetTickets call to get the afs service ticket.