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 |