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

RE: slapd-ldap: second search operation always generates error LdapErr: DSID-0C0906E8

> -----Original Message-----
> From: Bryce Powell
> Sent: January 24, 2013 08:18 AM
> To: 'Andrew Findlay'
> Cc: openldap-technical@openldap.org
> 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     |
> > -----------------------------------------------------------------------