Kerberos
UGCS uses Kerberos for all of our authentication needs. See The Moron's Guide to Kerberos for an introduction to how Kerberos works. This page merely documents the way UGCS does it.
Contents |
Kerberos Servers
krb-head (CNAME zeus) and krb-backup (CNAME hera) are our two Kerberos servers, as listed in our section for krb5.conf. They each run a KDC, and have provisions for pushing updates from zeus to hera. They also have the kadmin.local command, which will be described later.
Pushing Updates
Updates are pushed through the kprop service. First, the kerberos database is dumped with krb5_util to a file, and then the kprop protocol is used to push the new database to hera. This means that hera must have the kprop service running (usually as an inetd service)
Nagios Tests
Nagios tests a couple of things for Kerberos:
- TCP port 88 (Kerberos port) and 749 (kadmin, zeus only)
- Kerberos backups (zeus only)
- Kerberos propagation (hera only; checks the age of the krb5kdc directory to see if it's been updated)
- Getting tickets is indirectly tested by the ssh login test scripts
Access to Kerberos
Understandably, we don't want just everyone to have write access to our kerberos databases. All sysadmins can perform all operations except add new principals from their username/admin principal. This means that if you want to change a password, unlock an account, etc, you can do it by running the "kadmin" command anywhere in the world. You will be prompted for a password for "<username>/admin", which you better not have set to be the same as your account password (for security reasons). Then you can look at the kadmin documentation (it's pretty simple).
There is another principal, newacct_create, that can only create accounts. The keytab for this account is sitting on dionysus, where a remctl command from the account creator causes it to make the new principals (both username and username_cgi), but locked.
See /etc/krb5kdc/kadm5.acl for the ACL information for these accounts.
Keytabs
Somtimes, you will want a service to have a kerberos principal, but obviously don't want to have to enter a password every time. To solve this problem, keytabs were invented. A keytab is a file that contains the name and long binary password for a (or possibly multiple) kerberos principal(s). If you have created a principal, you can export a keytab to a file by running the following kadmin command
ktadd -k <keytab file> <username>
This will append the keytab to the file, so it will not wipe out existing entries in the keytab file. It will also reset the password of the principal- you cannot have both a keytab out and a password for the same principal.
Once you have a keytab file, you can use the ktutil command to modify it. See the ktutil documentation for how to use it. Since this only operates on local files, you just need local root, not any special kerberos privileges.
UGCS notes
At UGCS, every user has two principals: <username> and <username>_cgi. The keytab for the _cgi principal is added to /etc/apache2/ugcs-cgi.keytab by a cron script on demeter that picks up new entries from /afs/.ugcs/newacct-drop/keytabs (they are placed there by create-pending-account.py) If this doesn't work, you'll have to do it manually with kadmin.
