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. Finally set up login authorization to generate tickets from the main GUI login window, to check against kerberos for permission to alter system preferences, and to check against kerberos from the screen saver. 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.
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?
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 are some examples 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.
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.4.5
The approach I've used in the past, an aklog plugin for kerberos, is at the time of this writing not available. I'm aware of three alternatives:
Option A: Ragnar Sundblad has produced an afslog plugin that works in much the same way--I've tested this against the isis.unc.edu cell briefly and it seems to work, and it should work against most AFS cells using Kerberos 5 for login. It does not work against olde school AFS/Kerberos 4 cells (such as cs.unc.edu). You should probably try this one first, but at this time it's brand new for Tiger (if you're a pioneer, you don't mind the slings and arrows of outrageous misfortune).Option B: I have hacked Ragnar's code down to a simple call to a script. This approach allows you to call a script whenever you login via kerberos--not only for getting tokens, but for other functions as well.
Option C: 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: Using the afslog plugin
- First, make a copy of your current edu.mit.Kerberos file:
sudo cp /Library/Preferences/edu.mit.Kerberos /Library/Preferences/edu.mit.Kerberos.bak- Install the afslog plugin. The command line instructions below will do the downloads for you if you just want to get through this. At the time of this writing, Ragnar's code is up at ftp://ftp.nada.kth.se/pub/home/ragge/test/, you want the afslog.loginLogout-0.0.2b2.tgz (the afslog.loginLogout-0.0.2b2-src.tgz is the source code--if you don't know what that means, you don't want it). I've also put up a copy of both the binary and the source files.
Download the plugin, and then copy it into /Library/Kerberos Plug-Ins (if the directory doesn't exist, you'll need to make it). These commands should work:cd sudo mkdir /Library/Kerberos\ Plug-Ins sudo curl -O http://www.ibiblio.org/macsupport/kerberos/10.4/afslog.loginLogout-0.0.2b2.tgz sudo gnutar -xzf afslog.loginLogout-0.0.2b2.tgz sudo cp -R ./afslog.loginLogout-0.0.2b2/afslog.loginLogout/ /Library/Kerberos\ Plug-Ins sudo rm afslog.loginLogout-0.0.2b2.tgz- Then edit 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.
- Add a line under libdefaults that calls afslog:
login_logout_notification = afslog- Add these two lines between the libdefaults section and realms:
[appdefaults]
afs-use-524 = [ yes/true/1 = server-524 | no/anythingelse = krb5 tokens ]
Here's an example edu.mit.Kerberos file I've tested against the isis.unc.edu cell.At this point, you should get afs tokens whenever you autheticate against kerberos.
Option B) Using afslogscript.loginLogout
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. Aklog is a program that comes with OpenAFS that can get an AFS token for a cell if you have a valid kerberos ticket for the associated kerberos realm.
First, use the Kerberos app from MIT to make sure you have tickets. Then in the command line type unlog to get rid of any AFS tokens you might have, followed by aklog, followed by tokens. If your aklog is working, you should see something like:gilgamesh:~ hays$ unlog 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, since I'm not assuming you have a /usr/local directory yet, but it should work
Also, everything to the right of the pound sign is just a comment, and you don't have to type it....sudo mkdir /usr/local # Create the /usr/local directory--it may already exist, don't worry if it does sudo mkdir /usr/local/bin # Likewise for /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 (as you did above in step one)
- Next, download a script to get tokens via aklog, and then tell the system to call that script when you login.
sudo curl -o /usr/local/bin/afslogscript.loginLogout.sh \
http://www.ibiblio.org/macsupport/kerberos/10.4/afslogscript.loginLogout.sh sudo chmod a+x /usr/local/bin/afslogscript.loginLogout.sh- Check the permissions on this file, you want to make sure that it's only writable by root.
gilgamesh:~ hays$ ls -l /usr/local/bin/afslogscript.loginLogout.sh total 16 -rwxr-xr-x 1 root admin 727 Apr 4 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 /usr/local/bin/afslogscript.loginLogout.shIf you get tokens, you should be able to use this as part of the login sequence.
- Now, install the plugin module that calls this script on login.
cd sudo mkdir /Library/Kerberos\ Plug-Ins sudo curl -O http://www.ibiblio.org/macsupport/kerberos/10.4/afslogscript.loginLogout-0.0.1b2.tgz sudo gnutar -xzf afslogscript.loginLogout-0.0.1b2.tgz sudo cp -R ./afslogscript.loginLogout-0.0.1b2/afslogscript.loginLogout /Library/Kerberos\ Plug-Ins sudo rm afslogscript.loginLogout-0.0.1b2.tgz
Option C) 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 (also, everything to the right of the pound sign is just a comment, you don't have to type it, but it won't hurt either).
sudo mkdir /usr/local # Create the directory--it may already exist, don't worry if it does sudo mkdir /usr/local/bin # Likewise for /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 root admin 727 Apr 4 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 havesudo /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 LoginHookWhat 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 tookAt 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.
Thanks to Helen Rose at MIT for suggestions for the /etc/authorization settings, to Mike Bydalek for the login afs script, to Chaskiel Grundman at CMU for the aklog binaries, and many thanks to Ragnar Sundblad at KTH for suggestions and the afslog software.