Use of Kerberos is mandated by the use of AFS.

Kerberos is an authentication protocol allowing mutual authentication in and over untrusted networks, by use of the trusted third party. Each Kerberos server runs one or two components: the KDC (Key Distribution Center) and kadmind (Admin server). KDC is what performs authentication; Kadmin is the "management interface" for the Kerberos principals database.

Kerberos is very simple and fits cleanly in the infrastructure. User's passwords (be it interactive or from keytab files) are verified against KDCs. Everything else is automatic and requires no attention, except maybe for the fact that Kerberos support in OpenSSH breaks public key logins, which displeases some members. (In Jan 2010, machines are rearranged to allow one to be "standard Linux" login machine, with Unix passwords, SSH keys and local filesystem.)

1. The kadmin shell

All Kerberos administration commands are run from a special shell, called Kadmin. There are two variants of Kadmin. Kadmin is the usual, remote version of the command which can be run on any machine and requires username and password to connect to the Kerberos admin server. Kadmin.local is the "local" version which can only be ran on the Kerberos KDC machines. (Although it only makes sense running it on Kerberos master server, as any database changes on the slaves will be lost on next update from the master server).

Invoke kadmin.local as sudo kadmin.local -p YOURUSERNAME_admin. It is good to include "-p YOURUSERNAME_admin", or kadmin will "authenticate" as the first user it finds in the ticket cache, which may or may not be the username you expected. All the administrative commands would work anyway (since you ran kadmin.local), but an incorrect principal name would make various statistics incorrect (like name of principal who was adding/changing entries in the DB), reducing logs "meaningfullity". (I want bonus points for this word).

To invoke kadmin, use kadmin -p YOURUSERNAME_admin. In normal course of action, kadmin asks for a password.

Providing a password is impractical for automated scripts. As usual, instead of a password, you can also pass a keytab file. Our keytabs are saved in /etc/keytabs/ on each system, and they are readable by group 'wheel'. So administrators should be able to invoke 'kadmin' (use control shell) or kinit/k5start (impersonate any user) by supplying target user's key from a keytab, such as kadmin -p domtool -k -t /etc/keytabs/domtool.

However, domtool and a couple other keytabs are special cases. One can only obtain the user's $USER.daemon token, which has access to assorted user's read and write directories. There is no way to authenticate as $USER by means other than providing a password. (Strictly speaking, Krb/AFS admins can do it, but others cannot, not even from the Unix root account).

2. Creating users

This section talks about creating PTS entries for system services. (Creation of user entries is done automatically by create-user script and no manual work is needed).

We follow the convention that Kerberos users for daemons are named $DAEMON, where $DAEMON is the name of the daemon (for instance, the name of system user it runs as, or the name of its /etc/init.d file).

To add the Kerberos principal for a daemon, run this in kadmin:

addprinc -randkey -policy service $DAEMON

AFS users exist separately from Kerberos principals. To add the AFS user for a daemon to which you want to assign UID $UID, run:

pts createuser $DAEMON

. It is very good if the UID maches the Unix ID, so that there are no confusions in ls or any other output with user IDs.

"keytab" files smooth the way to running daemons that run with AFS privileges. An access-protected local file contains a user's credentials, and daemons read these files on starting up in order to authenticate.

To create a keytab for a daemon, run this in kadmin:

ktadd -k /etc/keytabs/$DAEMON $DAEMON
chown $DAEMON:wheel /etc/keytabs/$DAEMON
chmod 440 /etc/keytabs/$DAEMON

In the example above, only one key (of 4 or 5 created) is exported for a user. Sometimes it might be desirable to only export a specific key into a keytab file, but we generally just omit the -e KEY_TYPE parameter and export all keys to the keytab file.

You can view keys stored in a keytab by doing sudo klist -k /etc/keytabs/KEYTAB_FILE.

To make daemons properly kinit/aklog as the user you created for them, use k5start command. Many examples of how to use it are already found in our /etc/init.d/ scripts. Important options include -U (which kinits as the first principal found in the keytab file, without the need to explicitly name a principal), -f (which specifies the keytab file to kinit from), and -K MINUTES (which re-news the ticket after MINUTES, so that daemons can run for long periods of time).

3. Changing Passwords

If a user requests a password reset the following should be done after ensuring the request comes from a legitimate source.

Invoke kadmin and at the shell issue:

change_password $USER

CategorySystemAdministration CategoryNeedsWork