<artwork />   <projects />   <rhetoric />   <snippets />

My Mac OS X 10.7 Kerberos Workarounds

Update: Some of this has been superseded by my new post on the subject, Mac OS X 10.7: Kerberos is Back. authAuthority does not appear to actually be required, but there is a line that must be added to /etc/pam.d/authorization.

Currently, I have Kerberos on Lion using SSH. To do this, I had to install MacPorts and then install its version of SSH. More work needs to be done. Here I’ve documented what I did to get as far as I have.

Mac OS X 10.7 switched from MIT Kerberos to Heimdal. In order to get this to work, I had to make a few changes to our setup (which is far from mature, unfortunately). If you’ve read my other posts, then you would know that our KDC is running MIT Kerberos on a RHEL 6 server. The same server is also running OpenLDAP. Our goal was to provide Kerberos tickets at login that could be used to SSH into other workstations and protect our NFS shared home directories.

The first thing I had to was to open up the right UDP ports on our KDC (88, 464, and 749). It’s possible to force Heimdal to use TCP instead, but there were a few mixed reports that suggested that it didn’t always work. It seemed easier and more straightforward to let Heimdal use its default settings rather than risk that Apple had made some undocumented tweaks that broke it.

This next part doesn’t seem to be necessary, so I’ve deleted it.
The second thing I had to do was to add authAuthority to our list of mapped LDAP attributes. authAuthority can be found in /etc/openldap/schema/apple.schema on any 10.7 install. The schema file should be added to your OpenLDAP server and the authAuthority attribute type should be uncommented. Using phpldapadmin, I first added authAuthorityObject to my user’s objectClass. Then I added a new attribute, authAuthority and set it to read ;Kerberosv5;;;REALM; (the semicolons are important), replacing REALM with our realm name. Then, using Directory Utility (the easiest way to access it is through the Users & Groups System Preferences pane, but you can find it in /System/Library/CoreServices), I navigated to our LDAP server’s “Search & Mappings” tab, drilled down under Users, and set AuthenticationAuthority on the left side to map to authAuthority on the right side. If AuthenticationAuthority isn’t listed, you can add it. Click on Users (or add it as a Record Type), click add, select Attribute Types, and find AuthenticationAuthority in the list.

A quick note: If you don’t have authAuthority stored in OpenLDAP, but you have /etc/krb5.conf already in place, it’s possible that your network accounts will be unable to log in or use sudo until you do. Deleting /etc/krb5.conf will restore logins for you if you get stuck partway through this process, but it’s better to use a local login until Kerberos is completely set up.

The third second thing to do is to add the krb5.conf file. In previous versions of Mac OS X, you had to name your config edu.mit.Kerberos and hide it in /Library/Preferences/. Lion will still look there for the sake of backwards compatibility, but I didn’t like the idea of naming my Heimdal configuration file by another name. Happily, /etc/krb5.conf is supported (and probably the preferred location going forward). I was able to use my existing krb5.conf file from my RHEL 6 server without any changes. You can read man krb5.conf to make sure your configuration file won’t give you any surprises.

The fourth third thing I had to do was to make sure to edit /etc/pam.d/authorization. This is what the login window uses to fetch your Kerberos tickets. If you open the file, you’ll see that the first line actually calls pam_krb5.so. This replaces some of /etc/authorization‘s functionality. You only need to edit this file if you want to use uids as login names instead of the fully qualified uid@REALM format, but if you append default_principal to the end of the pam_krb5.so line, you will be able to use short names to login, and it will automatically append your default REALM to the end of your login. Here’s an example:

auth       sufficient       pam_krb5.so use_first_pass use_kcminit default_principal

Further testing seemed to reveal that you might need to remove use_kcminit from the same line in /etc/pam.d/authorization:

auth       sufficient     pam_krb5.so use_first_pass default_principal

At this point, if you’re feeling brave, run killall opendirectoryd if you haven’t already, log out, and log back in as a network user account. If you have already correctly configured network user accounts with OpenLDAP, everything should just work, and when you open Terminal and run klist or open Ticket Viewer (buried in /System/Library/CoreServices), you should see a ticket for your user account with a valid expiration date!

As a final step, if you need host principals for your workstations, I had some interoperability problems between Heimdal and my MIT Kerberos KDC. The way I worked around it was to create a keytab with kadmin on a RHEL 6 workstation, copy it to the new computer, and use ktutil on the destination Mac to append it to the default /etc/krb5.keytab file that comes with Mac OS X. (I managed to really break a Lion install a while back by deleting its keytab file, and rather than risk doing that again, I decided to let the existing principals remain. Recently, however, just copying the keytab file directly from a Linux machine to /etc/krb5.keytab seems to work.) Here’s essentially what I do now for new Mac OS X computers:

  1. I log into a RHEL 6 workstation running MIT Kerberos, and log into kadminwith my admin principal:
    # kadmin
    kadmin: ktadd -k computername.keytab host/computername.domainname
    kadmin: ktadd -k computername.keytab nfs/computername.domainname

    This takes care of SSH and NFS. If your network needs other Kerberos principals on workstations, add them to the keytab at this time.

  2. I copy the file (in my case, using SSH) to the newly installed Mac. Then I (optionally) run ktutil with sudo to merge the two keytab files together. Otherwise, just overwrite /etc/krb5.keytab.
    # ktutil copy computername.keytab /etc/krb5.keytab
  3. Now that the host principals have been safely merged, I can delete the temporary keytab I’ve created.

One Response to “My Mac OS X 10.7 Kerberos Workarounds”

  1. Póg Mo Thón » Blog Archive » Mac OS X 10.7: Kerberos is Back Says:

    […] My Mac OS X 10.7 Kerberos Workarounds […]

Leave a Reply

about | blog | email | links | sitemap

Entries (RSS) and Comments (RSS).