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:

It's largely compatible with Microsoft Active Directory. It can use accounts maintained in Active Directory. Or if IPA is the primary system (as it is for Computer Science), Windows systems can get account data from it.
It stores data about users, including (encrypted) passwords, in an LDAP system. In particular, IPA uses the 389 Directory Server. This is the latest incarnation of the original LDAP code from University of Michigan. (Openldap, Netscape DS, Sun DS, and Oracle DS are based on the same code.) The big advantage of 389 is that it supports large-scale multimaster implementations. All authenticated access to LDAP uses Kerberos (through GSSAPI).
Authentication is handled by Kerberos. All operations that need authentication require the user to have a Kerberos ticket. The IPA Kerberos server stores its data in LDAP.
Access to home directories uses NFS in a mode where access is authenticated by Kerberos. Unlike most Unix systems, the privileged user (root) does not have any special rights to access home directories. Root can still access all files located on the local system. (We also have one system that does not use Kerberized NFS. That allows staff to be able to get to user files in order to help the user. That system is also used to create home directories for users.)
Two-factor authentication is supported by a free phone app (FreeOTP) and Yubikey. Because FreeOTP is standards-based, it can be used for other purposes such as two-factor authentication for Google services.
Login and other PAM functions use sssd.

This software is available for Redhat/Centos, Ubuntu, and other major distributions.

We moved to this system for several reasons:

Our old system had security problems for machines in publically-accessible areas.
We wanted to be able to allow computers where faculty and grad students have privileged accrss to be able to access our shared home directories. With Kerberos, only users who actually use the systems are at risk. With the old system, anyone having privileged access could see all files.
The technology we were using (NIS), was no longer current, and would not support Windows or Macs very well.
The old system did not integrate two-factor authentication. We supported Google authenticator, but because it wasn't integrated with the system, there were ways to bypass it. (IPA integrates two-factor authentication into the Kerberos server with a pre-authentication plugin.)

The new system should be largely invisible to users, except for the need to create a separate password for it. However this is a fairly aggressive implementaton of new technologies, and failures are possible.

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

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.

If you are using a one-time password, kgetcred doesn't work. Allowing root to issue a ticket on your behalf would obviously subvert the intention of using two-factor authentication. In this case you have two choices:

Use Google authenticator. It is checked at login, but not by cron jobs. This is slightly less secure than the builtin Kerberos support for two-factor authentication.
Write your cron job to use only files stored on the computer itself. Our systems generally have substantial local file systems which you can use for this.
Ask us for a second user ID that won't use two-factor authentication.

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 services.cs.rutgers.edu.

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

[realms]
  CS.RUTGERS.EDU = {
    kdc = https://services.cs.rutgers.edu/KdcProxy
    kpasswd_server = https://services.cs.rutgers.edu/KdcProxy
    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

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.