[Date Prev][Date Next]
Glue, relay, chain, rwm, meta - which one?
Our OpenLDAP deployment serves multible bases (suffixes).
We are on a way of integration of most our services with LDAP.
Modern software like Jabberd2 can derive base DN from username. For
example, when JID = email@example.com logs on, Jabber server takes
"ourclient1.ru", looks up the appropriate base DN in its config file,
gets dn="dc=ourclient1,dc=ru", searches this base for an entry with uid
== somebody, and rebinds with
dn="cn=Somebody,ou=People,dc=ourclient1,dc=ru", thus making possible
LDAP authentication against multiple base DNs (important!)
Legacy software like Courier mail server is not aware of multiple base
DNs. In order to make use of LDAP authentication in Courier, we
introduce "ou=Domains,dc=ourcompany,dc=ru", and try to make all other
suffixes available under this DN. Like this:
The scheme needs not be exactly like the above. We just want
"cn=jim,ou=People,dc=ourclient1,dc=ru" and others to be returned when
ldapsearch'ing -b "ou=Domains,dc=ourcompany,dc=ru" -s sub
I will ask you please to help me choose the appropriate combination of
OpenLDAP mechanisms to accomplish this.
Once I thought that putting referrals to ou=Domains,dc=ourcompany,dc=ru
and making slapd chase them internally with slapo-chain will help. But
now I see that slapo-chain (as of 2.3.6) is deprecated, moved to
back_ldap, and controlled by some LDAP_CONTROL_X_CHAINING_BEHAVIOR, and
enabled only in devel builds. Is there any way to enforce server-side
chaining, like it was in <= 2.3.4? (In this case we just have to process
referrals internally, because we cannot rely on referral handling on
client-side - in most cases client software like Courier or Apache is
not aware of referrals, and ignores them.)
Seems like any other way will lead to additional database (of type
relay, ldap or meta) per served suffix. Or maybe slapo-glue or slapo-rwm
will help here?
Thanks in advance!