Just wanted to quickly note down a couple of things to document some configuration work I’ve been doing with OpenLDAP’s slapd-ldap (proxy) and slapd-meta backends. Both do basically the same thing, provide a virtual directory that can be used to transform entries at the attribute level, as well as to massage entry dn’s when necessary.
database meta
suffix "o=example,c=US"
uri "ldap://ldap.example.com/ou=home,o=example,c=US"
suffixmassage "ou=home,o=example,c=US" "ou=people,dc=example,dc=com"
acl-authcDN "cn=manager,dc=example,dc=com
acl-passwd secret
What this configuration results in is an OpenLDAP meta server that translates an entry like
“uid=test,ou=People,dc=example,dc=com”
into the entry
“uid=test,ou=home,o=example,c=US”
The directives are pretty much as they appear in a slapd-proxy slapd.conf, although some older code has made it necessary, for backward compatibility, to maintain some older terminology like “suffixmassage” rather than “rwm-suffixmassage”.
I’ve kind of abandoned any hope of getting either slapd-meta or slapd-ldap to solve the biggest problem I face in a heterogeneous computing environment — applications that can’t navigate complex directory hierarchies. There are a lot of them out there. From major publishers. I’d been experimenting with trying to map the complex directory structure on the Sun Directory at work to a much “flatter” space but hit a wall very quickly. The OpenLDAP Software list was initially helpful, but in the end fell short (my best guess is that there’s some weirdness in how slapd-meta interacts with Sun’s implementation of referrals in a multi-master environment — but the list moderator I was interacting with became impatient and cut off the discussion as “requiring too much effort” on their side, which was actually a refreshing, albeit still rude, break from the polite unresponsiveness I often get from commercial vendors when trying to get help on common operational issues with their products).