Kerberos

We use MIT Kerberos 5 for authentication. Our kerberos realm is CSCLUB.UWATERLOO.CA. KDCs run on auth1 (kdc1) and artificial-flavours (kdc2).

Running Kerberos Locally

It is possible to run Kerberos on your own personal computer in order to obtain login tickets for CSC machines (i.e. single sign-on over SSH). On Debian/Ubuntu, install the 'krb5-user' package. Then edit /etc/krb5.conf (as root) as follows:

• Under the [libdefaults] header, add these lines:
  • default_realm = CSCLUB.UWATERLOO.CA
  • forwardable = true
  • proxiable = true
• Under the [realms] header, add these lines:
  • CSCLUB.UWATERLOO.CA = {
  • kdc = kdc1.csclub.uwaterloo.ca
  • kdc = kdc2.csclub.uwaterloo.ca
  • admin_server = kadmin.csclub.uwaterloo.ca
  • }

Then, when you want to SSH into a CSC machine, run "kinit" from the command line. Kerberos will ask you for your CSC password. After that, you should be able to SSH into any CSC machine without typing your password or public key!

Note that this method of access is required to log in to some of our servers, such as potassium-nitrate.

Password Resets

To change your own password you can run passwd on any of the club's machines.

Changing other users' passwords

• ssh auth1
• sudo kadmin.local
• cpw username
• Enter new password and confirm

API Documentation. While not even close to enough to let you do most things that you'd want to do with Kerberos (and also being somewhat woefully out-of-date, considering it's from 1996), it's at least a start.

Expiring Passwords

If you are on syscom, you can force a user to change their password by doing this:

• ssh auth1
• sudo kadmin.local
• modify_principal +needchange [username]

Suspending an Account

If you are on syscom, you can prevent a user from logging with a Kerberos ticket by doing this:

• ssh auth1
• sudo kadmin.local
• modify_principal -allow_tix [username]

If you are seriously locking out an account, you may want to do some other things as well, including but not limited to changing the user's password (prevents password login) and changing the ownership and permissions on .ssh/authorized_keys* (prevents SSH key login). Don't do these things without a strong reason (but know how to do them when the time comes).

bofh's Kerberos5 cheat sheet, or "what does *that* error message mean, exactly?"

• If GSSAPI complains about "Wrong Principal in Request", make sure there's no clockskew on the machine trying to get the service ticket and the machine running the service that you are trying to get a GSS token to. This will cause this error for some insane reason, despite there being ANOTHER message for clockskew that specifically says "your clocks are off" - it just never seems to be used in the source code anywhere (as of MIT-KRB5 1.9, at least).
• There are some "generic" errors that are hard to debug. A few possible causes: unreadable krb5.keytab, reverse resolution of a host does not match its principal.