> -----Original Message----- > From: Bryce Powell > Sent: January 24, 2013 08:18 AM > To: 'Andrew Findlay' > Cc: [email protected] > Subject: RE: slapd-ldap: second search operation always generates error > LdapErr: DSID-0C0906E8 > > > On Wed, Jan 23, 2013 at 09:24:59AM -0700, Bryce Powell wrote: > > > > > I have setup an LDAP proxy using OpenLDAP 2.4.23 running on CentOS > > > release 6.2 Linux 2.6.32-220.4.2.el6.x86_64. Every second search > > > operation on a connection returns an error: > > > > > > SEARCH RESULT tag=101 err=1 nentries=0 text=000004DC: LdapErr: > > > DSID-0C0906E8, > > > comment: In order to perform this operation a successful bind must be > > > completed on the connection., data 0, v1db1 > > > > You later say: > > > > > Every subsequent search operation going forward generates the same > > error. > > > > which is not quite the same. > > Agreed - that was badly worded. Every subsequent search operation, *on > that same connection*, going forward generates the same error. > > > > > In any case, the error you quote obviously comes from the remote (AD) > > server so you should focus your investigation on the link from the > OpenLDAP > > proxy to AD. > > > > > database ldap > > > readonly on > > > suffix "dc=example,dc=com" > > > # Recreate cached connection before it can be dropped by the Active > > Directory. > > > Default Active Directory timeout MaxConnIdleTime=900 > > > idle-timeout 899 > > > rebind-as-user yes > > > uri "ldap://169.254.253.228/ ldap://169.254.239.115/ > > > ldap:/ > > > /169.254.245.81/ ldap://169.254.239.91/"; > > > > I would suggest simplifying the setup to start with - cut it down to a > > single > > back-end uri and see what happens. If that works properly, then try with > > each of those URIs in turn in case one of the remote servers is set up > > differently. > > > > You should consider using tcpdump and/or wireshark to watch the traffic > > from the proxy to the remote AD servers. That will tell you what is really > > happenning on the backend links. > > > > As an aside, I would not set the idle-timeout so close to the value that the > > remote server uses. It only needs a tiny clock skew for the behaviour to > > change completely. You should also look for firewalls (both in the network > > and on the servers) and find out what they do with idle connections: it is > > usually seriously damaging to this sort of setup. > > > > Andrew > > The firewall timeouts are way longer, but good point about the idle-timeout > being so close to the AD timeout. Thanks for your input, and I'll post further > findings as I progress with the troubleshooting.
I tested various intervals for the idle-timeout directive, and the shorter the interval, the earlier the LdapErr: DSID-0C0906E8 error occurred. I also tried replacing it with the conn-ttl directive, but this also exhibited the same behaviour. There is a firewall between the LDAP proxy and the remote AD's, and the settings are as follows: * timeout conn= 12:00:00 * half-closed = 0:10:00 I went down to idle-timeout of 60 seconds, and then the LdapErr: DSID-0C0906E8 error would occur about 3 to 5 minutes after a slapd restart, under 'normal' user load. I tend to think that there is indeed an issue with the idle-timeout functionality under the version of OpenLDAP we are using. Hopefully a more recent release has addressed this. > > --Bryce > > > -- > > ----------------------------------------------------------------------- > > | From Andrew Findlay, Skills 1st Ltd | > > | Consultant in large-scale systems, networks, and directory services | > > | http://www.skills-1st.co.uk/ +44 1628 782565 | > > -----------------------------------------------------------------------
