Julien Oix wrote:
Hi everyone,
I'm stopped with technical stuff tryin' to deploy a specific backend meta.
(see here : http://www.openldap.org/lists/openldap-software/200701/msg00190.html
and here : http://www.openldap.org/lists/openldap-software/200701/msg00272.html )
With respect to the above, I don't see the point in what you're trying to do above (apart that the acl-authcDN and acl-passwd statements are obsolete, you should use acl-bind instead). In fact, the acl-bind identity is used in case ACL checking requires access to the database, e.g. to evaluate group membership and so. Your ACLs, although naive and stuffed with all typical newbie errors (like "by * none", "by <rootdn> write" and so on) do not contain any data dependent rules.
So iI will try to explain what I want, and maybe what I'm tryin' to do is not the best way :)
This makes sense: explain the problem, not your solution.
The background :
- there is a general openldap directory existing D1,
First of all, don't use back-meta, unless you need to blend multiple targets. Use back-ldap instead.
on which I just have a system account to read its data --> no anonymous bind permitted to access the data, I need to call ldapsearch this way to retrieve any results :
ldapsearch -x -D "cn=toto,ou=system,dc=univ-paris7,dc=fr" -w xxxx -H ldaps://ldap.univ-paris.fr -b "ou=people,dc=univ-paris7,dc=fr" cn mail -LLL
- the fact is that I need authentication datas
what is authentication datas? Do you need to have entries with a userPassword attribute that are not in D1?
on people who are not in that directory D1, so I have to build my own ldap directory D2; and I don't want any data redundancy between D1 and D2 --> D1 (union) D2 = empty set
- to have an unique way to get authentication in Apache for example, in
order that people from D1 AND D2 can access, I've been thinkin' that the best solution was to deploy a openldap meta backend D3 that would transmit the authentication requests both to D1 and D2. --> D1 and D2 are D3's targets.
Is this the simplest way ? are there any solutions to implement that ?
The technical stuff
See the previous posts to see what stops me. Directory with anonymous binds don't have any problems to be targeted, but as soon as authentication is needed, access is refused whenever I give a dn to authenticate ...
What you need is NOT acl-*, it's idassert-* to have all requests authenticate as some privileged identity and then assert the client's identity as appropriate (assuming the remote server supports RFC 4370 proxied authorization; otherwise, you can still use idassert without authorization, but in this case the remote server will only see the privileged identity the proxy binds as).
You can avoid D3 and add the proxy backend directly on D2 (assuming it's a {d|r}ecent version of OpenLDAP; I suggest 2.3.33 because it contains a significantly enhanced version of back-ldap and back-meta). Then glue the proxy and the D2 database using slapo-glue(5) (all you need to do is add "subordinate" to the database that's subordinate to the other.
For example:
database ldap suffix "ou=people,dc=univ-paris7,dc=fr" subordinate uri "ldaps://ldap.univ-paris.fr" idassert-bind bindmethod=simple binddn="cn=toto,ou=system,dc=univ-paris7,dc=fr" credentials=xxxx mode=self flags=non-prescriptive # more proxy database stuff...
database bdb suffix "dc=univ-paris7,dc=fr" # more local database stuff...
Note that if the remote server can't recognize proxied authorization, change "mode=self" into "mode=none"; all operations directed towards the remote target with an identity that's not defined on that target will use the "cn=toto,ou=system,dc=univ-paris7,dc=fr" identity (so, don't use the rootdn of that DB...). The "flags=non-prescriptive" means that anonymous is allowed, and idassert is ignored for anonymous ops. The default in fact consists in bouncing anonymous ops. Finally, you can add ACLs as desired. Remember, however, that as indicated in slapd-ldap(5) and slapd-meta(5), proxy backends basically ignore ACLs; they're honored by the frontend when returning search results.
p.