Full_Name: Marcel Wysocki
Version: 2.4.22
OS: Solaris/Linux
URL:
ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (88.79.126.162)
Hello,
i have the same problem as described here:
http://www.openldap.org/lists/openldap-software/200712/msg00283.html
here are some logs:
@(#) $OpenLDAP: slapd 2.4.22 (Jun 4 2010 11:56:46) $
slapd starting
Initial connection:
##########################
conn=1000 fd=11 ACCEPT from IP=127.0.0.1:45654 (IP=0.0.0.0:389)
conn=1000 op=0 BIND
dn="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz"
method=128
conn=1000 op=0 BIND
dn="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz"
mech=SIMPLE ssf=0
conn=1000 op=0 RESULT tag=97 err=0 text=
##########################
First ldapsearch:
##########################
conn=1000 op=2 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3
filter="(mobile=491721000227)"
conn=1000 op=2 SRCH attr=objectclass
conn=1000 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=
##########################
backend server has been restarted, sencond ldapsearch:
##########################
conn=1000 op=3 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3
filter="(mobile=491721000227)"
conn=1000 op=3 SRCH attr=objectclass
conn=1000 op=3 ldap_back_retry: retrying URI="ldap://10.2.163.13:389"
DN="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz"
conn=1000 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text=
##########################
backend server has been stopped, third ldapsearch, fails as it should:
##########################
conn=1000 op=4 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3
filter="(mobile=491721000227)"
conn=1000 op=4 SRCH attr=objectclass
conn=1000 op=4 ldap_back_retry: retrying URI="ldap://10.2.163.13:389"
DN="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz"
conn=1000 op=4 SEARCH RESULT tag=101 err=52 nentries=0 text=
##########################
backend server has been restarted, fourth ldapsearch, rebind fails:
##########################
conn=1000 op=5 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3
filter="(mobile=491721000227)"
conn=1000 op=5 SRCH attr=objectclass
conn=1000 op=5 ldap_back_dobind_int:
DN="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" without creds,
binding anonymously
conn=1000 op=5 SEARCH RESULT tag=101 err=0 nentries=0 text=
##########################
following the configuration for back-ldap:
database ldap
suffix "o=bazbaz"
uri ldap://10.2.163.13:389
rootdn "cn=PEX,o=bazbaz"
rootpw secret
idle-timeout 301
rebind-as-user yes
single-conn yes
chase-referrals no
acl-bind bindmethod=simple
binddn="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz"
credentials=supersecret
I don't clearly see why you consider this behavior incorrect. As soon as
the client receives a err=52 (LDAP_UNAVAILABLE), the connection is
compromised. Back-ldap destroys the cached connection, since it does not
work. As a consequence, the related credentials are forgotten. The
client should give up, as the proxy already retried and failed (if it
succeeded, the whole point would be moot, as the client wouldn't even know
that the connection between the proxy and the remote server was broken).
p.