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

Re: (ITS#6571) rebind-as-user only works on first connection attempt



> 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.