Account Management

Computer Science Department user administration tools

Computer Science is currently using a set of administrative tools based on IPA. IPA is an open-source package maintained by Redhat and others. It has the following major characteristics: This software is available for Redhat/Centos, Ubuntu, and other major distributions.

We moved to this system for several reasons:

The use of Kerberos should be largely invisible to users, except for the need to create a separate password for it.

In order to maintain access to your files, you need an active Kerberos ticket. This will be issued automatically by sssd when you login. If you ssh between systems, the ticket will be passed automatically to the new system. Our tickets last a day (by default). There's a background process (renewd) that automatically renews the ticket as long as you're logged in. It will also remove your ticket when you logout. (We do not recommend using kdestroy in .logout or .bash_logout, because that will cause trouble if you're still logged in with a second session.)

The major risk is that we will have overlooked something, and your ticket will expire. You can check for this using the klist command. It will list your current Kerberos ticket. Please report any cases where you don't get a ticket on login, or it expires while you're still logged in. You can create a ticket manually using the kinit command. (If you're using two-factor authentication, you'll need to use skinit instead.) Note that tickets created by kinit are not renewed or destroyed automatically.

Note that we've had to "wrap" ssh with our own code. For that reasons, paths are set so that you get /usr/local/bin/ssh, not /usr/bin/ssh. If you use the wrong ssh, you will probably get a warning message tell you that your ticket is likely to expire. See below for details.


Cron jobs are a special problem. Since you're not logging in, sssd won't be called to generate a Kerberos ticket. To deal with this, we've created a special system to authorize cron jobs. You must use the command kgetcred -r on any system where you're going to use cron. It authorizes cron (actually root) to create a ticket on your behalf. This slightly lowers your security, since anyone who can compromie the security of the system can get a ticket on your behalf. To limit exposure, the tickets created for cron can't be forwarded to other systems by ssh.

You may wonder why we require you to register with kgetcred. One goal of the new system is to make sure that root can't access your files unless you've authorized it. Root can create a cron job for anyone. If cron jobs could access files without authorization, then root could get to your files just be creating a cron job to do it. So we need you to verify that root is allowed to start cron jobs for you on that system.

Using Kerberos at Home

Currently we don't allow connections to the Kerberos system from outside computer science. However you can still use it at home through a proxy at

To use a proxy, on your home machine the realms section of /etc/krb5.conf should look like this:

    kdc =
    kpasswd_server =
    pkinit_anchors = FILE:/etc/ipa/ca.crt
    http_anchors = FILE:/etc/ipa/ca.crt
/etc/ipa/ca.crt should be copied from any of the ilab systems. The file can be located anywhere, as long as you adjust the name appropriately in the configuration. Note that with the proxy, noaddresses must be true in the libdefaults section. (Or the noaddresses specification can be omitted, since true is the default.)

The proxy doesn't appear to work on the MacOs implementation of Kerberos. Neither does two-factor authentication. We suggest installing the kerberos5 package from Macports.

This proxy server should be compatible with the MS-KKDCP KDC Proxy used by Microsoft. However we haven't tried it. If you want to use Kerberos on Windows at home I recommend installing MIT Kerberos for Windows.


Ssh has a problem resulting from how the Kerberos libraries work. Ssh forwards your Kerberos ticket to the new system. However the lifetime of the new ticket can be short.

Suppose you login at 10am. You'll get a ticket that's valid until 10am the next day. Now at 9:30 the next day you ssh to another system. The way ticket forwarding works, the new ticket has the same end time as the original one, but it starts now. That means that the ticket on the new system will start at 9:30 and end at 10am, i.e. it will have a lifetime of only 30 min. Of course if you ssh at 9:50 you could get a ticket with 10 min lifetime.

To fix this, we insert a special library into ssh using LD_PRELOAD. It will cause the ticket to be renewed on the source end before running ssh. So if you ssh at 9:30 you'll start with a newly renewed ticket going from 9:30 to 9:30 the next day.

Other solutions have been proposed for this problem. But the others we know of all fail in some situations, particularly cases where you leave a job running in the background and logout.