Kerberos/AFS Login Additions to OS X 10.5

Caveats: this worked for me, but your mileage may vary. Be careful. You should always have a backup.

OSX uses MIT's kerberos, so what we're going to do is install some bits from MIT, configure kerberos for our domain, then install some software to get afs tokens. Then we'll install a preference pane for OSX that will help manage tickets and tokens. In all of these cases, authentication is supposed to fall back to local authentication if kerberos fails, so this should be safe for laptops. It's working ok for me on mine, but I suggest you try one feature at a time. Also, make sure you get the latest stable release of OpenAFS before playing with these.

If you're interested in more complex setups, Penn State has some good documentation on configuring OS X for kerberos authentication.

Step 1: Install MIT's kerberos extras package

You can get MIT's Kerberos Extras from:

http://web.mit.edu/macdev/KfM/Common/Documentation/osx-kerberos-extras.html

Installation of this will enable kerberos support for Carbon applications, and set up a sample kerberos configuration file. It's really an optional step, but why not?

Step 2: Configure Kerberos

Once it's installed, go to /Library/Preferences and find the edu.mit.Kerberos file. As root, or using sudo, make a backup, then open this file with a text editor (eg. vi, pico, BBEdit). For default realm, use your main kerberos realm. If you're in a Kerberos4 realm, add the data in the "v4" sections. For more detailed information, see the MIT Kerberos for OS X preferences and faq pages.

Since there's a lot of variation in what you can do with this file, you should contact your site's IT group to see what values they recommend. Here is an example of an edu.mit.kerberos file set up for the CS kerberos realms and the main UNC Chapel Hill realm (ISIS) to get you started if you want to press on on your own. These files are slightly different than the ones for 10.2 and 10.3

Save the file. You will have to logout and log back in to test it, but a reboot shouldn't be required

Once you're logged back in, look in /Applications/Utilites for the Kerberos application--the MIT extras install puts an alias to this where you can find it, instead in CoreServices. Open this, and go to Edit, Edit Favorite Realms, and add the realms you use.

Once you've done that, you should be able to use the main window to get kerberos tickets.

So far so good--now you should be able to use applications that know how to use kerberos. At UNC, that doesn't mean much, since we don't use kerberos all that much and most applications aren't kerberized. But this does lay the groundwork for the next step, which is automatically getting AFS tokens for access to your online file space.

Step 3: Enable Kerberos authentication at login and screensaver

From a terminal window, su to root or use sudo to make a back up of your authorization file.

sudo cp /etc/authorization /etc/authorizaton.orig

The reason for this is that if you mess up the /etc/authorization file, you may not be able to login to your machine. If this happens:

  • Boot into single user mode by holding down command-s on boot
  • Follow the instructions to fsck and mount the main partition
  • Then use copy your modified file to something safe so you can look at it: cp /etc/authorization /etc/authorization.bad
  • Copy your original file back into place: cp /etc/authorization.orig /etc/authorization

Type exit, and you should be able to login as before

Then, open the authorization file in the text editor of your choice (in this example, I'm using vi, but pico would work fine, too):

sudo vi /etc/authorization

Find the <key>authenticate</key> section in /etc/authorization:

<key>authenticate</key>
<dict>
<key>class</key>
<string>evaluate-mechanisms</string>
<key>mechanisms</key>
<array>
<string>builtin:authenticate</string>
<string>authinternal</string>
</array>

And add a line, <string>builtin:krb5authnoverify,privileged</string> to the mechanisms array:

<key>authenticate</key>
<dict>
<key>class</key>
<string>evaluate-mechanisms</string>
<key>mechanisms</key>
<array>
<string>builtin:authenticate</string>
<string>builtin:krb5authnoverify,privileged</string>
<string>authinternal</string>
</array>

 

Next, either use option A. (For Public Use Desktops) or option B. (For Single User Desktops and Laptop users)

Option A. For Public Use Desktops

This method is best for public use machines with multiple users, since you can authenticate without having a local account. Fair warning! If you do this, and the network is down, your machine will hang briefly after you type your password as it tries to login to the kerberos system. I do not recommend this modification for laptops, it can be really irritating. See the alternate modification for laptops below.

Find the <key>system.login.console</key> section in /etc/authorization

<key>system.login.console</key>
<dict>
<key>class</key>
<string>evaluate-mechanisms</string>
<key>comment</key>
<string>Login mechanism based rule. Not for general use, yet.
builtin:krb5authenticate can be used to hinge local
authentication on a successful kerberos authentication
and kdc verification. builtin:krb5authnoverify skips
the kdc verification. Both fall back on local authentication.
</string>
<key>mechanisms</key>
<array>
<string>builtin:auto-login,privileged</string>
<string>loginwindow_builtin:login</string>
<string>builtin:reset-password,privileged</string>
<string>authinternal</string>
<string>builtin:getuserinfo,privileged</string>
<string>builtin:sso,privileged</string>

Add <string>builtin:krb5authnoverify,privileged</string> to the mechanism's array:

<key>system.login.console</key>
<dict>
<key>class</key>
<string>evaluate-mechanisms</string>
<key>comment</key>
<string>Login mechanism based rule. Not for general use, yet.
builtin:krb5authenticate can be used to hinge local
authentication on a successful kerberos authentication
and kdc verification. builtin:krb5authnoverify skips
the kdc verification. Both fall back on local authentication.
</string>
<key>mechanisms</key>
<array>
<string>builtin:auto-login,privileged</string>
<string>loginwindow_builtin:login</string>
<string>builtin:krb5authnoverify,privileged</string>
<string>builtin:reset-password,privileged</string>
<string>authinternal</string>
<string>builtin:getuserinfo,privileged</string>
<string>builtin:sso,privileged</string>

Here's an example I've tested.

Option B. For Single User Desktops and Laptop users

Find this section in /etc/authorization

<key>system.login.done</key>
<dict>
<key>class</key>
<string>evaluate-mechanisms</string>
<key>comment</key>
<string>builtin:krb5login can be used to do kerberos
authentication as a side-effect of logging in.
Local username/password will be used.</string>
<key>mechanisms</key>
<array/>

And change it to the version below. Note that you not only add the <string>builtin:krb5login,privileged</string>, but also bracket it with <array> and </array> (you don't want <array/> in the new version!)

<key>system.login.done</key>
<dict>
<key>class</key>
<string>evaluate-mechanisms</string>
<key>comment</key>
<string>builtin:krb5login can be used to do kerberos
authentication as a side-effect of logging in.
Local username/password will be used.</string>
<key>mechanisms</key>
<array>
<string>builtin:krb5login,privileged</string>
</array>

Here's an example that I use on my machine.

If you mess up your authorization files, and need to start from scratch, here's a copy of the one that was installed on my desktop as part of 10.5

To test this, use the kerberos extras app to destroy any tickets you have, then restart the machine. Once you're logged in, check the kerberos extras app to see that you have a ticket in your default realm. This should also get you a ticket when you login to the screen saver.

Step 4: Getting AFS Tokens from Kerberos Tickets

The approaches I've used in the past, an aklog plugin for kerberos, and Ragnar Sundblad's afslog plugin, no longer work at the time of this writing not available. I'm aware of two alternatives:

Option A: Claudio Bisegni has written a Systems Preferences Pane called AFS Commander, this will let you control AFS via the GUI, and can use a kerberos ticket to call aklog to get AFS tokens when you login to the console. It will not get you tokens when you log in via the screen saver, but if you're getting a kerberos ticket via the screen saver, you can use it's menu item to easily get a ticket.

Option B: Or, we can kludge things a bit, by using a LoginHook to a script. This is not as elegant, since it cannot be tied to the screen saver, and if you're using afs as your OS X home directory, that can be a problem (since your token may expire before you can renew them). Also, it is very important that the script be able in all cases to exit with a status of 0, otherwise login may hang.

I suggest you try these one at a time in the order listed, and stick with the first one that works for you....

Option A: AFS Commander

This is very straight forward, download the software and double click on it to install. It's best to install it for all users. After it's installed, you can go to System Preferences. Assuming you've gotten afs and kerberos integrated, all you now need do is enable use of aklog and to get credentials on login. The latter will install a launch daemon process that will get you an afs token when you first login. You probably will also want to enable the AFS menu option, this will allow you to get tokens (if you have kerberos tickets) from the menu bar. Here's a screen shot of the relevent settings:


AFS Commander Settings

Option B)Using aklog from a script as a login hook

First, check your edu.mit.Kerberos file--if you have a login_logout_notification = "aklog"line in the libdefaults like that used for 10.3, delete it--generally, it doesn't cause any problems, but it will interfere I think with the login hook we're trying.

Check to see if you have a working aklog. Use the Kerberos app from MIT to make sure you have tickets, and then in the command line type aklog, followed by tokens. If your aklog is working, you should see something like:

gilgamesh:~ hays$ aklog
gilgamesh:~ hays$ tokens

Tokens held by the Cache Manager:

User's (AFS ID 4726) tokens for afs@cs.unc.edu [Expires Apr  4 13:52]
 --End of list--
gilgamesh:~ hays$
 

If it doesn't work, it may be that your cell uses kerberos 4 instead of kerberos 5. In that case you should try downloading the kerberos 4 compliant aklog binary for 10.4. Now, I was taught to try to keep the stuff I do independently out of the directories used by the system and installers. The aklog installed by Openafs goes into /usr/bin. So I suggest is that you install this binary in /usr/local/bin, as well as any other software that you build or install manually. This is a brute force kind of way to do this, but it should work.

sudo mkdir /usr/local 
sudo mkdir /usr/local/bin 

sudo curl -o /usr/local/bin/aklog \
http://www.ibiblio.org/macsupport/kerberos/10.4/aklog4-Tiger.bin
sudo chmod a+x /usr/local/bin/aklog

If this went ok, from the command line try typing /usr/local/bin/aklog (you need to specify the exact path to make sure you're running the right version!) and see if you can get afs tokens from your kerberos ticket.

Next, we'll make a directory called Scripts for you to store a login script, download a script to get tokens via aklog, and then tell the system to call that script when you login. This script is from Mike Bydalek with some very minor modifications:

sudo mkdir /Applications/Scripts # make the directory
sudo curl -o /Applications/Scripts/login.sh \
http://www.ibiblio.org/macsupport/kerberos/10.4/afs-login.sh
sudo chmod a+x /Applications/Scripts/login.sh

Very important: check the permissions on this file, you want to make sure that it's only writable by root (this script will run as root, so if you're not careful who can write to it, you could wind up with a hacked system).

gilgamesh:~ hays$ ls -l /Applications/Scripts/
total 16-rwxr-xr-x 1 rootadmin727 Apr4 14:04 login.sh

You can test this from the command line (make sure you have kerberos tickets first, and you have to tell the script what your userid is!):

unlog # first kill any tokens you might have

sudo /Applications/Scripts/login.sh YourUserIDHere

To do this, you'll reference this script in a login hook, but first we'll also check to see that you don't already have a login hook set.

sudo defaults read com.apple.loginwindow LoginHook

What you want to get from this is "The domain/default pair of (com.apple.loginwindow, LoginHook) does not exist". If you get an association listed, that script is already being used as a login hook. So you could call the one you just downloaded from that script, or merge the two, but you don't want to go onto the next step without figuring out what you'd be replacing.

To add the script as a login hook, type:

sudo defaults write com.apple.loginwindow LoginHook '/Applications/Scripts/afs-login.sh'
sudo defaults read com.apple.loginwindow LoginHook # verify that the association took

At this point, you should be able to kill all of your tickets and tokens, logout, and you should get tickets and tokens while logging in via the console.


Last modified: 06 March 2010