Adding Leopard’s LDAP Container Objects to the UNIX LDAP Server

In the first article in this series, I described how to get the schema data out of Leopard and into a Sun ONE Directory Server. In this article, I’ll describe how to get the container objects out of Leopard’s LDAP server, and add them to the UNIX directory. These container objects will hopefully hold data relevant for assigning access to Apple’s Blog & Wiki server, among other things.

I say “hopefully” 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 is good reason to believe that it will work for other OSX services as well.

1. Extract the Container Objects from Leopard

This is fairly straightforward. You can use the ldapsearch command to dump the structure of your LDAP database, without the user and group data, to a file. This is all on one line:


$ ldapsearch -v -x -D 'uid=diradmin,cn=users,dc=netmojo,dc=ca' -W -b 'dc=netmojo,dc=ca' -s sub '(|(|(objectclass=container)(objectclass=organizationalUnit))(objectclass=apple-configuration))' > containers.ldif


Note that you need to put in your own directory administrator’s username after the uid=, and your own search base (mine is dc=netmojo,dc=ca). You will be prompted for your directory administrator’s password.

Now you should have a file, containers.ldif, that contains the LDAP container objects that we will be adding to your UNIX LDAP directory, under ou=macosx. You will have to do a little editing of this file, starting with adding the ou=macosx container to the top of the file.

2. Edit the Extracted LDIF Data

Open containers.ldif in your favorite text editor and add this to the top of the file:


# OSX Objects
dn: ou=macosx,o=MyORG
ou: macosx
objectClass: top
objectClass: organizationalUnit
description: Holds metadata for OSX Server


As usual, you need to substitute for your actual search base. I will be using o=MyORG as my search base on my Sun server, but yours might be something like “dc=partyhats,dc=com”. So I’m adding ou=macosx to the top-level of my LDAP base, and all of the objects listed in containers.ldif will go under it.

The next thing to do is remove the parts we don’t need, starting with the comments from the top of the file (“#extended LDIF…”).

You probably already have users in your UNIX directory in ou=People, o=MyORG, and groups in ou=Groups, o=MyORG, for example. The plan is to augment those records, so you should go ahead and remove the dn: cn=users… and dn: groups… entries from containers.ldif. When I say “entries”, I mean, for example:


# users, netmojo.ca
dn: cn=users,dc=netmojo,dc=ca
cn: users
objectClass: container


Nuke it.

The next step is to do a search & replace on the search base, so that in the ldif file, the search base is ou=macosx,[your UNIX search base]. For example, I would replace all occurrences of “dc=netmojo,dc=ca” with “ou=macosx,o=MyORG”. Then I’ll have entries such as:


# mounts, netmojo.ca
dn: cn=mounts,ou=macosx,o=MyORG
cn: mounts
objectClass: top
objectClass: container
#
# accesscontrols, netmojo.ca
dn: cn=accesscontrols,ou=macosx,o=MyORG
cn: accesscontrols
objectClass: container


You want only the containers in this file. Scroll through the file and look for entries that have actual data in them, and remove the data. They’re easy to spot, because OSX Server stores data in binary format. For example:


# macosxodconfig, config, netmojo.ca
dn: ou=macosxodconfig,cn=config,ou=macosx,o=MyORG
ou: macosxodconfig
objectClass: top
objectClass: organizationalUnit
description:: PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPCFET0NUWVBF
IHBsaXN0IFBVQkxJQyAiLS8vQXBwbGUvL0RURCBQTElTVCAxLjAvL0VOIiAiaHR0cDovL3d3dy5hc
HBsZS5jb20vRFREcy9Qcm9wZXJ0eUxpc3QtMS4wLmR0ZCI+...


Delete the description: field, and all of the data in it. Likewise with other objects that contain data:


# ldapreplicas, config, netmojo.ca
dn: cn=ldapreplicas,cn=config,ou=macosx,o=MyORG
cn: ldapreplicas
apple-xmlplist:: PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPCFET0NUW
VBFIHBsaXN0dHJpbmc+Cgk8L2FycmF5PgoJPGtleT5SvL0RURCBQTElTVCAxLjAviaHR0cDovL3d3dy
5hcHBsZS5jb20vRFREcy9Qcm9wZXJ0eUxpc3QtMS4wLmR0ZCI+CjxwbGlzdCB2ZXJzaW9uPSIxLjA
iPgo8ZGljdD4KCTxrZXk+SVBhZGRyZXNziMS4wIiBlbmNvZGluZz0iVVRGLTRyaW5nPjE5OC4x
NjEuMjkuMTg3PC9zdHJpbmc+Cgk8L2FycmF5PgoJPGtleT5SZXBsaWNhTmFtZTwva2V5PgoJPHN0c
mluZz5NYXN0ZXI8L3N0cmluZz4KCTxrZXk+UmVwbGljYXM8L2tleT4KCTxhcnJheS8+CjwvZGljdD
4KPC9wbGlzdD4K
objectClass: apple-configuration
objectClass: top
apple-ldap-replica: ldap://123.456.789.01
apple-ldap-writable-replica: ldap://123.456.789.01


Becomes:


# ldapreplicas, config, OSX Object
dn: cn=ldapreplicas,cn=config,ou=macosx,o=MyORG
cn: ldapreplicas
objectClass: apple-configuration
objectClass: top


You want just the dn, cn/ou and objectClass declarations.

Probably most of these objects are redundant and won’t be used. I don’t know which ones Mac OSX Server will expect to find when assigning permissions and setting up collaboration services, so I’m just going to add all of the containers for now. (“cn=CollabServices,cn=config” looks promising). After I actually get the services set up, maybe I’ll refine this post to include only the necessary objects.

When you’re done hacking away the data, you should have a nice lean LDIF file of around 190 lines. Remember to remove the “search result” comments from the bottom of the file:


# search result
search: 2
result: 0 Success


That will cause an error when you import the data. Here is my LDIF file, but I recommend that you make your own. Apple can and will change things, so it is best to get your info from the source.

3. Import the LDAP Objects into Your UNIX Directory Server

If you’ve followed all of the steps in the first post and in this one so far, the last step is a piece of cake. Copy your LDIF file to your UNIX server, and use ldapadd to import it:


$ ldapadd -v -h localhost -D 'cn=Directory Manager' -w - -f macosx-containers.ldif


As usual, substitute “cn=Directory Manager” for the directory administrator of your UNIX server, and substitute “macosx-containers.ldif” for your LDIF file.

If anything is out of place with the LDIF file, or if your schema import from the first post wasn’t actually successful, ldapadd will complain and die during import, which will let you know exactly where the problem is. Happy hacking :).

In my next article of this series, I’ll discuss the modification of user accounts in the UNIX LDAP directory.