The first article describes how to add the appropriate Apple LDAP schema to your external directory. The second article describes how to set up appropriate partitions (e.g., cn=config, ou=MacOSX…) in your external directory to hold data from the Apple server. This article tackles the augmentation of user records in the external directory so that OSX Server recognizes them as native users.
1. Update the UNIX User Records in LDAP
First, extract a user account from Open Directory, to see what object classes and attributes Apple uses:
$ ldapsearch -v -x -D 'uid=diradmin,cn=users,dc=netmojo,dc=ca' -W -b 'dc=netmojo,dc=ca' -s sub "uid=testuser"
# testuser, users, netmojo.ca
cn: Test User
authAuthority: ;ApplePasswordServer;0x47f...,1024 35
132011037 ... firstname.lastname@example.org:123.456.789.12
;MYREALM.CA;1024 35 1320110 ... email@example.com:123.456.789.12
UNIX LDAP directories will vary widely in the type of data that they have for user accounts. I assume that your records have the usual posixAccount and shadowAccount objectclasses, as well as the standard user-account attributes, such as uid, uidNumber, gidNumber, loginShell, homeDirectory, etc.. If you want to use the full suite of services available on your Apple server, you will need to modify your user account records so that they include at least the following objectclasses and attributes:
displayName: Firstname Lastname
You can update your UNIX records using any tools that you like. You could use an LDAP editor of your choice, or the somewhat awkward tools that Sun provides with Solaris.
However, if you’re working with hundreds, or thousands of users in your UNIX directory, you’ll want to use a script to modify them automatically. I wrote this perl script to do the job. Feel free to use it, if you understand perl and know what you’re doing.
2. Update the indexes in your LDAP directory
The Apple server will perform a lot of queries on your LDAP server, so unless often-searched-for attributes are indexed, your Apple server and possibly your UNIX server will become quite sluggish. By examining the LDAP logs to see what OSX Server is searching for, we know which attributes should be indexed:
[08/Apr/2008:19:43:59 -0600] conn=13900 op=253 msgId=254 - SRCH base="ou=people,o=myorg" scope=1 filter="(&(objectClass=apple-user)(|(apple-generateduid=5408D7B6-XXXX-43C6-YYYY-549A7777688E)))" attrs="uidNumber apple-generateduid uid cn gidNumber sambaSID apple-generateduid"
[08/Apr/2008:19:44:12 -0600] conn=13900 op=255 msgId=256 - SRCH base="cn=computers,ou=macosx,o=myorg" scope=2 filter="(&(|(objectClass=apple-computer))(|(apple-generateduid=5408D7B6-XXXX-43C6-YYYY-549A7777688E)))" attrs="uidNumber apple-generateduid cn gidNumber ttl sambaSID macAddress apple-generateduid"
[08/Apr/2008:19:44:18 -0600] conn=13900 op=261 msgId=262 - SRCH base="ou=group,o=myorg" scope=1 filter="(&(objectClass=apple-group)(|(apple-serviceslocator=*mailingList*)))" attrs="cn apple-serviceslocator apple-group-memberguid apple-group-nestedgroup apple-serviceslocator"
...and so on...
To add attribute indexes with Sun ONE 5.x, start the LDAP console application,
Some of the attributes below are site-specific, and you may not even have them in your list, so ignore them. Sluggishness went away when I added many of these attributes to the index list:
Once you’ve selected added the attributes to the index list, click the Save button, then click the “Re-index suffix” button in the pop-up window. Select all or just the new indexes, and click the OK button to begin re-indexing. It’s quick and painless.
3. Bind the Apple Server to the UNIX directory
For this, you need to login to your Apple server and start the Directory Utility application. It is in Applications -> Utilities. I basically followed Rajeev Karamchedu’s instructions, under the “Mapping Remaining Attributes and ObjectClasses” heading.
One very important difference is that I’m running Directory Utility from the Leopard server that is hosting my collaboration services. So where he says “Login to the Macintosh Client”, actually login to your Leopard server.
Before you close Directory Utility, switch to it’s Search Policy tab, and make sure that your UNIX LDAP directory is listed in the search path for both Authentication and Contacts. There is a bug in the Apple teamserver that prevents authentication if the directory isn’t also in the Contacts search path. This is also probably why the inetOrgPerson, etc., objectclasses are necessary.
Once you have set up the attribute mappings, successfully bound your Leopard server to your UNIX server, and adjusted the Authentication and Contacts search paths, you should be able to access your UNIX user accounts with the native OSX tools.
4. Access the user records in Workgroup Manager
Open Workgroup Manager, and click on the Accounts tab. In the top-left, there is a tiny globe icon with a down-pointing arrow beside it. Click it.
A list of available directories should appear, and the UNIX directory that you just bound to should be among them. Select it, and your UNIX users should populate the list below. Congrats!
There is now only one more step to go to be able to assign wikis, blogs and calendars to your UNIX users: update the groups in your UNIX LDAP directory. I will cover that in my next article.
Note: If you just want users to be able to create blogs, and you’re not concerned with group blogs/wikis, you could probably add the
apple-serviceslocatorattribute to your UNIX users, and get that functionality. Copy the contents of this field from a local user on the Leopard server. If you try this, let me know how it goes! My concern has been group wikis and blogs, and I haven’t tested with lone users.