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

[Bryce Powell <Bryce.Powell@telus.com>]

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

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