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] 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 database ldap readonly on suffix "dc=abc,dc=adroot,dc=abc,dc=bc,dc=ca" #noundeffilter yes #use-temporary-conn yes 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 ____________________________________________ |