back-meta ignoring binddn ?

[Tom Riddle <ftr@highstreetnetworks.com>]

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