I also have a META database that points to the two LDAP databases, so my understanding of the flow of connections is as follows:

Client bind -> META -> LDAP1 & LDAP2 -> AD1 & AD2

, where AD1 & AD2 are the Active Directory domains that LDAP1 & LDAP2 databases respectively point to.

I added to the META database configuration:

rebind-as-user yes

, but was still seeing some entries every few minutes in the ldap log:

“In order to perform this operation a successful bind must be completed on the connection.”

So I added the same setting to both LDAP databases:

rebind-as-user yes

After restarting the slapd service, I haven’t seen any more of these errors in the log file. Am not entirely clear why this setting would be required, and am wondering what other subtle side effects might be encountered. As far as I can tell, the issue had nothing to do with timeout periods per se, and related timeout settings.

Here is the full configuration for the LDAP and META databases, if anyone would like to comment:

# AD1 proxy

database                ldap

readonly                on

suffix                  "dc=AD1,dc=local"

rebind-as-user          yes

uri                     "ldap://AD1_IPaddress1/ ldap://AD1_IPaddress2/ … ldap://AD1_IPaddressN/"

overlay                 rwm

rwm-rewriteEngine       on

(… rules removed)

# AD2 proxy

database                ldap

readonly                on

suffix                  "dc=AD2,dc=local"

rebind-as-user          yes

uri                     "ldap://AD2_IPaddress1/ ldap://AD2_IPaddress2/ … ldap://AD2_IPaddressN/"

overlay                 rwm

rwm-rewriteEngine       on

(… rules removed)

database                meta

suffix                  "dc=META,dc=local"

rootdn                  "uid=root,dc=META,dc=local"

rootpw                  "{md5}…"

rebind-as-user          yes

# LDAP1

uri                     "ldap://ldap_server_hostname/dc=LDAP1,dc=META,dc=local"

suffixmassage           "dc=LDAP1,dc=META,dc=local" "dc=AD1,dc=local"

map                     attribute uid sAMAccountName

idassert-bind           bindmethod=simple

                        binddn="cn=sa-tsr_srv,ou=service accounts,dc=AD1,dc=local"

credentials="…"

                        mode=none

idassert-authzFrom      dn.exact:"uid=root,dc=META,dc=local"

# LDAP2

uri                     "ldap://ldap_server_hostname/dc=LDAP2,dc=META,dc=local"

suffixmassage           "dc=LDAP2,dc=META,dc=local" "dc=AD2,dc=local"

map                     attribute uid sAMAccountName

idassert-bind           bindmethod=simple

                        binddn="cn=sa-tsr_srv,ou=service accounts,dc=AD2,dc=local"

credentials="…"

                        mode=none

idassert-authzFrom      dn.exact:"uid=root,dc=META,dc=local"

Thanks

From: Matthew M. DeLoera [mailto:mdeloera@exacq.com]
Sent: December 11, 2012 06:11 AM
To: Bryce Powell; openldap-technical@openldap.org
Subject: Re: LDAP database timeout settings

AD has an inactivity/idle default timeout of 900 seconds. I suspect you can google to find the setting name, and where it's stored, in your AD server(s).

Hope that helps.

- Matthew

On Dec 10, 2012, at 8:35 PM, Bryce Powell wrote:

Having done some more research, it appears that Active Directory also has some settings that could result in disconnected connections. I experimented with idle-timeout set to 30 seconds for the LDAP databases, but this seemed to exacerbate the frequency of the errors. The behaviour exhibits as ‘dead’ connections, and LDAP does not appear to attempt to re-establish these connections. Using the CentOS distro of OpenLDAP 2.4.23

Here are the slapd.conf settings:

database                ldap

readonly                on

suffix                  "dc=xyz,dc=local"

#noundeffilter           yes

#use-temporary-conn      yes

uri                     "ldap://IP1/ ldap://IP2/ ldap://3/ ldap://IPn/"

database                ldap

readonly                on

suffix                  "dc=abc,dc=adroot,dc=abc,dc=bc,dc=ca"

#noundeffilter           yes

#use-temporary-conn      yes

uri                     "ldap://IP11/ ldap://IP12/ ldap://13/ ldap://IP1n/"

I have some rewrite rules for bindDN, searchEntryDN, searchAttrDN, matchedDN, but I don’t believe these settings are relevant to the issue at hand.

Essentially I want the connections to be re-established without generating errors.

Thanks

____________________________________________