Macs at home; part 7: AFP vs NFS

Filed under: Geekiness — iain @ 20:47:31

See the introduction to this post.

It’s been an eventful day which started and ended with frustration but finishes with a greater understanding of network home directories, a working AFP server and cleartext passwords finally banished.

I sent my fileserver down for reboot to install the latest Linux kernel. At this point my iMac, on which I had a desktop session, became very very upset. My home directory is NFS mounted and when the server went away the client became totally unusable. Even when the server came back up it wouldn’t re-establish the mounts.

UNIX machines traditionally tend to choke when NFS servers go away but the Mac automounter absolutely refused to come back to life and I had no option but the reboot the machine. I wondered if AFP home directories would be more reliable.

It turns out they are but there’s a fatal flaw. An ssh connection to the machine won’t mount the AFP home which means they’re only useful for a desktop session. At least I did get them working though.


The netatalk software suite contains the AFP server afpd and it was actually very simple to set up. Two config files were all that were needed.


    - -noddp -uamlist uams_dhx_pam.so,uams_gss.so \\
      -k5service afpserver -k5keytab /etc/krb5.keytab \\
      -k5realm IAIN.CX -fqdn files.iain.cx:548


    ~ "home" adouble:v2

The only daemon that needs to be started is afpd which, with the above configuration, advertises a share called home which maps to the connecting user’s home directory.

The prerequisites for this are a working /etc/pam.d/netatalk configuration and an entry in /etc/krb5.keytab for afpserver/files.iain.cx. Users can then authenticate either with PAM (passing a username and password) or Kerberos.

LDAP configuration

Users need an apple-user-homeurl entry (mapped to HomeDirectory in DirectoryService) of the form:


For example:


They still need the apple-user-homeDirectory entry which refers to where the share will be mounted. If NFS automounts are in use (as they are in my network) you can’t reuse /Network/Servers so /home/username is a good choice (it will be automatically created as needed). This, I suppose, is why the default LDAP mappings have NFSHomeDirectory in DirectoryServices mapping to homeDirectory in LDAP…

Plaintext passwords banished

You may recall that I stated that passwords needed to be stored in plaintext because Mac clients tried a CRAM-MD5 bind to the directory server in order to validate a user’s logon credentials.

This is actually a fallback. The clients first attempt to authenticate with Kerberos. The only problem was that I’m using the Heimdal implementation because of its seamless integration with Samba and by default principals are not allowed to get proxiable tickets. I tried setting proxiable = false in /Library/Preferences/edu.mit.Kerberos but this flag was not honoured (although it is if you run kinit on the command line).

Heimdal is great because if you tell it you are joebloggs it looks for a user in LDAP with the sambaSamAccount objectClass and compares the password you provide against the NTLM credentials stored for that user. Effectively this means that you get Kerberos for free when you set up Samba with an LDAP backend.

But if you don’t also add the krb5KDCEntry objectClass you won’t be able to change the principal’s flags which means that the default disallow-proxiable flag will be set for the user and when the Mac comes along and asks for a proxiable ticket the request will be denied. You won’t be able to log on even though you got the right password. And then the Mac tries CRAM-MD5 instead.

The fix was to add some attributes to my user entries.

    dn: cn=iain,ou=users,dc=iain,dc=cx
    objectClass: krb5KDCEntry
    krb5PrincipalName: iain@IAIN.CX
    krb5KeyVersionNumber: 1
    krb5KDCFlags: 70

krb5KDCFlags=70 happens to be the default set of flags minus disallow-proxiable.

Now I can authenticate with Kerberos and I don’t need to store my passwords in plaintext. Hurrah.


  1. Reestablishing NFS mounts works for me under Mac OS X. Are you using NFS over UDP or TCP? I’m using UDP which is for some weird reason faster with Mac OS X clients.

    Comment by Tron — 2007-09-17 @ 06:53:57

  2. I had to go and double check because I remember you writing in your blog about your problems with TCP but I definitely did specify TCP in the mount options for the Linux clients.

    Turns out I had the default settings, which is UDP.

    I’m trying now with TCP after the iMac locked up again.

    Comment by iain — 2007-09-26 @ 16:20:31

RSS feed for comments on this post.

Leave a comment

You must be logged in to post a comment.

Powered by WordPress