OK, so this was a real PITA to figure out, and I didn’t find a great deal of help in Google so I’m going to write a short post about doing this, both so I can find it in future and so that other people can benefit from what I discovered.
So, the first thing to do is to make sure that you have a working Kerberos set-up. To check this, you can try
$ kinit some-user
Please enter the password for some-user@EXAMPLE.COM:
If it successfully authenticates when given the name of a user in your Open Directory set-up, you’re all set. You can, if you like, look at the Kerberos ticket you just gained by using the klist command, but if kinit worked then there’s probably no need. If, on the other hand, that kinit didn’t work, you need to re-configure Kerberos from scratch. This seems to be very hit and miss and often it’s easier to reconfigure Open Directory from scratch instead, but that’s a bit drastic and is only really practical for smaller set-ups because it tends to result in all the passwords getting reset.
If your Kerberos isn’t working, please don’t bother asking me about it. I have yet to find a reliable sequence of commands to completely re-initialise it on OS X Server. You might find AFP548.com useful if you’re in this sort of mess.
Next, make sure that your client machines are configured to authenticate using Kerberos. On OS X 10.5, that means editing /etc/authorization to change
<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.</string>
<key>mechanisms</key>
<array>
<string>builtin:smartcard-sniffer,privileged</string>
<string>loginwindow:login</string>
<string>builtin:reset-password,privileged</string>
<string>builtin:auto-login,privileged</string>
<string>builtin:authenticate,privileged</string>
<string>HomeDirMechanism:login,privileged</string>
<string>HomeDirMechanism:status</string>
<string>MCXMechanism:login</string>
<string>loginwindow:success</string>
<string>loginwindow:done</string>
</array>
</dict>
to
<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.</string>
<key>mechanisms</key>
<array>
<string>builtin:smartcard-sniffer,privileged</string>
<string>loginwindow:login</string>
<string>builtin:reset-password,privileged</string>
<string>builtin:auto-login,privileged</string>
<string>builtin:krb5authnoverify,privileged</string>
<string>HomeDirMechanism:login,privileged</string>
<string>HomeDirMechanism:status</string>
<string>MCXMechanism:login</string>
<string>loginwindow:success</string>
<string>loginwindow:done</string>
</array>
</dict>
That isn’t the only way to go about this part, but you need to make sure that your users get a Kerberos ticket automatically somehow. If they don’t, they won’t be able to mount the static automount because the server won’t recognise them. See Article 107154: Enabling Kerberos authentication for Login Window on Apple’s site, but note that the part where it says that the information is not required as of OS X Server 10.3 is not, in fact, entirely true. Various universities set things up using Kerberos and some of their pages may also be helpful; I quite like Iowa State’s page, personally.
Next, set-up your shares using Server Admin, setting the Custom mount path setting as required. For instance, I set one up with the path /Network/Groups. On previous versions of Mac OS X, you could do this step from Workgroup Manager, which was useful because it meant you could manually edit the mount URL to remove the hard-coded “;AUTH=NO USER AUTHENT” setting. Unfortunately you can no longer do this as of 10.5, which means that you have to use dscl or the various LDAP utilities.
Even more unfortunate, when I tried to edit with dscl, I just got the error message
*** Uncaught Exception: ([DSoDataNode initWithDir:value:] value is not a valid NSString nor NSData)
(and yes, I’m certain I used the right command). As a result, I ended up making myself a file like this (I called mine groups.ldif):
dn: cn=server.example.com:/Volumes/SomeVolume/Groups,cn=mounts,dc=server,dc=example,dc=com
replace: mountOption
mountOption: url==afp://server.example.com/Groups
and then I did
$ kinit diradmin
Please enter the password for diradmin@EXAMPLE.COM:
$ ldapmodify -f groups.ldif
The first line is just to authenticate as the directory administrator—you only need to do that once. If you need to examine your LDAP mount records first, you can do something like this:
$ ldapsearch -b "cn=mounts,dc=server,dc=example,dc=com"
which will list all of the mount records.
One other useful tidbit is that if you’re trying to test this from a client machine, you can do
$ sudo automount -v
from Terminal to refresh the automount set-up on the client.
It all sounds so simple written down, but this took me a good few hours and a lot of frustration. Hopefully I’ve saved someone else (or even just myself, in future) from repeating that experience.