[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Glue, relay, chain, rwm, meta - which one?

Mitya wrote: 
Hi all,

Our OpenLDAP deployment serves multible bases (suffixes).

dc=ourcompany,dc=ru
 ou=People
  cn=john

dc=ourclient1,dc=ru
 ou=People
  cn=jim

dc=ourclient2,dc=com
 ...

dc=ourclient3,dc=net
 ...

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 = somebody@ourclient1.ru 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 "somebody@ourclient1.ru" 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)...

dc=ourcompany,dc=ru
 ou=People
  cn=john
  cn=...
 ou=Domains
  dc=ourclient1,dc=ru
   ou=People
    cn=jim

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
"(objectClass=person)".

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. 
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?

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.

--
 -- 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/