Introduction

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.

Assumptions

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

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 /etc/openldap/schema/apple.schema 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 ServerRoot/slapd-serverId/config/schema 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 99user.ldif 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’ 99user.ldif 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 92apple.ldif on the master server. This will ensure that this file will get read before the 99user.ldif. Also note that on the replica servers, you will NOT find a 92apple.ldif after performing a schema replication. Instead, all of the new schema should be found merged in 99user.ldif 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 homeDirectory to mount the NFS home directory from the server. In almost all the cases, the value for this attribute is /home/$username. 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. /Network/Servers/path/to/nfs/home/directory). Fortunately, the apple schema also includes an alternative attribute called apple-user-homeDirectory 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=People - These entries will be extended to become apple-user objects
• ou=Group - These entries will be extended to become apple-group objects
• ou=Hosts - Base 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 ;basic;.
• 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