- the occasional blog - http://rajeev.name -

Integrating Mac OS X into Unix LDAP Environment with NFS Home Directories

Posted By rajeev karamchedu On September 9, 2006 @ 2:26 pm In How-To Series,Technology | 63 Comments


Mac OS X and Mac OS X Server have been designed to fit into existing enterprise directory services. Apple’s extensible Open Directory architecture integrates with standards-based LDAP directory services, including Sun JAVA Enterprise Directory Server and IBM Directory Server, as well as with proprietary ones such as Microsoftâ„¢s Active Directory.

In Mac OS X 10.4 (Tiger), Apple released a new feature called Portable Home Directories which allows Macintosh laptop users to maintain synchronized copies of their home directories on their laptop and the network. When a user goes off line with the laptop, her home directory goes with her, so she can continue to work just as if she would back at the office. When she reconnects to the network, Mac OS X automatically syncs up selected content in her local home directory with the one on the server.

The following possibilities are available to any Systems Administrator or Architect who is looking to integrate Mac OS X into their IT Environment. Depending upon what’s already installed and available, the choices are:

  • Use the existing Active Directory Environment to authentication Macintosh users.
  • Use the existing Open Directory Server on a Mac OS X server to authenticate Mac users
  • Use the existing LDAP Environment (Novell, Sun ONE, OpenLDAP etc) to extend authentication services
  • Install one of the above, if a centralized solution is not already implemented.

In this article, we will discuss in detail, the steps required to integrate Mac OS X with Sun ONE Directory Server for authentication and also configure and manage the Portable Home Directories using NFS. There is adequate documentation on the internet with regards to Active Directory Integration and synchronizing home directories using Window File Sharing Protocols and SAMBA. However, when it comes to non-Apple and non-Microsoft Directory Services and NFS, there is a dearth of case studies and documentation. We hope to resolve that with this article.

In addition to achieving full integration, this approach also allows the use the Macintosh Work Group Manager to manage apple users, groups and computers and associated policies. Apple stores all of policy and preference settings in plists. Unless you have another method to make changes to these plists and manage them, I strongly recommend that you use Work Group Manager.


It is assumed that the implementation environment is a Unix environment with a standards based LDAP server deployed for authentication and home directories being served from a central NFS server. It is desired to extend the LDAP auth services and NFS home directories to Macintosh Systems

Implementation Environment

While this document’s steps are specific to the following products, since all of them are standards-based, only product-specific knowledge would be needed to adopt this methodology to other environments (for e.g. OpenLDAP, Novell etc)

  • Directory Server: Sun ONE Directory Server 5.2
  • Home Directories: Hosted on a central Network Appliance file server, accessible via NFS

Preparing the Directory Server

Preparing the Directory Server for Apple’s use involves two steps: Extending the Schema and Populating the server with objects. Extending the schema, though it is quite simple a Sun ONE Directory Server or an OpenLDAP server, should only be performed by administrators who understand the DS operations very well and know how to back out the schema if necessary.

Extending the Directory Server Schema

In order for a Mac Server or Workstation to use an LDAP server for authentication and authorization services, it needs to find users, groups, computers, access policies and such data in ldap servers. Apple’s OD uses standard objectclasses such as posixAccount, shadowAccount, posixGroup etc to store and find user, group and computer information. In addition, it uses apple’s native (custom) attributes to store apple-specific information (e.g AFP homedir location, user’s icon, apple’s generated UID etc). The table below provides a list of the objects that Apple uses and the objectclasses they comprise of. For a full list of mappings including the objectclasses and attributes, please consult the Mac OS X Server Open Directory Administration Guide

Apple LDAP Mappings
LDAP Object Class Name Schema
inetOrgPerson RFC 2798
posixAccount RFC 2307
shadowAccount RFC 2307
apple-user Apple Extended Schema
posixGroup RFC 2307
apple-group Apple Extended Schema
People inetOrgPerson RFC 2798
Mounts mount Apple Extended Schema
Computer apple-computer Apple Extended Schema
Computer Lists apple-computer-list Apple Extended Schema
Config apple-configuration Apple Extended Schema
Preset Computer Lists apple-preset-computer-list Apple Extended Schema
Preset Groups apple-preset-group Apple Extended Schema
Preset Users apple-preset-user Apple Extended Schema
apple-printer Apple Extended Schema
printerIPP IETF-Draft-IPP-LDAP
AutoServerSetup apple-serverassistant-config Apple Extended Schema
Locations apple-locations Apple Extended Schema

There are couple of ways to get this native apple data into our LDAP server.

  • Using Unused Attributes

    One approach is to employ the unused attributes that are found in LDAP configuration to host this information. However, if the original vendor who is assigned those attributes decides to start using these attributes, then you will risk breaking the implementation and future upgrades can turn messy. Not Recommended

  • Import Apple Specific Schema

    Extending the LDAP Schema to include apple schema will allow us to store all of the Macintosh data in ldap servers in their own objectclasses and attributes. Schema extensions are a lot easier to perform and maintain in Sun ONE LDAP Servers and OpenLDAP servers than Active Directory. Recommended

    In order to realize the full functionality of Work Group Manager, it is best if you extend the LDAP Server with apple schema, which is what we have decided to do.

Note Of Caution: Apple’s schema is a work-in-progress. Apple declares that it may extend the schema to support the future version of Mac OS X and Mac OS X Server. The latest version of the schema can be found in the file


of any Mac OS X Server running the latest version of the OS.

The schema file, as it is, however, needs some formatting before it can be imported into Sun ONE Directory Server. The schema files for Directory Server are stored in


directory. These schema files are read once at start up time by the DS and are stored in

cn=schema entry

during runtime. The schema files are prefixed by a number and are read in alphanumerical order, since the order in which these schema files are read is critical.

The file


contains additional ACIs for the DS that may have been added using the console or via the command line. Also note that in a replicated environment, any changes made on the replicas’


file will be overwritten the next time the schema is replicated from the Master server. Schema modifications must always be made on the master server and they should be stored in separate files. For more information on Extending Sun ONE Directory Server Schema, please consult the Sun ONE Administration Guide. [1]

We will store our apple schema in a file called


on the master server. This will ensure that this file will get read before the


. Also note that on the replica servers, you will NOT find a


after performing a schema replication. Instead, all of the new schema should be found merged in


on the replicas.

Adjusting the Apple Schema
Some Notes about Apple Schema and Sun ONE Directory Server:

  • The apple.schema needs to be converted to ldif format before it can be imported. A formatted apple.schema can be downloaded here [2]. Note that this file includes both the native apple schema and also the samba scheme that is used by apple objects. Sun ONE Directory Server does not include samba schema so I have included it here.

  • The standard unix nfs clients use the ldap attribute


    to mount the NFS home directory from the server. In almost all the cases, the value for this attribute is


    . This is also the attribute that apple by default uses, to mount its home directory. However, in order to implement Apple’s Portable Home Directories fully, apple expects a different value for this attribute (i.e.


    ). Fortunately, the apple schema also includes an alternative attribute called


    to be used in such cases. This attribute comes commented out and needs to be uncommented before importing.

Populating with Data

Once the schema has been successfully extended, it is now time to create the various containers and objects that Mac OS X expects to find in the directory server. Since the LDAP Servers are already in service to authenticate Unix users and provide NFS home directory locations, the LDAP tree may look like the following:

Server: Example.com

  • dc=example,dc=com
    • ou=People – BaseDN location for Unix User Accounts, Address Book entries
    • ou=Group – Base DN location for Unix, Netscape and Other Groups
    • ou=Hosts – Base DN location for Computers
    • ou=Protocols
    • ou=Services

For populating the Macintosh Objects and Entries, we have decided to organize the our tree in the following fashion. Proper organization of objects in a directory tree can save the IT Staff a lot of headaches in future as more and more services are integrated into the LDAP environment. An optimal directory tree structure is also site-specific. You do not want to send your IT Staff running around changing the LDAP configurations on all machines because the directory tree structure has changed. This will not only add delay and implementation costs on the IT side, but will also result in downtime to your users – who may not be very happy as a result.

Server: Example.com

  • dc=example,dc=com
    • ou=PeopleThese entries will be extended to become apple-user objects
    • ou=GroupThese entries will be extended to become apple-group objects
    • ou=HostsBase DN location for Computers
    • ou=Protocols
    • ou=Services
    • ou=macosx – New OU created to hold all other Mac Objects for easier management
      • ou=accesscontrols
      • ou=autoserversetup
      • ou=certificateauthorities
      • ou=computer_lists
      • ou=computers
      • ou=config
      • ou=filemakerservers
      • ou=locations
      • ou=machines
      • ou=mount
      • ou=neighborhoods
      • ou=preset_computer_lists
      • ou=preset_groups
      • ou=preset_users

How did we know that these containers are needed by Apple ?

On an OS X Server, we started the Open Directory Server and created one admin user. We then dumped the directory tree contents to a file to see what containers Apple is looking for. This approach guarantees that Apple Work Group Manager will work with our LDAP server without any problems.

In our existing LDAP directory, a standard unix user account object looks something like this:

% ldapsearch -h ldapmaster  -b "ou=people,dc=example,dc=com" -L uid=testuser
dn: uid=testuser,ou=People,dc=example,dc=com
homeDirectory: /home/testuser
mail: testuser@example.com
sn: User
givenName: testuser
cn: TEST
loginShell: /bin/tcsh
gidNumber: 400
uid: testuser
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
uidNumber: 8000
gecos: Test User Account

The following attributes and objectclasses need to be added to this user object in order to make it into an apple-user object.

objectclass: apple-user
attribute: authAuthority
attribute: apple-user-homeDirectory

  • authAuthority: authAuthority attribute contains information about how the user’s password needs to be verified. Since the authentication requests are not going to an Open Directory server, the value of authAuthority should be set to



  • apple-user-homeDirectory: This is the location of your NFS home directory in this format
    • /Network/Servers/path/to/nfs/home/directory

    For e.g. if your NFS server path to your home directory is nfsserver:/vol/home/testuser. On all unix/linux clients, it is (usually) mounted at /home/testuser. On a Mac, however, for portable home directories to work, the apple-user-homeDirectory should be set to :

    apple-user-homeDirectory: /Network/Servers/nfsserver/vol/home/testuser

Modify the user object to include these attributes

% ldapmodify -h ldapmaster -D FakeDirAdminUserName -w FakeDirAdminPassword
dn: uid=testuser, ou=people,dc=example,dc=com
changetype: modify
add: objectclass
objectclass: apple-user
add: authAuthority
authAuthority: ;basic;
add: apple-user-homeDirectory
apple-user-homeDirectory: /Network/Servers/nfsserver/vol/home/testuser
modifying entry "uid=testuser,ou=people,dc=example,dc=com"

Create and Populate Mount Objects

Mac OS X uses the


objectclass to look for NFS, SMB and AFP mount information, including user home directories. Detailed discussion of automount implementation in Mac OS X is outside the scope of this article. Automount in Mac OS X has been covered excellently here [3] and here [4].

Briefly, however, it is important to note that while it is possible to mount a user’s home directory at the traditional location (


), doing so will disable some of the end-user features of Portable Home Directories... When using NFS, the only way we were able to fully implement Portable Home Directories is to use the


option in the mount Object.

Consequently, using the “net” option in Mac OS X means that the mount directory will be /Network/Servers – hence the reason to set the apple-user-homeDirectory value to /Network/Servers/path/to/nfs/homedir.

With that, a mount entry for a user’s home directory should look like:

dn: cn=nfsserver:/vol/home/testuser,ou=mount,ou=macosx,dc=example,dc=com
mountOption: rw
mountOption: net
mountOption: intr
mountOption: nfsv3
mountOption: tcp
mountOption: rdirplus
mountOption: bg
mountDirectory: /Network/Servers
objectClass: mount
objectClass: top
mountType: nfs
mountPassNo: 0
mountDumpFrequency: 0
cn: nfsserver:/vol/home/testuser

The mount options, nfsv3, tcp, rdirplus, bg, intr are all site-specific options and often related to performance and availability.

Mapping Remaining Attributes and ObjectClasses

Apple stores all of its remaining LDAP mappings and configuration information in LDAP itself, in a container called ou=macosxodconfig. One of the many advantages of this approach is that once these mappings are performed and written to the server, subsequent client configurations will download all of them automatically from the LDAP server. We need to use a Macintosh client machine running 10.4.3 or later and admin privileges to perform this operation. We will also need the username and password of the LDAP Administrator or at least, the binddn and bind password of a user account with read/write privileges to the mac osx suffix container (i.e. ou=macosx)

  • Login to the client as an admin and open up Directory Access application. (Found in /Applications/Utilities/Directory Access)
  • Click the lock icon in the bottom-left of the window to authenticate. Check LDAPv3 and click Configure. A new screen will appear
  • Important! – Ensure that the box labeled Add DHCP-supplied LDAP servers to automatic search policies is unchecked. There are several security advisories relating to its use
  • Click New. Enter the FQDN of the master LDAP server in the Server Name field. Make sure that Use for authentication and Use for contacts is selected
  • Click Manual
  • In the resulting screen, give a descriptive name to the configuration and click Edit
  • In the resulting screen, select the second tab titled Search & Mappings
  • From the drop-down labeled Access this LDAPv3 server using, Select Open Directory Server
  • A new window pops up, prompting for the Search base suffix. Enter dc=example,dc=com and click OK
  • You will see a list of Record Types and Attributes in a split-screen window. Mapping is done by selecting a object type in the left screen and mapping them to LDAP Object classes in the screen on the right. Using the table below to map the Record Types and Attributes.

    For the sake of brevity, I am only listing the attributes that you need to change

    • Users
      • Mapping: inetOrgPerson, posixAccount, shadowAccount and apple-user
        Search Base: ou=People,dc=example,dc=com
        Scope: First level Only
      • RecordName
        • Mapping: uid
      • RealName
        • Mapping: displayName
      • NFSHomeDirectory
        • Mapping: apple-user-homeDirectory
      • homeDirectory
        • Mapping: apple-user-homeurl
    • Groups
      • Mapping: posixGroup, apple-group
        Search Base: Ou=Group,dc=example,dc=com
        Scope: First Level Only
    • Mounts
      • Mapping: mount
        Search Base: ou=mount,ou=macosx,dc=example,dc=com
        Scope: First Level Only

    For the remaining objectclasses (Record Types), the only value that needs to be changed is the Search Base so that it reflects our directory tree. For e.g., cn=machines,dc=example,dc=com should be changed to ou=machines,ou=macosx,dc=example,dc=com

  • Once all the changes are done, click Write to Server
  • In the resulting pop-up dialog box, enter the LDAP administrator username and password (or the username and password of the bind dn and bind password of the user who has read/write access to the ou=macosx container) This will write create an object ou=macosxodconfig,ou=config,ou=macosx,dc=example,dc=com. This container will also be used later by Work Group Manager to store Managed Preferences

Done! For subsequent client configuration, you only need to know the hostname of the ldap server.

Configure the clients to pull the Search and Mappings from the server (instead of Open Directory Server, select “From Server” with Search Base as ou=config,dc=example,dc=com) and you will be all set!

In the next section, we will configure a macintosh client with ldap so that our testuser can use LDAP logins and configure portable home directories.

Client Configuration
Now that our LDAP Server is setup with all the OD schema and objects, it is time to configure the clients. This is the easiest part of the whole process.

  • Login to the Macintosh Client as an admin user
  • Open Directory Access application. Either use Spotlight to bring it up or double-click it in /Applications/Utilities/Directory Access.
  • Click the lock icon on the bottom-left corner to unlock the screen. Check LDAPv3 and and Click Configure. A new screen will appear
  • Important! – Ensure that the box labeled Add DHCP-supplied LDAP servers to automatic search policies is unchecked. There are several security advisories relating to its use
  • Click New. Enter the FQDN of the LDAP server in the Server Name field. Make sure that Use for authentication and Use for contacts is selected
  • Activate the pull down menu titled LDAP Mappings and select From Server. This will cause the client to perform a sub-scope search under the basedn for the entry

    and use that to pull down all of the ldap configuration information.
    Once the configuration is complete, you will see a message

    Configuration of new server complete

  • Click OK and give a descriptive name to the Configuration and click OK
  • Click on Authentication and ensure that the newly created LDAP configuration is listed in the Authentication list. It will be listed below NetInfo/DefaultLocalNote which appears in gray. This cannot be changed.
  • If your Contacts are listed in LDAP server as well, then you can click the Contacts tab and put your LDAP server there as well.

All Done! For a good measure, restart the client. You should be able to login with your LDAP credentials. Upon successful logins, OS X will cache these credentials and you would still be able to log-off and log-on when you are not on the corporate network.

Using Work Group Manager with LDAP

Apple provides Workgroup Manager application, that can be used to manage share points, users, groups and network-wide macintosh policies. It can be downloaded as a separate package here [5] and run on any mac desktop that is configured with LDAP services. Please follow to this post [6] to read more about how to setup and use the WGM with LDAP.


  1. Apple Discussions [7]
  2. Apple Mailing Lists [8]
  3. AFP548 Website [9]
  4. MacEnterprise Website [10]
  5. Mac OS X Server 10.4 Manuals [11]
  6. Open Directory and Active Directory [12]
  7. Integrating Mac OS X And Novell eDirectory – Intro [13]
  8. Integrating Mac OS X in a NIS Environment [3]
  9. Using automount on Mac OS X [4]

Integrating Mac OS X into Unix LDAP Environment with NFS Home Directories:HowTo Series:Rajeev Karamchedu

63 Comments (Open | Close)

63 Comments To "Integrating Mac OS X into Unix LDAP Environment with NFS Home Directories"

#1 Comment By Mike Connor On October 15, 2006 @ 2:18 am

Extremely handy! Thanks a bunch for posting this!

#2 Comment By Bjørn Tore Sund On February 14, 2007 @ 7:28 pm

Exactly what I needed to get my Macintoshes integrated into a larger system. Thank you very much!

#3 Comment By rajeev karamchedu On February 18, 2007 @ 5:16 pm

No problem! I am glad you found it useful. With [14] out for the developers, I hope to write up a similar article on Leopard’s integration with NFS and AD!

#4 Comment By Christoph Lukas On March 19, 2007 @ 4:14 pm


thanks for your article.

Reading the introduction I thought: ‘Wow, exactly what I was looking for’. But it seems this article only covers the integration of the mac os scheme with a directory server. Or did I miss a link to a followup?

I would really like to know details on how you setup PHD with NFS.


#5 Comment By rajeev karamchedu On March 19, 2007 @ 4:28 pm

I think I am missing the link for the follow up. I have written the article initially as separate pages that covered all of the implementation (including home directories over NFS using automounter). Let me check for those posts and link them properly. Sorry about that.


#6 Comment By rajeev karamchedu On March 19, 2007 @ 6:09 pm

I found some HTML code from the page templates that was causing the rest of the output to be hidden. The full article is online now. Hope you find it useful.

I am testing Leopard and hope to write up some info on that as well.

#7 Comment By Brian B On April 4, 2007 @ 2:34 pm

How did you convert the apple.schema to an ldif file? May I have a copy of your apple.ldif?

#8 Comment By rajeev karamchedu On April 4, 2007 @ 6:59 pm

Hi Brian

The page has the link to the formatted apple schema.

The apple.schema needs to be converted to ldif format before it can be imported. A formatted apple.schema can be downloaded [15].


#9 Comment By P. Did On May 8, 2007 @ 7:18 pm

Your site was very helpful. Two additional things. Can you detail more your experiences with Workgroup Manager? I find that it’s unable to connect WGM to my directory (after all the other changes) because it requires the Apple DirectoryService listener on port 625

#10 Comment By Pirmin On May 9, 2007 @ 9:33 am

Your site is great.
I can not mount the home directory during the login process – so i can not login.
How should the apple-user-homeurl look like?
Something like this?

Thanks a lot

#11 Comment By rajeev karamchedu On May 9, 2007 @ 6:37 pm


Thanks much for your note. The settings really depend on your configuration and on your mappings.

The OSX code looks for these two attributes for setting up the home directories:


If using NFS, you should in the least, map NFSHomeDirectory to the LDAP attribute – apple-user-homeDirectory

Technically I did not see the need to map the HomeDirectory attribute at all. If you are using AFP home dirs, you may need to map it to apple-user-homeurl. The thing with apple-user-homeurl is that its value is actually an XML spec like this:


For NFS, OSX uses the attribute NFSHomeDirectory. The above document talks about setting it. basically it is /Network/Servers/path/to/nfs/homedir. So using your example, the string should be /Network/Servers/$SERVERNAME/Volumes/homes/$USERNAME

#12 Comment By P. Did On May 15, 2007 @ 10:13 am

Sorry to be a bother, but I’m very interested if you’ve been able to get WorkGroup Manager working with your configuration. How did you do so without having someone/something listening on the DirectoryListener port? What steps after configuration of your did it take to get WGM working?


#13 Pingback By the occasional blog » WGM on LDAP Directory On May 15, 2007 @ 6:36 pm

[…] article I had written about integrating Mac OS X with LDAP attracted a bit of attention. While I had […]

#14 Comment By ernst On May 28, 2007 @ 4:15 pm

Thanks for your writing.
But I also would be interested how you managed to connect Workgroup Manager to LDAP. Mine says something like server not found.

#15 Comment By rajeev karamchedu On May 28, 2007 @ 5:20 pm


I have detailed that on a separate post here at


#16 Comment By Pirmin On June 7, 2007 @ 9:43 am

Hi it’s me again :-)

I couldn’t use smb for the synced mobile homes, because it worked not steadily. Sometimes the sync process worked ond sometimes not. Maybe so problems with the automounter?

I use now nfs – I am more happy with nfs but not to 100 %. Sometimes the share don’t gets mounted and the sync process isn’t working during this time. What is wrog with the mount?
There is another strange thing. When i login with a new / fresh created user the nfs mount is not mounted. When I login the second time the nfs mount is mounted.
Do you have an Idea what could be wrog? Do you have any sugestions?

Thanks a lot for your great support :-)

#17 Comment By ega On July 11, 2007 @ 11:18 am

can you clarify what the client actually uses for self configuration?
You say “Client will self-configure itself by searching for ou=macosxconfig entry in the basedn.” except the listing for the root DN here and on my real OSX server shows ou=Config at base.
Does MacOS X client do subtree search for ou=Config in the entire base DN ?? How does the client know to look for ou=Config, ou=macosx,dc=foo,dc=bar without a mapping (we are trying to deliver a mapping for self config) ? Confused…

#18 Comment By rajeev karamchedu On July 11, 2007 @ 12:45 pm

Hi Ega

That is a typo that I have since corrected. It is not macosxconfig but rather macosxodconfig. Sorry about that.

Earlier on in the page, I have mentioned

Apple stores all of its remaining LDAP mappings in LDAP itself, in a container called ou=macosxodconfig.

In the earlier step under the section Mapping Remaining Attributes and ObjectClasses, we had setup the mappings and written all the mappings to ou=macosx,dc=example,dc=com. What actually happens there is that a container called “config” is created under that suffix (that we enter) and underneath that an ou=macosxodconfig is created where an XML blob containing all LDAP info is stored.

In the later step, when we go to configure the client, all you have to do is specify the suffix base dn and it will do a sub-scope search for ou=macosxodconfig and pulls all LDAP info out of it !

#19 Comment By Prakash Velayutham On July 20, 2007 @ 7:07 pm

I am trying to set this up using an OpenLDAP server and Mac OS X clients, but for some reason, the client does not let me login as an LDAP user.

Server gets the request and it can find the relevant user in its tree, but somehow the password does not get passed on from the client to the server, and the server keeps denying the auth access for “userPassword” attribute for the client. Finally server fails saying

Jul 20 19:00:51 headnode slapd[7804]: do_sasl_bind: dn () mech CRAM-MD5
Jul 20 19:00:51 headnode slapd[7804]: conn=38 op=1 BIND dn=”” method=163
Jul 20 19:00:51 headnode slapd[7804]: ==> sasl_bind: dn=”” mech= datalen=42
Jul 20 19:00:51 headnode slapd[7804]: SASL Canonicalize [conn=38]: authcid=”user”
Jul 20 19:00:51 headnode slapd[7804]: slap_sasl_getdn: conn 38 id=user [len=9]
Jul 20 19:00:51 headnode slapd[7804]: slap_sasl_getdn: u:id converted to uid=user,cn=CRAM-MD5,cn=auth
Jul 20 19:00:51 headnode slapd[7804]: >>> dnNormalize:
Jul 20 19:00:51 headnode slapd[7804]:
Jul 20 19:00:51 headnode slapd[7804]: ==>slap_sasl2dn: converting SASL name uid=user,cn=cram-md5,cn=auth to a DN
Jul 20 19:00:51 headnode slapd[7804]: slap_authz_regexp: converting SASL name uid=user,cn=cram-md5,cn=auth
Jul 20 19:00:51 headnode slapd[7804]:
Jul 20 19:00:51 headnode slapd[7804]: SASL Canonicalize [conn=38]: slapAuthcDN=”uid=user,cn=cram-md5,cn=auth”
Jul 20 19:00:51 headnode slapd[7804]: SASL [conn=38] Error: unable to open Berkeley db /etc/sasldb2: No such file or directory
Jul 20 19:00:51 headnode slapd[7804]: SASL [conn=38] Error: unable to open Berkeley db /etc/sasldb2: No such file or directory
Jul 20 19:00:51 headnode slapd[7804]: SASL [conn=38] Error: unable to open Berkeley db /etc/sasldb2: No such file or directory
Jul 20 19:00:51 headnode slapd[7804]: SASL [conn=38] Failure: no secret in database
Jul 20 19:00:51 headnode slapd[7804]: send_ldap_result: conn=38 op=1 p=3
Jul 20 19:00:51 headnode slapd[7804]: send_ldap_result: err=49 matched=”” text=”SASL(-13): user not found: no secret in database”
Jul 20 19:00:51 headnode slapd[7804]: send_ldap_response: msgid=2 tag=97 err=49
Jul 20 19:00:51 headnode slapd[7804]: conn=38 op=1 RESULT tag=97 err=49 text=SASL(-13): user not found: no secret in database

Any help appreciated,

#20 Comment By rajeev karamchedu On July 20, 2007 @ 9:52 pm

Looks like your have some setup issues to work out – mainly SASL stuff.

looky here:

Jul 20 19:00:51 headnode slapd[7804]: do_sasl_bind: dn () mech CRAM-MD5

Obviously doing a SASL bind..


Jul 20 19:00:51 headnode slapd[7804]: SASL [conn=38] Error: unable to open Berkeley db /etc/sasldb2: No such file or directory
Jul 20 19:00:51 headnode slapd[7804]: SASL [conn=38] Error: unable to open Berkeley db /etc/sasldb2: No such file or directory
Jul 20 19:00:51 headnode slapd[7804]: SASL [conn=38] Error: unable to open Berkeley db /etc/sasldb2: No such file or directory

you may want to resolve them first…

#21 Comment By Prakash Velayutham On July 26, 2007 @ 11:09 am

How do I enable simple binds from Mac client in this case? What should be the server-side configuration so that SASL binds from the client fall back to simple.

My OpenLDAP version is 2.3.27-25
Mac OS X Client – 10.4.10


#22 Comment By Lyndon Van Wagner On September 16, 2007 @ 8:52 pm

Thanks for this article. I’m in the process of setting up an LDAP server @ home, so that I can centralize user accounts… Its my 1st use of LDAP, so what confused me was how to get 92apple.schema into the LDAP DB. Finally, I found out that we include it in slapd.conf. You might want to add that for other novices. ;-)

#23 Comment By MSN_Exploder On October 29, 2007 @ 11:52 am

first off all, thanks for your great article ^^
I’m running several macs with Tiger using PHD without issues.


I tested Leopard these days, and everything works great (ie. Logon with network users, working with “normal” network users straight on the server) but using PHD doesn’t work.
it’s simply not syncing anything, login, creating home dir etc works without problems but it’s not syncing one file.
I’m totally lost :-(

Tried to create an new User with the new Workgroup Manager (works without problems) but still no syncing.

Maybe u could help me. ^^
I don’t won’t to loose my PHDs.

Ohh, I’m using Freebsd-6.2 just in case ;-)


#24 Comment By Loc Stewart On November 1, 2007 @ 4:54 pm

Thank you very much for your article. I followed your instructions completely and also used the apple_schema.ldif from the link. When I added the apple-user obj apple-user-homeDirectory was not available. Two questions: 1. how do I modify the apple_schema.ldif to give apple-user this attr? I do not know how to convert schema to ldif file. 2. With a new .ldif file, what should I do to remove the previous one that I have added to the schema?
I am totally new with ldap, but your instructions took me through amazing work, thanks again.

#25 Comment By Christopher Smith On November 7, 2007 @ 11:33 am

How about the other way around? Integrating Linux into OS X Open Directory Environment with Home Directories.

#26 Pingback By the occasional blog | Integrating Linux into Open Directory On November 8, 2007 @ 1:22 pm

[…] posted a comment on my Mac OS X article about integrating Linux into a Mac OS X Open Directory Environment. I figured […]

#27 Comment By Chris G. Sellers On November 21, 2007 @ 1:28 pm

Has anyone run across account management issues with the NS schema versus shadowAccount? e.g. , SunONE likes to store stuff in passwordExpirationTime and passwordHistory like attributes instead of shadowExpire. Do your MacOS X clients resepect those attributes or how did you map them? What about filters for users, how did you say these people or groups can login but no one else?

#28 Pingback By the occasional blog | Autofs goodness in Apple’s Leopard (10.5) – Part I On November 22, 2007 @ 11:50 pm

[…] about integrating Apple into your exsiting Unix/NFS environment, please read the article Integrating Mac OS X into Unix LDAP Environment with NFS Home Directories. Rant:  Even with Leopard, there is no support for Microsoft DFS. […]

#29 Comment By chefhomer On December 4, 2007 @ 4:12 pm

Have you tried integrating any Mac OS X 10.5 Leopard Servers with your iPlanet Directory Server yet? If you import the newer Apple schema file from Leopard Server – can the older 10.4 machines still continue to use the same instance of the directory server (with the data present in the Tiger schema fields? ( are the new fields/objects in the leopard schema just an extension to the Tiger schema – or did anything get re-mapped?) Thanks for any info.

#30 Comment By Derek On December 7, 2007 @ 7:09 pm

Great write-up!
Ok, I’ve searched for awhile and I’m not finding what I need to make this happen.
We have an openldap server runing on a linux machine. I am trying to get the apple leopard client to understand the automount maps we have in the ldap tree on the server. I have successfully configured the apple client’s user and group settings simply by appending ou=People, to the searchbases of the User and People records and appending ou=Group, for the Groups record on the client. The automount part is much trickier apparently. Like sun apple uses the auto_foo syntax with autofs but unlike sun I can’t figure out what the equivalent command to ldapclient is on the apple. Basically we slurped over the NIS maps from nis into ldap so now at the root level of the ldap structure on the ldap server we have:

# LDIF Export for: dc=foo,dc=bar,dc=bla
# Generated by phpLDAPadmin ( [16] ) on December 6, 2007 12:33 pm
# Server: Master LDAP Server (ldap.foo.bar.bla)
# Search Scope: one
# Search Filter: (objectClass=*)
# Total Entries: 8

dn: nisMapName=auto.foo,dc=foo,dc=bar,dc=bla
objectClass: top
objectClass: nisMap
nisMapName: auto.foo

dn: nisMapName=auto.master,dc=foo,dc=bar,dc=bla
objectClass: top
objectClass: nisMap
nisMapName: auto.master

dn: nisMapName=auto.mirror,dc=foo,dc=bar,dc=bla
objectClass: top
objectClass: nisMap
nisMapName: auto.mirror

dn: nisMapName=auto.notbackedup,dc=foo,dc=bar,dc=bla
objectClass: top
objectClass: nisMap
nisMapName: auto.notbackedup

dn: nisMapName=auto.projects,dc=foo,dc=bar,dc=bla
objectClass: top
objectClass: nisMap
nisMapName: auto.projects

dn: nisMapName=auto.test,dc=foo,dc=bar,dc=bla
objectClass: top
objectClass: nisMap
nisMapName: auto.test

dn: ou=Group,dc=foo,dc=bar,dc=bla
ou: Group
objectClass: top
objectClass: organizationalUnit

dn: ou=People,dc=foo,dc=bar,dc=bla
ou: People
objectClass: top
objectClass: organizationalUnit

below is the contents of the local ldap config file that the ldapclient command generates on Solaris machines:

# Do not edit this file manually; your changes will be lost.Please use ldapclient (1M) instead.
NS_LDAP_SERVERS= ldap.foo.bar.bla, ldap2.foo.bar.bla
NS_LDAP_SEARCH_BASEDN= dc=foo,dc=bar,dc=bla
NS_LDAP_SERVICE_SEARCH_DESC= auto_foo:nisMapName=auto.foo,dc=foo,dc=bar,dc=bla
NS_LDAP_SERVICE_SEARCH_DESC= auto_projects:nisMapName=auto.projects,dc=foo,dc=bar,dc=bla
NS_LDAP_SERVICE_SEARCH_DESC= auto_test:nisMapName=auto.test,dc=foo,dc=ucsc,dc=edu
NS_LDAP_SERVICE_SEARCH_DESC= auto_notbackedup:nisMapName=auto.notbackedup,dc=foo,dc=ucsc,dc=edu
NS_LDAP_SERVICE_SEARCH_DESC= auto_mirror:nisMapName=auto.mirror,dc=foo,dc=bar,dc=bla
NS_LDAP_ATTRIBUTEMAP= automount:automountInformation=nisMapEntry
NS_LDAP_ATTRIBUTEMAP= automount:automountKey=cn
NS_LDAP_ATTRIBUTEMAP= automount:automountMapName=nisMapName
NS_LDAP_OBJECTCLASSMAP= automount:automount=nisObject
NS_LDAP_OBJECTCLASSMAP= automount:automountMap=nisMap
NS_LDAP_SERVICE_AUTH_METHOD= pam_ldap:tls:simple
NS_LDAP_SERVICE_AUTH_METHOD= passwd-cmd:tls:simple

Basically I would like to set +auto_master in the auto_master in /etc and with the correct translations like the suns have, just get my mount info from the ldap server as needed.
Any info would be greatly appreciated

#31 Pingback By Integrating Leopard Autofs with LDAP · the occasional blog On December 9, 2007 @ 12:22 am

[…] 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“. […]

#32 Comment By rajeev karamchedu On December 9, 2007 @ 12:33 am


I have posted some Leopard specific info here


#33 Pingback By Integrating Leopard Server With Sun ONE LDAP • Netmojo Systems On March 27, 2008 @ 6:20 pm

[…] article will add to Rajeev Karamchedu’s excellent post, “Integrating Mac OS X into Unix LDAP Environment with NFS Home Directories”, only with Leopard Server instead of Tiger. My goals are a bit different from […]

#34 Pingback By Integrating Leopard Server With Sun ONE LDAP, Part 2 • Netmojo Systems On March 27, 2008 @ 10:58 pm

[…] because I’m writing as I go, and I don’t know how it will turn out. However, given that others have had success at employing this method to get NFS automounting home directories working from Solaris LDAP, there […]

#35 Comment By Peter On April 10, 2008 @ 10:26 am

Great article, although I’ve came across few problems while follwoing it.

My scenario:
SLES10 server and OSX 10.5 machines.
I’ve added apple.schema to LDAP and it’s visible.

The problem:
Nothing happens when I try to write attributes and objectclasses modifications to the server.
Nothing gets written, the window just closes on OK.

Any ideas?

#36 Pingback By Integrating Leopard Server With UNIX LDAP, Part 3 • Netmojo Systems On April 24, 2008 @ 8:01 pm

[…] start the Directory Utility application. It is in Applications -> Utilities. I basically followed Rajeev Karamchedu’s instructions, under the “Mapping Remaining Attributes and ObjectClasses” […]

#37 Comment By Ben On April 26, 2008 @ 8:31 am

I’m with Peter (April 10, 2008, 10:26 am), with an OpenLDAP 2.3 server (Debian etch) and 10.5.2 client: “Nothing happens when I try to write attributes and objectclasses modifications to the server.”
Nothing in the logs to suggest what’s up.
Thanks for the writeup though, it’s been helpful in understanding how OD differs from plain RFC2307 (which I’m now using).

#38 Comment By rajeev karamchedu On April 26, 2008 @ 9:22 pm

@Peter and @Ben

What I am unsure from your comments is whether or not a dialog box pops up when you click “Write to Server”.. This dialog box should contain fields to enter

    Distinguished Name

  • Password
  • Search Base

If the dialog box does not even show up, then I would start looking at the LDAP client configuration leading up to it.

It it does show up and you are entering values correctly (remember the search base — the client will create a ou=macosxodconfig entry under this suffix and stores its config info.), then I would check

  • Read/Write Permissions to the LDAP server with the DN/Pwd pair
  • Read/Write ACLs on the suffix being used
  • Network tracing may be in order if the above two tests check out..


(remember the SearchBase is the searchbase where the client can

#39 Comment By Ben On April 27, 2008 @ 7:17 am

>If the dialog box does not even show up…

It does, and I enter my admin credentials. Then, nada. I’m not certain I have the LDAP server’s ACLs right, though I can create anything with the same credentials under phpLDAPadmin. I’m out of time on this work right now, I hope to get another shot in the next few weeks… (I’d love to find an up to date “from zero to OpenLDAP + OS X” howto – I’ve more or less been stumbling from place to place piecing things together, no doubt I’ve missed something along the way!)

#40 Comment By rajeev karamchedu On April 27, 2008 @ 7:27 am


I am sure you have already done this but I had to ask. Once you click “Write to server” and nothing happens, have you checked the LDAP Server and see if the macosxodconfig entry gets changed ? (LDAP debug access logs should also help). Sometimes, changing a specific mapping to a bogus value and looking for that in the XML text of the macosxodconfig entry will also help…

What is not clear is

a) whether the ldap server is receiving the request at all from the client.

b) If it did receive the request, then what did the access log say..?
do you have access to the access logs on the server ?

Running tcpdump on the client will also help …


#41 Pingback By homedir On June 5, 2008 @ 7:08 am

[…] for integrating Mac OS X with Unix LDAP and NFS environment. A must-read for all Unix administratorshttp://rajeev.name/2006/09/09/integrating-mac-os-x-into-unix-ldap-environment-with-nfs-home-dir…suexec homedir – HowtoForge Forums HowtoForge – Linux Howtos and …suexec homedir […]

#42 Comment By Zach C On July 23, 2008 @ 9:36 am

Hi, Thanks for your great writeup on this topic. This definitely is the most complete and helpful article I’ve found so far.

I do have a question about extending the posix users and groups to be apple-user and apple-group objects. Do I have to add that object class to all users and groups in the directory? I only have a few users that need to use OS X and I would like to only extend those users and not every user and group. However, when I browse nfs shares, OS X can’t resolve user IDs to usernames that haven’t been made apple-users. It also can’t resolve any group names. I would have thought the posixAccount and posixGroup mappings would have taken care of this.

Upon closer inspection I see that there is a “Map to [any|all] items in this list” setting in Directory Utility. I also see that I can drag the mappings up and down (perhaps to prioritize?).

Can you shed some light on this? If I can avoid modifying every user and group account in the directory, that would be preferable.
I am running OS X 10.5.4 on the client.


#43 Comment By rajeev karamchedu On July 26, 2008 @ 6:41 am


You do not have to add this to all users. One advantage of LDAP is that objects are extensible individually. You can extend individual user object to be apple-user objects.

#44 Comment By Peter On August 2, 2008 @ 2:19 pm

in ‘Mapping Remaining Attributes and ObjectClasses’ part you’ve listed attributes that should be changed.

1. What about any already existing ones, ie: extensibleObject. Should they be removed?

2. What about ‘Map to any/all items in list’? Do they matter, and how if so?


#45 Comment By zuzana On October 23, 2008 @ 11:45 am

I’ve been working on setting up a five machine G5 10.3.9 Cluster using LDAP to NFS mount a RAID as user home directories, and NFS mount a directory existing on the LDAP master (with some programs that need to be shared) to the same location as on the master on the other 4 replica nodes. I’m trying to do this using only the Server Admin GUI and the Workgroup Manager GUI, for the users to easily be able to replicate the process should anything go down in the future.

I can create users just fine, but sharing is the difficult part that doesn’t seem to work at all. Checking off “custom mount” as the location to share anything always returns a “device busy” at the terminal on the other 4 nodes (and I assume I shouldn’t add the master’s IP to the “export to” list), and checking off “use as user home directories” for the home directories on the RAID just created new default home directory folders with owner root and doesn’t share any of the pre-existing content from the RAID to any of the other nodes. Have you ever had this problem before? I have no idea what I’m doing wrong because I think I’ve tried everything.

#46 Comment By maceis On October 30, 2008 @ 4:24 pm

I am trying to set up an LDAP environment on a Mac OS X 10.5 Client machine and also on a Mac OS X 10.4 Server machine to use it mainly for sharing contacts in a small office network. This works already but I have to create contacts on the command line which is fine for me but not acceptable for the staff.

I would like to use Directory.app for creating contacts (people and groups).
We can already read contacts (also with Mail.app and Address Book.app) but when trying to create a “New Shared Contact” I always get “An error occured during authentication – Unable to verify credentials for server myhost.mydomain.dom”

In system.log I can see (loglevel stats) a search “SRCH attr=authAuthority” which results in “SEARCH RESULT tag=101 err=0 nentries=1 text=” so I assume that there must be something missing in my setup.

I would really appreciate if anyone could give me a hint `cause I´m working an this for weeks now an I´m stuck.

Thanks in advance and best regards

#47 Comment By Chris Owens On February 27, 2009 @ 3:30 pm

Rajeev this was extremely helpful to me. Thanks!

It broke when I upgraded to 10.5. By looking at the protocol messages, I’ve come up with a few extra things that need to be done if you want WGM to play nicely under OS X 10.5.

I can’t figure out how to get the trackback thing to work properly, but my notes [18]

#48 Comment By Peter On April 17, 2009 @ 10:14 am

Following these instructions I’ve got my OSX clients authenticating against openldap on Linux box, plus nicely working PHDs.
Thanks for the instructions!

I’m battling with one problem, however;
Users in the ldap belong to multiple groups, but on the OSX only the primary group of an user is visible.

Any ideas or pointers here?


#49 Comment By mark anderson On May 27, 2009 @ 5:10 am

This is very interesting information. I just bookmarked it now.

#50 Comment By Lokke Highstein On June 1, 2009 @ 2:10 pm

This is great! Thanks for writing it up. Have you tried doing this with OpenDS 1.2 at all? I am trying to get that set up and am hoping that the schema adjustments that you made, are the same for OpenDS.

The link to the apple.schema seems to be broken now. Is there any chance I can still get a copy of that file?

#51 Comment By Juan Piñero On August 31, 2009 @ 9:33 am

Hi Rajeev
Thanks for this tutorial.
I’m very new in MacOS world and we are trying to integrate a couples of iMac into our network.
We are running Sun ONE Directory Server 5.2 and I want to authenticate mac user versus our ladp servers. Are there anything in the Mac side that can parse information from solaris schema to apple.schema? something like “NS_LDAP_SERVICE_SEARCH_DESC” in solaris or “nss_map_attribute” in linux?. I’m a bit afraid to change anything in the schema.
Another thing is I can’t access to this link “http://www.tigr.org/%7Erajeev/92apple_schema.html”

Thanks again

#52 Comment By Stephen Winnall On November 30, 2009 @ 10:36 am

I used this information to set up an ODS clone on Ubuntu 9.04 using OpenLDAP and was able to access it without problem from my Leopard clients up to 10.5.8. Thanks!

However, a machine that I have upgraded to Snow Leopard (10.6.2) – although able to see the ODS clone – seems to ignore it completely. WGM 10.6.2 won’t let me log in with the credentials which work for Leopard. The shell “id” command doesn’t return any information from the ODS clone.

I presume that Apple has changed the schemas for ODS, though the only change I have been able to identify is the introduction of apple_auxillary.schema. Adding that to my ODS clone has not solved the problem though.

Do you have any insight into what needs to be done to get an ODS clone running for Snow Leopard clients?


#53 Comment By rajeev karamchedu On November 30, 2009 @ 10:45 am

Have not had a chance to experiment with 10.6 for a while but may be this link might be of help.


#54 Comment By Bill Bradley On March 15, 2010 @ 4:15 pm

The link to apple.schema ldif is broken. does anyone have a copy?

#55 Comment By Ulrix On March 29, 2010 @ 10:02 am


your article help a lot. But I still encounter some problems. I’m trying to use NFS + Kerberos + LDAP. I’m using OS X 10.5. The LDAP users can login, but they won’t get their home directories. It seams as if the mac system isn’t even trying to mount the NFS share. The Kerberos configuration seams to be fine, because the user gets a valid ticket. Perhaps you could explain the apple-user-homeurl, homeDirectory values. I don’t quiet get it if i need the apple-user-homeurl value for nfs. Is it possible that 10.5 changed the way how you mount the home directory?

Best reagrds,


#56 Comment By Daryn On April 1, 2010 @ 1:27 am

Greetings. I found this article very informative. The article mentions: “On an OS X Server, we started the Open Directory Server and created one admin user. We then dumped the directory tree contents to a file…”. Would you please email me this file, or post a link to it?

#57 Comment By rajeev karamchedu On April 6, 2010 @ 7:18 am

I don’t have access to those files anymore – but something you can do quite easily if you have access to an Open Directory Server.. Just issue a ldapsearch command at the root of the suffix as an admin user..

#58 Comment By rajeev karamchedu On April 6, 2010 @ 7:30 am

Here are some example entries that might help you..

apple-user-homeurl: nfs://fas3170.myco.com/vol/homes /users/rajeev
homeDirectory: /home/rajeev

To understand exactly what the client is requesting from the server, my suggestion is to turn up the debug logging on the OSX LDAP server and watch the access logs.

#59 Comment By Ryan On June 8, 2010 @ 12:47 pm


Ben is not alone; 10.6 does indeed do nothing when you click “write to server”. I have run tcpdump on the client, and it does not even try to make a network connection. So sadly, I don’t think this works for 10.6, so I’ve had to resort to passing around the .plist configuration to the clients, which kinda stinks. For reference, I use SSL with my configuration and the ACL’s are correct, because if I manually update the mappings on the clients, everything works just fine.

#60 Comment By Robert On November 28, 2010 @ 8:59 pm

I’ve got most of this working but I can’t get a user’s groups to come across. Only the primary group is associated with the user on login. Any ideas?

#61 Comment By Robert On June 16, 2011 @ 11:05 pm

I can’t for the life of me get Workgroup Manager working with my CentOS openldap server. It just can’t or won’t connect. Logs don’t seem to give any clues. Is there something specific in the ldap setup that identifies an OD master as OD instead of LDAP? Is this the problem? I can’t authenticate at all yet so sticking to Apache Directory Studio.

#62 Pingback By Dentaku » Integrating Mac OS X into Unix LDAP Environment with NFS Home Directories On March 9, 2012 @ 1:19 pm

[…] Integrating Mac OS X into Unix LDAP Environment with NFS Home Directories Mac OS X and Mac OS X Server have been designed to fit into existing enterprise directory services. Apple’s extensible Open Directory architecture integrates with standards-based LDAP directory services, including Sun JAVA Enterprise Directory Server and IBM Directory Server, as well as with proprietary ones such as Microsoft’s Active Directory. […] […]

#63 Pingback By [Network Administration]: LDAP and OS X « Punctuated Noise On January 28, 2013 @ 7:51 pm

[…] I’ve gotten my LDAP directory up and running. It’s serving out the directory information, and I’ve been able to login on my Linux machine. Now, I want to get logins and home directories available on my OS X machines. This is some really good information out there on getting this working. Most of what is here is cobbled together from these sources among others: Mac OS X Server Open Directory Adminstration for Snow Leopard BackupCentral’s LDAPand Austofs for Ubuntu and Snow Leopard Rajeev Karamchedu’s excellent writeup for integrating OS X and LDAP […]

Article printed from the occasional blog: http://rajeev.name

URL to article: http://rajeev.name/2006/09/09/integrating-mac-os-x-into-unix-ldap-environment-with-nfs-home-directories/

URLs in this post:

[1] Sun ONE Administration Guide.: http://docs.sun.com/app/docs/prod/s1dirsrv#hic

[2] here: http://www.tigr.org/%7Erajeev/92apple_schema.html

[3] here: http://www.bresink.de/osx/nis.html

[4] here: http://sial.org/howto/osx/automount/

[5] here: http://www.apple.com/support/downloads/serveradmintools104.html

[6] this post: http://rajeev.name/2007/05/15/wgm-on-ldap-directory/

[7] Apple Discussions: http://discussions.apple.com/index.jspa

[8] Apple Mailing Lists: http://lists.apple.com/

[9] AFP548 Website: http://www.afp548.com/

[10] MacEnterprise Website: http://macenterprise.org/content/view/193/84/

[11] Mac OS X Server 10.4 Manuals: http://www.apple.com/support/manuals/macosxserver/

[12] Open Directory and Active Directory: http://www.macdevcenter.com/pub/a/mac/2003/08/05/active_directory.html

[13] Integrating Mac OS X And Novell eDirectory – Intro: http://archive.macosxlabs.org/documentation/directory_services/details/novell/intro.html

[14] : http://www.apple.com/macosx/leopard/

[15] : http://rajeev.nameThe apple.schema needs to be converted to ldif format before it can be imported. A formatted apple.schema can be downloaded here.

[16] : http://phpldapadmin.sourceforge.net/

[17] : http://rajeev.name/2007/12/09/integrating-leopard-autofs-with-ldap/

[18] : http://interisle.wordpress.com/2009/02/25/implementation-notes-on-os-x-105-in-an-ldap-environment/

[19] : http://images.apple.com/business/solutions/it/docs/Modifying_the_Active_Directory_Schema.pdf