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

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

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"
%

Pages: 1 2 3 4 5