Illegitimi non carborundum


Integrating Login and Home Directory on OS X Leopard Clients

I've recently been dabbling in OS X related stuff. One of the things that is important to me is ensuring that my login details and users can use the OS X machine just the same as any other. Not that I really have any need for this, seeing as I'm pretty much the only user, but I like to learn these things 🙂So I've been using LDAP for a while (again, just because I can) and so I figured configuring login details would be easy. Well it's not totally easy, but it's also not too hard. One of the first things is that the default LDAP schemas etc. on Mandriva are probably a little old fashioned these days. It seems Apple and others are pushing ahead with RFC2307 spec for user accounts etc. The good news is that it seems pretty easy to support this with a few minor modifications.

Configuring OpenLDAP on Mandriva 2009.1

First up, install the openldap-extra-schemas package. This contains the apple.schema needed to make things work. This schema builds on the outdated samba (2) schema which is now sadly replaced with an updated version for samba3. I guess this will change in the future but for the time being, I hacked up the necessary attribute definitions into a schema that I included prior to the apple one. Here are the changes I made to the default /etc/openldap/slapd.conf file:

--- etc/openldap/slapd.conf	2009-07-27 16:22:58.000000000 +0100
+++ /etc/openldap/slapd.conf	2009-07-25 15:58:56.000000000 +0100
@@ -15,11 +15,11 @@
 include	/usr/share/openldap/schema/krb5-kdc.schema
 include /usr/share/openldap/schema/kerberosobject.schema
 include	/usr/share/openldap/schema/misc.schema
-include	/usr/share/openldap/schema/nis.schema
+#include	/usr/share/openldap/schema/nis.schema
 include	/usr/share/openldap/schema/openldap.schema
-include /usr/share/openldap/schema/autofs.schema
+#include /usr/share/openldap/schema/autofs.schema
 include /usr/share/openldap/schema/samba.schema
-include /usr/share/openldap/schema/kolab.schema
+#include /usr/share/openldap/schema/kolab.schema
 include /usr/share/openldap/schema/evolutionperson.schema
 include /usr/share/openldap/schema/calendar.schema
 include /usr/share/openldap/schema/sudo.schema

As you can see, nis, autofs and kolab schemas have all been disabled. Both nis and autofs are covered in RFC2307. I only disabled kolab as it builds on some of the definitions of those other two and thus caused errors on startup. I don't use kolab so this isn't a problem. It is no doubt quite simple to fix these errors.

As I like to keep changes to system config files to a minimum I didn't changes things much ore than that. There is a file, /etc/openldap/schemas/local.schema in which I did the real work. Here is the contents of that file:

# This is a good place to put your schema definitions
include /home/setup/ldap/schemas/mozilla.schema

# (cg) This schema is needed for OSX Automount integration.
# In order to activate it, you need to disable:
#  o nis.schema
#  o automount.schema
#  o kolab.schema
include /usr/share/openldap/schema/rfc2307bis.schema

include /etc/openldap/schema/pre-apple.schema
include /usr/share/openldap/schema/apple.schema

The rfc2307bis and apple schemas are part of the openldap-extra-schemas package mentioned above. The pre-apple one is one I crafted myself based on comments on other blogs and due to the fact our samba schema is now version three. Here is my pre-apple.schema file:

#ident $Id: apple.schema,v 1.42 2005/01/27 23:40:38 jtownsen Exp $
# Preliminary Apple OS X Native LDAP Schema
# This file is subject to change.

# (cg) Some definitions needed prior to including the apple.schema
# See:
# Both the below sections are included (but commented) in the official
# apple.schema in the openldap-schemas-extra package.

# ===== From (historical) samba.schema

## Account flags in string format ([UWDX     ])
attributetype ( NAME 'acctFlags'
 DESC 'Account Flags'
 EQUALITY caseIgnoreIA5Match

## Password timestamps & policies
attributetype ( NAME 'pwdLastSet'
 DESC 'NT pwdLastSet'
 EQUALITY integerMatch

attributetype ( NAME 'logonTime'
 DESC 'NT logonTime'
 EQUALITY integerMatch

attributetype ( NAME 'logoffTime'
 DESC 'NT logoffTime'
 EQUALITY integerMatch

attributetype ( NAME 'kickoffTime'
 DESC 'NT kickoffTime'
 EQUALITY integerMatch

attributetype ( NAME 'pwdCanChange'
 DESC 'NT pwdCanChange'
 EQUALITY integerMatch

attributetype ( NAME 'pwdMustChange'
 DESC 'NT pwdMustChange'
 EQUALITY integerMatch

# string settings
attributetype ( NAME 'homeDrive'
 DESC 'NT homeDrive'
 EQUALITY caseIgnoreIA5Match

attributetype ( NAME 'scriptPath'
 DESC 'NT scriptPath'
 EQUALITY caseIgnoreIA5Match

attributetype ( NAME 'profilePath'
 DESC 'NT profilePath'
 EQUALITY caseIgnoreIA5Match

attributetype ( NAME 'userWorkstations'
 DESC 'userWorkstations'
 EQUALITY caseIgnoreIA5Match

attributetype ( NAME 'smbHome'
 DESC 'smbHome'
 EQUALITY caseIgnoreIA5Match
 SYNTAX{128} )

# user and group RID
attributetype ( NAME 'rid'
 DESC 'NT rid'
 EQUALITY integerMatch

attributetype ( NAME 'primaryGroupID'
 DESC 'NT Group RID'
 EQUALITY integerMatch

# ==== From (commented out) apple.schema

# Authentication authority attribute
attributetype (
 NAME 'authAuthority'
 DESC 'password server authentication authority'
 EQUALITY caseExactIA5Match
 SUBSTR caseExactIA5SubstringsMatch

# ACL object attributes
attributetype (
 NAME 'apple-acl-entry'
 DESC 'acl entry'
 EQUALITY caseExactMatch
 SUBSTR caseExactSubstringsMatch

So with all that done, I was able to restart my LDAP server without any errors. That is not to say that the data in it is any good, but it seemed to work for me. I've not tried creating new users etc yet tho', so problems could come out of the woodwork yet!

Configuring OS X For LDAP Authentication

This topic is really rather well covered already but it's actually very trivial. Just use "Directory Utility" to add the remote server, First off Show the Advanced controls and create an LDAPv3 definition for your server and select the RFC2307 mappings. I didn't do any custom mappings on top of this. I just left everything as default. Once you've done this you can just add your server as a new source and everything should work. You can verify by using the command "id" on the terminal. Just pass in an LDAP username and it should give you their details.

Quite simple so far huh? Well that is half the story. The second part is mounting the home directory.

Mounting Home Directory via LDAP Provided AutoFS Information

Big thanks go to Rajeev Karamchedu for his excellent series of posts on this topic. The information he gives is pretty much bang on. The most important part is about using the new autofs schema (three options are given in the Mandriva autofs package, but Apple only supports one), and the fact that the definition must live at the base dn. This is annoying as I'd rather it lived inside ou=Mounts but such is life. Hopefully Apple will support this in due course. One important deviation from Rajeev's post (and I'm not sure if this is just due to newer versions of OS X) is that I could not use the automountKey=/ syntax for defining my home directories. I had to use * in place of / This makes sense as it is the default wildcard for just about everything, but it's still a deviation.

You should also make sure that the "insecure" option is added to the /etc/exports file on the NFS server. OS X mounts come from a port number > 1024, so this option is needed. In a private network it's not really insecure as the name suggests, so don't loose too much sleep over it 🙂 I'd recommend testing a manual NFS mount first. In actual fact, I would strongly recommend this as I found a rather annoying infinite loop in the autofs stuff. It continually tried to mount /home/.DS_Store over and over when I didn't have the insecure option set. I'm not sure why it did this, but I had to kill automountd to stop it.


So things work. It wasn't all that hard, and now I have login and auth for my network users on OS X. I've not tried getting autofs working again with Linux clients with the new structure imposed by OS X. It does support the structure, but I'm not sure if the location (e.g. not under ou=Mounts) or the wildcard will cause proplems (for the former it's configurable on Linux so shouldn't be a problem).

Apple could do better with their LDAP lookup (e.g. support a search base!), but all in all it's pretty good.

Thanks go to Matt Flemming and Rajeev Karamchedu for their excellent writeups. Hope this regurgitation helps some people in similar situations.

Share and Enjoy:
  • Digg
  • StumbleUpon
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks
  • Slashdot
  • Pingback: Integrating Login and Home Directory on OS X Leopard Clients … | I AM OSX()

  • Buchan

    I have only ever briefly had an Apple machine available to test with, and unfortunately, that was while I was trying to pack up and move to a different country. Without any apple-specific schemas on my Mandriva OpenLDAP server, I could log in to the machine via ssh with an LDAP account, but I could not see LDAP users on the login screen.

    However, I have some comments …

    “One of the first things is that the default LDAP schemas etc. on Mandriva are probably a little old fashioned these days.”

    Well, RFC2307bis is an expired draft, and samba doesn’t actually support RFC2307bis (DN-valued group member attributes), so by default we ship RFC2307 (e.g., in openldap-mandriva-dit), but provide the RFC2307bis schema as well. As such, I haven’t tested RFC2307bis myself (samba testing is too important), or added support for it in our tools.

    Please note, you seem to have used “RFC2307” to refer to “RFC2307bis” in some places, please be careful to note the difference.

    Can you confirm whether RFC2307bis is *really* required.

    BTW, Mac clients seem to be a bit brain-dead, they often keep re-trying the same searches that seem to be useful for configuration, even when they are configured.

  • Ed

    Are your mac os clients using the actual NFS home directories or are you syncing using portable home directories (PHDs)?

    If your NOT using PHDs do your mac os clients have the delete immediately problem when using the trash can? And do you get the resource forks artefacts dotted around directories “._*”?

    Im trying to run mac os clients with NFS home directories (not using portable directories), but have the above issues, as well as a few application issues (flash,firefox/chrome,etc). I thought I remembered reading somewhere that at least the trash can problem was fixed when using a mac os x server for authentication (or a suitably configured ldap server). Obviously I can’t find that source anymore!

    • Colin

      For reference, I’ve not actually run this setup for quite some time. My OSX install is only rarely used (only to update my phone basically, and I’ll soon be changing it, so likely to be ditched entirely).

      But prior to my last (linux) server update, I was using NFS directly as home dirs, no syncing involved. To be honest, I cannot recall if I had the delete immediately problem or not. I think I likely did, but honestly can’t remember, sorry. Since the last update at the server end, the NFS bit stopped working, although authentication is still fine. I didn’t bother investigating it as the time spent doing that would likely take longer than just updating my phone with a local user account!

      Sorry I can’t be more helpful 🙁

      • Ed

        No problem. I’ll add some details for anyone finding this from google.

        After some more work on LDAP I think I’ve got the trash can working (only on a test account at the moment) and some of my other issues resolved (although most of them will need time to confirm they’ve gone). This is without using PHDs, using the standard RFC2307 mapping, not open directory (I haven’t used samba.schema or apple.schema).

        People can email me if they’re trying something similar,