Re: the best and the shortest way ?

[Pierangelo Masarati <ando@sys-net.it>]

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 :
> 
> 1) 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
> 
> 2) 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
> 
> 3) 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.