[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: AD sporadically gives LDAP_SERVER_DOWN after the first request

On 21/03/11 17:17 +0100, Markus Sander wrote:
My employer ships software for Linux and other Unix-like OSes that binds
to Active Directory in order to, basically, integrate it to AD.
Functionally, it is not too dissimilar to pam_krb5 and nss_ldap.
OpenLDAP 2.4.18 is used to bind to Active Directory LDAP servers.
Authentication (to a machine trust account) is done using a Kerberos
keytab. MIT Kerberos is used.

Group membership data are stored in LDAP objects of class Group which
have the `member' attribute (multiply) filled with the DN of all
members. Those DNs are of type Group or of type User (I'm just chasing
users for now), and their `sAMAccountName' value is what I need to give
to NSS as the group member's name.

My procedure is as follows: First, I bind to one of several configured
LDAP servers using SASL2/GSSAPI, i.e. Kerberos 5. Then I inquire all of
the result set's `member' attributes and resolve the resulting DNs one
by one to build a DN => sAMAccountName map in memory (that's about 10k
entries, so, not a problem here). Then, I request the actual group
entries and look up the DNs in the `member' attribute in the map. Last,
the connection is terminated.

The group members' `sAMAccountName' is inquired one by one with the base
set to the DN (which I already know), the scope set to flat, and the
filter set to (objectClass=*). So that's about 10k single queries in
quick succession. The whole group query typically takes about 6 seconds.

The problem is: OpenLDAP sometimes gives me LDAP_SERVER_DOWN during the
`sAMAccountName' queries. This occurs sporadically but then typically
for the rest of the `sAMAccountName' queries. The group entry query that
follows does succeed. Most of the time the first of those errors
immediately follows a GSSAPI error, nameley, DES key is a weak key,
which may be true but appears unrelated, since only AES512, AES256 and
HMAC are used in the keytab.

You could set a security property of 'maxssf=0' on the client end, to
disable the sasl security layer, and use a network capture utility to get
an independent view of what's going on.

Our Active Directory 2003 R2 server at work supports turning it off this

Dan White