Accidental LDAP

I'll be the first to admit that I knew very little about LDAP. That has since changed, but not by choice. This article is a summary of what I have learned during a migration from IBM Tivoli Directory Server to Microsoft AD/AM.

What is it?

LDAP is an acronym for Lightweight Directory Access Protocol, but it's not as simple as it sounds. It makes one wonder how complex DAP might be. In abstract terms, LDAP is an object database. It can store and retrieve all kinds of objects, such as strings, numbers, images, etc. It's commonly used to store user information, like a sophisticated address book.

DN, CN, attributes and all that

You might have heard LDAP aficionados mention DNs, CNs and so on. It sounds like another language (which it is), but it's really not as complicated as you might think. LDAP stores objects. Objects contain attributes. Attributes are like properties of the object. DN and CN are two common properties of LDAP objects. DN is special: it's the Distinguished Name, or the unique identifier for an object. It's analogous to a primary key in a relation database. CN is short for Common Name, it's a common attribute in many LDAP objects, but it's nothing special. Objects follow a schema, which describes mandatory and optional attributes of an object. Each object contains a special attribute called objectClass that refers to the class of the object, just like a class in many object oriented languages.

Attributes have a type, which is called the syntax. This is also defined by the schema.

Isn't LDAP a standard?

Like many standards, there's theory and then there's practice. In theory, any two LDAP servers can do the same thing with the same data. In practice, it's not so simple. For example, if you wanted to migrate from one LDAP server to another, you should be able to export the schema and data from one LDAP and import it into another. This is common practice, using a standard file format known as LDIF.

The problem is that LDAP migration is so infrequent, e.g. it's almost never done, that few people remember all the details of the process. This was the beginning of a long journey into the black of LDAP for me. I think I have learned enough about LDAP at this point to write my own LDAP server.

Recently, I had the enviable position of migrating from IBM Tivoli Directory Server to Microsoft ADAM. These are both free products, so you can download and install them if you like. ADAM is particularly lightweight, it's very easy to install. I can't say the same for Tivoli.

First, I tried exporting the schema from Tivoli and importing into ADAM. I didn't get past line 1 in the LDIF file before ADAM started spewing every error imaginable. It turns out the schema was not compatible with ADAM. Fortunately, Microsoft includes a utility called ADSchemaAnalyzer that can translate schemas from another LDAP server into a schema better suited for ADAM. This was just what I needed. There was one problem: ADSchemaAnalyzer threw an internal exception and gave up when presented with the Tivoli schema. I was back to square one.