These are instructions for getting Kerberos to play nicely with Mac running OS X 10.8 “Mountain Lion” or newer.

The advantage to this Kerberos approach, versus joining the Mac to UW’s NetID domain, is that user accounts exist on the local system. This allows them to work on the computer even if UW Kerberos – or the network itself – is unavailable for some reason. The disadvantage is this approach requires more manual intervention per machine, since you have to create local user accounts.

First, some caveats:

  • Your local username on the Mac must be the same as your UW NetID. This will not work otherwise. Your password can be different than your UW password (in which case either password will work), and your UID doesn’t need to be the same either (it almost certainly will be different).
  • I have not got this working yet for File Sharing or Screen Sharing – you still need to use your account’s local password when connecting to those services. When I figure those out, I will update this page – but, to prevent confusion, consider suggesting that your end users set their local password to match their UW password.
  • These instructions will almost certainly not work on versions of OS X prior to 10.8 “Mountain Lion”.
  • If you try this and your system breaks – you get to keep both pieces. Fixing it is your responsibility. These changes should not be attempted by people inexperienced with either Kerberos or PAM.

One further note: You might be tempted to try this against UW’s NetID realm rather than the u.washington.edu realm I’ve used below. When I tried that, though, it did not consistently work. I have no idea why that would be the case other than, well, it’s Windows’ “Kerberos”.

When presenting edits that need to be made to existing files, the following convention will be followed. New text to be inserted will be indicated like this, and pre-existing text that needs to be deleted will be marked like this.

Pluggable Authentication Module (PAM) Changes

1) Make a copy of /etc/pam.d/authorization and put it somewhere safe, then make the following changes:

# authorization: auth account
auth      optional      pam_krb5.so use_first_pass use_kcminit default_principal
auth      sufficient    pam_krb5.so use_first_pass default_principal
auth      optional      pam_ntlm.so use_first_pass
auth      required      pam_opendirectory.so use_first_pass nullok
account   required      pam_opendirectory.so

2) Save an unaltered copy of /etc/pam.d/screensaver, then edit the original as follows:

# screensaver: auth account
auth      optional      pam_krb5.so use_first_pass use_kcminit default_principal
auth      sufficient    pam_krb5.so use_first_pass default_principal
auth      required      pam_opendirectory.so use_first_pass nullok
account   required      pam_opendirectory.so
account   sufficient    pam_self.so
account   required      pam_group.so no_warn group=admin,wheel fail_safe
account   required      pam_group.so no_warn deny group=admin,wheel ruser fail_safe

3) Back up /etc/pam.d/sudo (are you noticing a pattern here?), then edit it as follows:

# sudo: auth account password session
auth      optional      pam_krb5.so default_principal
auth      sufficient    pam_krb5.so use_first_pass default_principal
auth      required      pam_opendirectory.so
account   required      pam_permit.so
password  required      pam_deny.so
session   required      pam_permit.so

4) Make a copy of /etc/pam.d/sshd (how about now – do you see it now?), then make these changes:

# sshd: auth account password session
auth      optional      pam_krb5.so use_kcminit default_principal
auth      sufficient    pam_krb5.so use_first_pass default_principal
auth      optional      pam_ntlm.so try_first_pass
auth      optional      pam_mount.so try_first_pass
auth      required      pam_opendirectory.so try_first_pass
account   required      pam_nologin.so
account   required      pam_sacl.so sacl_service=ssh
account   required      pam_opendirectory.so
password  required      pam_opendirectory.so
session   required      pam_launchd.so
session   optional      pam_mount.so

Changes to (or creation of) /etc/krb5.conf

If UW handles DNS for the subnet you’re on, you don’t need to do any of the following – with the PAM changes above, OS X will automatically look for the Kerberos records UW has set up. We’re in EE, though, and EE currently has a Kerberos realm of its own – so EE’s DNS points to EE’s Kerberos. We want to use UW’s Kerberos, so we need to set up a file /etc/krb5.conf to point the OS in the right direction…

By default, no /etc/krb5.conf file exists on OS X – so if it doesn’t exist on your system, you’ll need to create it before you can enter this information, obviously.

The following three lines make up the entire contents of a functional /etc/krb5.conf file on a machine that will be authenticating against UW’s Kerberos realm. This obviously wouldn’t work if you wanted to allow for multiple Kerberos domains…

[domain_realm]
washington.edu = u.washington.edu
.washington.edu = u.washington.edu

Of course, if you are a control freak, here’s a different version you can use…

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = u.washington.edu
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true

[realms]

 u.washington.edu = {
  kdc = k5-kdc1.u.washington.edu
  kdc = k5-kdc2.u.washington.edu
  admin_server = k5-admin.u.washington.edu
 }

[domain_realm]
 u.washington.edu = u.washington.edu
 .u.washington.edu = u.washington.edu

Further Notes

After making these changes, users who log in with their UW password will be automatically issued a Kerberos ticket. If they log in with their local password, no ticket will be issued (that’s obvious, I hope).

Changes to PAM and Kerberos settings appear to take effect immediately – you do not need to reboot your machine after making the changes listed above.

Last updated 2017-05-16