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