Ubuntu’s openldap SASL authentication mechanism

In preparation for the possibility of new users at civilfritz, I’ve been trying to set up openldap on slice1. 10.10 uses a cn=config tree to configure openldap, which I don’t have any experience with. That’s fine, but I have found it particularly difficult to find documentation about.

I eventually found OpenLDAP’s documentation on cn=config, and eventually understood that the ldif literally stored on the disk serves to define the configuration tree.

That left me still wondering how Ubuntu intends you to authenticate to the directory. It turns out that Ubuntu sets up an EXTERNAL authentication mechanism, and I found examples of its use.


It’s getting so much clearer now! I knew I wanted to learn about sasl.

It turns out that dn’s of the form uid=<username>,cn=<mechanism>,cn=auth or uid=<username>,cn=<realm>,cn=<mechanism>,cn=auth represent virtual identities that don’t actually exist in the directory. You usually set up a mapping between these virtual identities and entities stored in the directory, but the default ACL permits access explicitly to gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth. I can’t find explicit documentation about ldapi and cn=peercred,cn=external,cn=auth yet, but it appears that, when I do, it will basically just describe the virtual identity tree as an interface to access a user’s unix identity via an IPC socket.

Another update:

While it’s true that the ldif stored at /etc/ldap/slapd.d is the literal backend storage for the cn=config hierarchy, you’re not meant to modify it directly (because, for example, the server stores things that you might not specify, like a structuralObjectClass attribute). Once I figured out how to modify the directory as root, (sudo ldap${foo} -Y EXTERNAL -H ldapi:///) everything made sense.