[Date Prev][Date Next]
Re: 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:
First of all, the best solution here is to use SASL binds. The LDAP
client just sends the username "firstname.lastname@example.org" to the LDAP
server and the details of how the username are matched to a user entry
are entirely managed by the LDAP server. I'm surprised you refer to
Courier as a "legacy" system since it appears that it is still a pretty
active open source project. Any LDAP-enabled software that claims to
support LDAPv3 should support SASL binds (since SASL binds are a
mandatory-to-implement feature of LDAPv3)...
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.)
slapo-chain is not deprecated. It was originally a component of
back-ldap and has always depended on back-ldap's code for its own
functionality. It was split out on its own for a while, and we decided
that it was better to leave it in back-ldap where it was originally
developed. It is not LDAP_DEVEL only, it is automatically enabled
whenever back-ldap is enabled.
Of course, referrals and chaining are probably the worst-performing way
to accomplish what you want.
Glueing subordinates is an obvious approach. (Note that early 2.3
releases changed the glue syntax from the one used in OpenLDAP 2.1-2.2.
The current 2.3.7 release restores the old syntax, and slapo-glue is no
longer a separate module. It is integrated back into the slapd core,
just like it was in OpenLDAP 2.1 and 2.2.) The relay database would be a
good alternative. Either one should work well for this situation.
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?
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/