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

back-meta ignoring binddn ?




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