I’ve just spent about 3 days LDAPizing several of the support apps Hacklab uses, so I thought I’d share my notes.

LDAP is Easy

LDAP is the grandaddy of centralized databases, designed in the early 90s to replace the huge, complex, and expensive X.500 directory protocols. It models the universe as a tree of entries, where each entry has a DN and a set of attributes. DNs are built by selecting an attribute to uniquely identify a given entry at its level of the LDAP tree, so an entry’s DN looks like a list of name=attribute pairs: ou=People,dc=hacklab,dc=to identifies the entry whose ou attribute is “People” and whose parent is the entry dc=hacklab,dc=to.

That’s the entire data model: a tree of dictionaries.

LDAP is Hard

LDAP itself is a only protocol, not a service for any particular use; when people talk about LDAP, what they really mean is “LDAP plus the schemata we’re using.” The schemata define what attributes a given entry can have and how they’re validated, and LDAP client applications, in turn, often expect entries to obey a given schema. Because of LDAP’s X.500 roots, there are many schemata, and it’s not always clear which ones you need for a given task.

The tools around LDAP are the other main source of frustration. While Microsoft Active Directory and the Apple Open Directory tools are extremely high-quality management tools, they’re also relatively expensive and aimed at large deployments. The open-source offerings around LDAP are almost universally very open-ended LDAP frontends. If you’re lucky, they can be customized around however you’re actually using LDAP; if you’re not, they’re barely more useful than the command-line ldap-utils.

In Practice

Hacklab’s LDAP server doesn’t have to deal with filesystem mount points, shell accounts, Windows security domains, or any of the many other things that make ActiveDirectory and OpenDirectory so complex. Instead, the LDAP server is primarily for keeping track of logins for the various website: this blog uses it, as does the wiki. This means we’re free to use a fairly simple schema.

For users, we’re using inetOrgPerson, which requires very few fields (only cn and sn), but allows many fields for identifying people. We also use the userPassword attribute to store hashed passwords, which apps check by attempting to bind to (log into) the LDAP server as that person. Groups of users are implemented as groupOfNames entries, which are barely more than a DN and a list of member DNs.

All of these structures are very simple and well-understood: inetOrgPerson and its parent classes define the attributes every address book application expects to find in LDAP address books, so the LDAP server could (were it public) be used as a Hacklab address book.

Integrating apps into LDAP was mostly very straightforward, but different apps have different ideas of what “integrated” actually means. Trac, out of the box, trusts whatever identity Apache passes it but handles authority roles internally. The plugin for pulling roles from LDAP hasn’t been updated in approximately forever, and doesn’t work with Trac 0.11. So, Trac roles are managed by Trac, and Apache only checks whether users are allowed to access Trac at all (and presents the login box). WordPress’s wpDirAuth plugin doesn’t handle role management at all, so WordPress also manages privileges itself, relying on LDAP for logins. WordPress also talks directly to LDAP, rather than using Apache’s LDAP integration.

The only real snag is user management, and I still haven’t found a good tool that doesn’t assume you’re running an enterprise with hundreds of users. The password page is a PHP script I found while googling around that I vetted for security and installed, but for actually creating new users I’ve been relying on LDAP Browser, which isn’t so much a user management tool as it is a generic LDAP query tool. Combined with some custom templates, it works, but it’s not hugely comfortable.

Using LDAP is not a magic bullet for centralizing identity data. However, it’s cut down on my own admin overhead for trac and the wiki, and it makes life easier for hacklab members by reducing the number of passwords they need to remember. I think it’s a net win.