Kerberos
From Syscore
Contents |
Using Kerberos
At UMBC, it's as simple as logging in. All of the OIT UNIX systems verify a user's password by attempting to retrieve a ticket granting ticket for your principal (your username is the name of your kerberos principal), which can later be used to authorize you to other Kerberos-aware services (such as PH). You can see your current Kerberos credentials (tickets and credentials are used almost interchangably in the Kerberos system) by typing klist.
irix1[3]# klist Ticket cache: /tmp/krb5cc_p486390 Default principal: banz@UMBC.EDU Valid starting Expires Service principal 20 May 99 20:59:54 21 May 99 21:59:53 krbtgt/UMBC.EDU@UMBC.EDU 20 May 99 20:59:54 21 May 99 21:59:53 afs@UMBC.EDU irix1[4]#
The output of this command shows that I have my Kerberos ticket-granting-ticket, krbtgt/UMBC.EDU@UMBC.EDU. Since AFS generates your token from your Kerberos credentials, an afs ticket is also retrieved for you as part of your login process. A service ticket, like that for AFS includes, as encrypted data, information that identifies the ticket as being owned by you and an expriation time (by default, 25 hours). Also part of the package is the AFS service key, a secret key known only to the AFS servers, that is required to decrypt the package and verify it's authenticity.
Ticket and AFS token expiration
Most users will never experience their Kerberos tickets (or AFS tokens expiring), since the default expiration time of 25 hours is much more than the length of time most people log in for. However, for faculty or staff that may be constantly logged in from their offices, or users who log in from other places on the Internet (via ssh, of course), may find that their Kerberos, and AFS credentials will expire. The most obvious symptom of which is getting a permission denied when trying to access any file in your home directory!
Verifying that you have expired tokens is easy. AFS supplies the tokens command, which is similar to the klist command for Kerberos, but it deals only with AFS tokens (which are stored in the kernel of the machine you are using).
irix1[5]# tokens Tokens held by the Cache Manager: User's (AFS ID 4906) tokens for afs@umbc.edu [Expires May 21 12:02] --End of list-- irix1[6]#
...is the normal output of the tokens command. When you have expired tokens, the output will be similar to this:
irix1[6]# tokens Tokens held by the Cache Manager: --End of list-- irix1[7]#
Getting new tokens is as easy as typing kinit, which will retrieve you new Kerberos credentials, and as a side effect, also retrieve, or update, your AFS tokens.
irix1[7]# kinit Password for banz@UMBC.EDU: enter your password irix1[8]#
...and you can continue working. Kerberos, SSH, and Remote Logins
SSH, running on most any machine that is running AFS and Kerberos at UMBC, is configured to use Kerberos to:
- Provide password-less logins
- Forward kerberos (and AFS) access credentials to the target machine.
While any machine, with the correctly configured SSH client, has the ability to authenticate itself via kerberos to any machine, not all systems are configured to receive such authentication. Major server machines, such as umbc7, irix1, irix2, linux1, and linux2 are, and for most purposes this is sufficient. If you have a machine that your absolutly need password-less login to, please contact systems@umbc.edu and arrange to have a host key generated for your machine to enable remote kerberos logins.
KDC Configuration
We currently have two Kerberos KDCs, a primary and a secondary read-only replica which is updated every 15 minutes.
See Also: Kerberos Password Policies
Software version
We are running a locally modified version of [MIT Kerberos] 1.3.5 on our KDCs. The current source tree is located at /afs/umbc.edu/src/afsapps/kerberos/current/krb5-cvs.
kdc.conf
[kdcdefaults]
kdc_ports = 88,750
[realms]
UMBC.EDU = {
database_name = /usr/k5s/var/krb5kdc/principal
admin_keytab = /usr/k5s/var/krb5kdc/kadm5.keytab
acl_file = /usr/k5s/var/krb5kdc/kadm5.acl
dict_file = /usr/k5s/lib/pw_dict
key_stash_file = /usr/k5s/var/krb5kdc/.k5.UMBC.EDU
kadmind_port = 749
max_life = 25h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = des-cbc-crc
supported_enctypes = des-cbc-crc:normal des-cbc-crc:v4 des-cbc-crc:afs3
}
Logging
KDC and Kadmin requests are logged to loghost, as well as local log files.
Local Modifications
Cracklib support
Our kadmin daemon has been modified to check user password changes through Cracklib. (see Kerberos Password Policies)
Forwarded Kerberos Requests
Our KDC can accept Krb4-style requests forwarded from our AFS database servers. This is in order to accept authentication from braindead klog clients which wish to speak "real Kerberos" instead of "rxka."
Password synchronization
Password changes are synchronized through an external script to our LDAP server and potentially other authentication services, such as Active Directory. It does this by executing /usr/k5s/sbin/syncpass, a perl script, and sending two lines -- the first one being the principal name, and the second being the key.
Currently, the script only sends changes off to the LDAP server, however, code has been written to also update our Active Directory's password store, but hasn't been enabled yet.
Slave propagation
The master propagates the database to the slave as a binary image (both servers are of the same architecture and operating system.) The master "locks" the database, makes a quick copy of it, and then does an rsync-over-ssh to the slave KDC. Once this is done, the slave locks its database and the new binary image is copied into place.
Backups
The master backups up its various filesystems via tar, PGP encrypts them, then copies them to jumpcore.umbc.edu, where they are stored and then backed up via our Legato Networker backup system. The OS and software filesystems are backed up weekly, while the Kerberos database files are backed up on a nightly basis.
