5:35 p.m.
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(a)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
6:10 a.m.
New subject: 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
____________________________________________
10:28 a.m.
New subject: LDAP database timeout settings
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(a)exacq.com>wrote:
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
____________________________________________
10:45 a.m.
New subject: LDAP database timeout settings
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(a)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
____________________________________________
3941
days inactive
3941
days old
openldap-technical@openldap.org
3 comments
3 participants
participants (3)
-
Bryce Powell -
Kyle Smith -
Matthew M. DeLoera