[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Glue, relay, chain, rwm, meta - which one?
Howard, thank you for your response.
> 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)...
I had a suspicion that SASL can cope with that, but haven't got
sufficient knowledge of SASL principles. I'll investigate this.
As for "legacy", surely I've misused the word. I'm not a native speaker,
as you might guess ;) sorry for that. When talking about integration, we
usually have "native" subsystems (they do something natively), and
everything other is "legacy" and it usually takes some efforts to make
them interoperate. In this case, Courier accepts only one base DN in its
authdaemond-ldap configuration, thus limiting any further LDAP operation
to this base. Will SASL really overcome this limit?
> 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.
So, how do we enforce chaining within arbitrary backend (ldbm, bdb, hdb)
in >= 2.3.6? Yes, in my case this will be the worst solution, but this
mechanism itself is very important.
> 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.
Thank you for the tip. Can I ask your please for a usage exapmle for
both facilities (glue and relay) concerning LDAP structure given above?
Regards,
Mitya