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 _____________________________________________ From: Bryce Powell Sent: December 10, 2012 01:32 PM To: openldap-technical@openldap.org Subject: LDAP database timeout settings
Hi,
I have configured two LDAP backend databases, each pointing to a difference Active Directory domain (multiple domain controllers specified per domain). After a period of time after slapd starts, the ldap log file shows multiple entries like this for the various connections (conns=nnnn):
Dec 10 13:18:03 vmxxxldap01 slapd[7826]: conn=1004 op=27 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
Without going into too much detail regarding the configuration, I'm wondering if I need to specify LDAP database configuration settings for: idle-timeout network-timeout
man slapd-ldap:
idle-timeout <time> This directive causes a cached connection to be dropped an recreated after it has been idle for the specified time.
network-timeout <time> Sets the network timeout value after which poll(2)/select(2) following a connect(2) returns in case of no activity. The value is in seconds, and it can be specified as for idle-timeout.
I don't understand the explanation for network-timeout though, and am hoping someone can kindly explain it in more detail, and suggest a scenario for its appropriate usage.
Also, when is it appropriate to use the ldap.conf NETWORK_TIMEOUT setting?
man ldap.conf:
NETWORK_TIMEOUT <integer> Specifies the timeout (in seconds) after which the poll(2)/select(2) following a connect(2) returns in case of no activity.
Could someone please suggest the best approach for my use case? Of course, I might also be completely off the mark here ...
Thanks Bryce Powell
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 ____________________________________________
On Windows 2008R2, here are the steps. This needs done on each DC I believe.
As administrator in CMD on a DC:
ntdsutil ldap policies connections connect to server DCNAME q set MaxConnIdleTime to TIMEVALUE (we used 3600 seconds) commit changes q q
Hope that helps!
-Kyle
On Tue, Dec 11, 2012 at 9:10 AM, Matthew M. DeLoera mdeloera@exacq.comwrote:
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 ____________________________________________
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 ____________________________________________
openldap-technical@openldap.org
-
Bryce Powell -
Kyle Smith -
Matthew M. DeLoera