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.
Update:
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.