> 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 > way. > Thanks, Dan. Turning encryption off indeed circumvented the problem. It turned out that the root cause is a weak key check in RC4 that MIT Kerberos performs and that Active Directory does not perform. The discussion on the Kreberos mailing list linked below explains the matter in more detail. http://mailman.mit.edu/pipermail/krbdev/2011-March/009921.html
Attachment:
signature.asc
Description: OpenPGP digital signature