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

Re: back-meta ignoring binddn ?

binddn has nothing to do with binds; it has to do
with ACL checking and those operations that require
the proxy server to retrieve some privileged info
from the remote server.  As a consequence, if you
bind to server A as X and X gets resolved to server B,
your bind is propagated there; other targets get bound
anonymously.  Note that back-meta does not (yet?)
support auth proxying.

If you need to bind to each remote server as an
applicative identity, you may exploit the pseudorootdn
feature.  For all those remote servers that have
valid pseudorootdn and pseudorootpw config directives,
when binding as rootdn to the back-meta, the bind gets
propagated to the remote servers with these administrative
identities (which should be remote administrative
identities).

I'm not sure whether porting the back-ldap proxy auth
stuff to back-meta would fix your problem; I haven't
investigated it yet.  In case, an appropriate setup
of subordinate back-metas should work for you, since
it appears that you have very well separate and tree
structured naming contexts in your setup.

p.

>
> I'm trying to setup a distributed DIT using either back-ldap or
> back-meta and am having trouble getting the backend to use the correct
> dn when binding to the target.
>
> My setup contains 3 servers: serverA, serverB, serverC on seperate
> machines, all running Fedora Core 1.0 with openldap-2.1.22.  I want
> serverA to contain the root and a local branch, and proxy for remote
> branches on serverB and serverC.
>
> o=XYZ
> -ou=siteA
> --ou=People
> -ou=siteB
> --ou=People
> -ou=siteC
> --ou=People
>
> slapd.conf files are detailed below.  I have populated the servers with
> sample entries and everything looks fine if I don't go through the
> proxy.  So, for example if I do:
>
> % ldapsearch -x -W -D "cn=buser2,ou=People,ou=siteB,o=XYZ" -b
> 'ou=siteB,o=XYZ' -s sub -H ldap://serverB/
>
> or
>
> % ldapsearch -x -W -D "cn=buser2,ou=People,ou=siteB,o=XYZ" -b
> 'ou=siteC,o=XYZ' -s sub -H ldap://serverC/
>
> I get what I expect.  But if I do the following:
>
> % ldapsearch -x -W -D "cn=buser2,ou=People,ou=siteB,o=XYZ" -b 'o=XYZ' -s
>  sub -H ldap://serverA/
>
> I get results from serverA and serverB but nothing from serverC.  If I
> try to bind as a user from siteC I get results from serverA and serverC,
>  nothing from serverB.
>
> Looking in the debug log for serverB I see:
> conn=8 fd=7 ACCEPT from IP=192.168.0.95:32893 (IP=0.0.0.0:389)
> conn=8 op=0 BIND dn="cn=buser2,ou=People,ou=siteB,o=XYZ" method=128
> conn=8 op=0 BIND dn="cn=buser2,ou=People,ou=siteB,o=XYZ" mech=simple
> ssf=0 conn=8 op=0 RESULT tag=97 err=0 text=
> conn=8 op=1 SRCH base="ou=siteb,o=xyz" scope=2 filter="(objectClass=*)"
> conn=8 op=1 SEARCH RESULT tag=101 err=0 nentries=12 text=
> conn=8 op=2 UNBIND
> conn=8 fd=7 closed
>
> In serverC debug log:
> conn=6 fd=7 ACCEPT from IP=192.168.0.95:32894 (IP=0.0.0.0:389)
> conn=6 op=0 BIND dn="" method=128
> conn=6 op=0 RESULT tag=97 err=0 text=
> conn=6 op=1 SRCH base="ou=sitec,o=xyz" scope=2 filter="(objectClass=*)"
> conn=6 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=
> conn=6 op=2 UNBIND
> conn=6 fd=7 closed
>
>
> Neither of these bind dn are the binddn specified in the slad.conf at
> serverA.  It seems that back-meta is ignoring my binddn specification ?
>  If I comment out the binddn line I get the same results.  What I would
> really like is for it to bind to serverC with the same dn it used to
> bind to serverB.  I also tried using two back-ldap stanzas instead of
> one back-meta stanza, but got the same results.  What am I doing wrong ?
>
> Thanks for any light you can shine on this.
>
> Configuration details follow:
>
> serverA slapd.conf:
> access to dn.subtree="ou=siteA,o=XYZ"
>     by self write
>     by anonymous auth
>     by set="this->userList->roleOccupant&user" read
>
> access to dn.subtree="o=XYZ"
>     by self write
>     by anonymous auth
>     by users read
>
> database ldbm
> suffix "ou=siteA,o=XYZ"
> rootdn "cn=admin,ou=People,ou=siteA,o=XYZ"
> rootpw ...
> subordinate
> directory /var/lib/ldap
> index objectClass eq
> index cn eq,subinitial
>
> database meta
> suffix "o=XYZ"
> uri ldap://serverB/ou=siteB,o=XYZ
> binddn "cn=admin,ou=People,ou=siteB,o=XYZ"
> bindpw ...
> uri ldap://serverC/ou=siteC,o=XYZ
> binddn "cn=admin,ou=People,ou=siteC,o=XYZ"
> bindpw ...
>
> serverB slapd.conf:
> access to dn.subtree="o=XYZ"
>         by self write
>         by anonymous auth
>         by set="this->userList->roleOccupant&user" read
>
> database ldbm
> suffix "ou=siteB,o=XYZ"
> rootdn "cn=admin,ou=People,ou=siteB,o=XYZ"
> rootpw ...
> directory /var/lib/ldap
> index objectClass eq
> index cn eq,subinitial
>
> database ldap
> suffix "o=XYZ"
> uri ldap://serverA
> lastmod off
>
> serverC slapd.conf same as serverB with obvious name substitutions.
>
> --
> Tom Riddle
> HighStreet Networks
> www.highstreetnetworks.com


-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it