- 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 | 64 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:
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
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)
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
|LDAP Object Class Name||Schema|
|apple-user||Apple Extended Schema|
|apple-group||Apple Extended Schema|
|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|
|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.
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
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
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.
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. 
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 . 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:
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.
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: firstname.lastname@example.org 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
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 :
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 ^D 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  and here .
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)
For the sake of brevity, I am only listing the attributes that you need to change
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
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.
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.
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
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  and run on any mac desktop that is configured with LDAP services. Please follow to this post  to read more about how to setup and use the WGM with LDAP.
Integrating Mac OS X into Unix LDAP Environment with NFS Home Directories:HowTo Series:Rajeev Karamchedu
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:
 Sun ONE Administration Guide.: http://docs.sun.com/app/docs/prod/s1dirsrv#hic
 here: http://www.tigr.org/%7Erajeev/92apple_schema.html
 here: http://www.bresink.de/osx/nis.html
 here: http://sial.org/howto/osx/automount/
 here: http://www.apple.com/support/downloads/serveradmintools104.html
 this post: http://rajeev.name/2007/05/15/wgm-on-ldap-directory/
 Apple Discussions: http://discussions.apple.com/index.jspa
 Apple Mailing Lists: http://lists.apple.com/
 AFP548 Website: http://www.afp548.com/
 MacEnterprise Website: http://macenterprise.org/content/view/193/84/
 Mac OS X Server 10.4 Manuals: http://www.apple.com/support/manuals/macosxserver/
 Open Directory and Active Directory: http://www.macdevcenter.com/pub/a/mac/2003/08/05/active_directory.html
 Integrating Mac OS X And Novell eDirectory – Intro: http://archive.macosxlabs.org/documentation/directory_services/details/novell/intro.html
 : http://www.apple.com/macosx/leopard/
 : 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.
 : http://phpldapadmin.sourceforge.net/
 : http://rajeev.name/2007/12/09/integrating-leopard-autofs-with-ldap/
 : http://interisle.wordpress.com/2009/02/25/implementation-notes-on-os-x-105-in-an-ldap-environment/
 : http://images.apple.com/business/solutions/it/docs/Modifying_the_Active_Directory_Schema.pdf