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

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

Mitya wrote: 
Howard, thank you for your response.

You're very welcome.
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?
I haven't looked at Courier, you'd have to ask that question in a Courier support forum. 

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.

I suppose we should add more examples to the manpages or the FAQ. The basic use is, e.g.

 database hdb
 suffix o=foo,o=bar
 ...
 overlay chain
 chain-uri ldap://host.domain:port/

This would implement chaining on a single backend, targeted to a single destination. The chain-uri directive isn't actually necessary, since the chain overlay can just parse the destination directly from the referral.

Note that you must configure OpenLDAP slapd with --enable-ldap so that the back-ldap backend is built, since the chaining function is integral to back-ldap.
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?
The example wasn't very clear, you mentioned that the request comes in with uid=somebody and returns a result with cn=somebody. What's really in the users' entry, uid or cn or both?

For glue, configure Courier with a search base of "" and glue all your databases into one:

database bdb
suffix dc=ourcompany,dc=ru
subordinate

database bdb
suffix dc=ourclient1,dc=ru
subordinate

database bdb
suffix dc=ourclient2,dc=com
subordinate

database bdb
suffix dc=ourclient3,dc=net
subordinate

database bdb
suffix ""

It occurs to me that if Courier is searching a single baseDN for everyone, then the glue approach is less desirable because it will fan out the search to all the backends, even though only one of them can hold the answer. The better approach here would be to use the relay backend, and have it select an appropriate target based on the search request. Unfortunately, the information needed to massage the searchDN is in the searchFilter, and that info isn't evaluated until after the searchDN has already been processed. I think we need an enhancement to rwm to provide the searchFilter as a predefined parameter in the searchDN context. Then you would be able to do something like this

database relay
suffix ou=Domains
rwm-rewriteEngine on

rwm-rewriteContext searchDN
rwm-rewriteRule "^ou=Domains$" "${*searchFilter},$0" ":"
rwm-rewriteRule "^(uid=.+@ourclient1),ou=Domain$" "dc=ourclient1,dc=ru" ":"
rwm-rewriteRule "^(uid=.+@ourclient2),ou=Domain$" "dc=ourclient2,dc=com" ":"
rwm-rewriteRule "^(uid=.+@ourclient3),ou=Domain$" "dc=ourclient3,dc=net" ":"
rwm-rewriteRule "^(uid=.+@ourcompany),ou=Domain$" "dc=ourcompany,dc=ru" ":"

Then you just point Courier at "ou=Domains" with a search filter of (uid=user@domain) and the proper result will come back.

But since the searchFilter is not available at searchDN evaluation, the above won't work. Instead you need to do something a bit more complicated, which I'm not going to present here because it's ugly and inefficient...

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