In the two-part series titled “Autofs goodness in Apple’s Leopard (10.5)“, we took a detailed look at Leopard’s automount, autofs. In this article, we will look at the integration of leopard’s autofs with LDAP. There is not a lot of documentation from Apple on it, and when I got down to do the work, it took a bit of trial-and-error on my part.
First off, Leopard’s autofs DOES work with LDAP. Second, we are also looking at a little bit of hardcoded application from Apple, ergo not very flexible. Third, the integration of Mac OS X into LDAP is not covered in this particular post, as it was quite heavily covered in this comprehensive article titled “Integrating Mac OS X into Unix LDAP Environment with NFS Home Directories“.
Autofs and Directory Utility
Directory Utility is used to manage LDAP connections, services setup and lookup order using Directory Utility. For those who used Directory Utility in TIGER to setup mount objects, user objects etc in an remote LDAP servers, all that is still there and it will still work. However, the new autofs that is introduced in Leopard will not use Directory Utility to manage any of its maps in LDAP. The autofs ldap maps are managed separately.
Autofs LDAP schema
This one is easy. Leopard comes with openldap installed. The openldap schema directory contains all the schema files, including the autofs schema. The automount specific schema is re-produced below:
attributetype ( 1.3.6.1.1.1.1.31 NAME 'automountMapName'
DESC 'automount Map Name'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
attributetype (
1.3.6.1.1.1.1.32
NAME 'automountKey'
DESC 'Automount Key value'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
attributetype (
1.3.6.1.1.1.1.33
NAME 'automountInformation'
DESC 'Automount information'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
objectclass (
1.3.6.1.1.1.2.16
NAME 'automountMap'
SUP top STRUCTURAL
MUST ( automountMapName )
MAY description )
objectclass (
1.3.6.1.1.1.2.17
NAME 'automount'
SUP top STRUCTURAL
DESC 'Automount'
MUST ( automountKey $ automountInformation )
MAY description )
The big difference between linux autofs and leopard’s autofs is that linux autofs supports both nisMap and automount schemas, whereas Leopard’s autofs only supports the automount schema definition. Considering that all vendors are (slowly) moving towards the automount schema, it is not bad after all. The hassle is for those who already have legacy autofs implementations in Linux, Solaris and elsewhere that depend on the nisMap schema definitions. Leopard sort of forces you to make that breakway.
Leopard’s autofs only supports the automount schema definition
For example, in Derek’s case (and in my own case), our maps are laid out using the legacy nisMap schema. To allow for the newer clients to look up ldap maps, Solaris ldap clients are adjusted and the newer schema is mapped to the old schema.
auto_master
Here’s the first hard coded part. The master file for autofs is hardcoded to auto_master. This is also different from the linux autofs where you can specify the master file in the sysconfig files. When automount starts up in Leopard, it issues this ldap search.
SRCH base="automountMapName=auto_master,<BASEDN>" scope=1 deref=0 filter="(&(|(objectClass=automount)))"
The auto_master entries are extracted out of this search and subsequent LDAP calls are issued as the mount requests are made. These subsequent LDAP autofs calls are all quite simple and easy to understand.
The master file for autofs is hardcoded to auto_master
THe following ldif file is a working example of how one could lay out the autofs maps in a LDAP suffix:
dn: automountMapName=auto_master,dc=example,dc=com objectClass: top objectClass: automountMap automountMapName: auto_master dn: automountKey=/home,automountMapName=auto_master,dc=example,dc=com objectClass: top objectClass: automount automountKey: /home automountInformation: auto.home dn: automountKey=/local,automountMapName=auto_master,dc=example,dc=com objectClass: top objectClass: automount automountKey: /local automountInformation: auto.local dn: automountKey=/,automountMapName=auto.home,dc=example,dc=com objectClass: top objectClass: automount automountKey: / automountInformation: filer:/vol/home/& dn: automountKey=tier1,automountMapName=auto.local,dc=example,dc=com objectClass: top objectClass: automount automountKey: scratch automountInformation: filer:/vol/tier1
These maps also do not collide with the LDAP Directory Services mapping you may have setup during the TIGER days and should put you in a decent shape to begin peeling off the NetInfo stuff from LDAP and moving towards the Directory Utility world. Good Luck!
Thanks for the excellent post – it helped me a lot.
I did find that when I set this up recently the automountKey=/ bit didn’t work. Could be things have moved on in the last two years at the OSX side, but using a key of * worked fine.
I wrote up my experience over here: http://colin.guthr.ie/2009/07/integrating-login-and-home-directory-on-os-x-leopard-clients/
Thanks again.
[...] 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 [...]
That’s a great point indeed about most places not having the ability to make LDAP changes.
I am spoiled by the fact that my teams do it all (LDAP, Unix and Mac!)
Can you think of a tool that will allow for remote management of Mac OS X ? Workgroup Manager comes to my mind and we push out a lot of company wide policies using it to all Macs.
If there are other tools that you know of that allow for remote management of mac clients, it’ll be great if you can do a write up on it on your blog (which is cool, BTW)
Migrating to the new schema is preferred, but OS X admins can’t always convince the people who run the LDAP servers to make changes for them.
Managing Directory Services configurations is a standard OS X admin task; one assumes OS X admins have a way to manage these configurations. I use radmind, but there are lots of tools to use. The relevant info is in /Library/Preferences/DirectoryService/DSLDAPv3PlugInConfig.plist and /Library/Preferences/DirectoryService/SearchNodeConfig.plist
@Greg
I would recommend folks to migrate to the new automount schema. The old nisMap schema is on its way out.
Directory Utility stores the information as xml files on the system itself. Could be a problem if one is managing a large number of OS X clients with LDAP integration.
The good news is that if you did have the NetInfo entries in LDAP and were getting your automount entries from LDAP that way, it will still work!
Leopard’s autofs only supports the automount schema definition, but if you have the older nisMap schema, you can use Directory Utility to edit the LDAP mappings to work with the nisMap schema.
The master file for autofa is hardcoded to auto_master, but it’s a simple matter to edit the local /etc/auto_master file to point it at a “auto.master” file in LDAP:
Change +auto_master # Use directory service
to: auto.master # Use directory service
More on integrating Leopard’s autofs with LDAP here: http://managingosx.wordpress.com/2007/12/11/autofs-in-leopard