Wikimedia Bugzilla is closed!

Created attachment 9896 [details]
Patch for boost the nested group search for a specific user in a Active Directoy tree. Against r90286 version of LdapAuthentication extension.

Hi there.

Where I work (Statoil ASA) we use Mediawiki 1.18.0 with the LdapAuthentication Extension (v1.2e) for internal projects. We use authentication against Active Directory, and also Kerberos for clients who supports it.

In our AD structure we have a lot of nested groups, and not to mention a very large AD/LDAP database. This gave us some challenges when we wanted to restrict access to the wiki so that only users who was an indirect member of a AD group got access. By using the $wgLDAPGroupSearchNestedGroups = array('mydomain.com' => true) we instruct the extension to do a recursive function call resolving all groups the user is a member of, thus resulting in a lot of LDAP query calls.

In my case I experienced that the authentication process took between 6-8 seconds. Even though this only happened the first time you log on, or if your cookies timed out, the delay was way to big.

After digging into the problem, it was quite clear that the initial nested group resolving through recursive ldap query calls where causing the delay. I did a lot of debugging through the linux "ldapsearch" tool, and from there on inspecting the LDAP attributes/objects AD gave me. After (a lot!) of googling I found a MSDN webpage describing Microsofts AD LDAP Search Filter Syntax [1]. On that webpage it was a table with some "Matching rule OID's". Especially one matchine OID rule caught my attention; LDAP_MATCHING_RULE_IN_CHAIN. 

By using that "search filter" rule, I did the nested group resolving in a single LDAP query. Here is an example with the Linux "ldapsearch" tool:
#$ ldapsearch -x -D "ldap-bind-user" -H ldap://my-ad-server.mycompany.com/ -b "dc=mycompany,dc=com" "(&(sAMAccountName=MyWindowsUsername)(memberof:1.2.840.113556.1.4.1941:=cn=MyGroup,ou=TopGroups,ou=groups,dc=mycompany,dc=com))" -W

If user "MyWindowsUsername" is a direct member of a group, and that group again is member of the "cn=MyGroup,ou=TopGroups,ou=groups", the LDAP query will return that to us. If not, no results. Very nice, and blazing fast! I went from 6-8 seconds to 230 ms..


Note: I used a snapshot created from http://www.mediawiki.org/wiki/Special:ExtensionDistributor/LdapAuthentication. It was based on r90286, Mediawiki 1.18.

I've attached my diff/patch. It probably needs to refactoring to get it smoothly integrated with the rest of the features of LdapAuthentication extension. Would be great if others could test this patch also.

To "enable the patch", place this in your LocalSettings.php, and patch your LdapAuthentication.php with the attachement:
$wgLDAPSearchAttributes = array('mycompany.com' => 'sAMAccountName');
$wgLDAPGroupUseRetrievedUsername = array('mycompany.com' => false);
$wgLDAPGroupObjectclass = array('mycompany.com' => 'group');
$wgLDAPGroupAttribute = array('mycompany.com' => 'member');
$wgLDAPGroupNameAttribute = array('mycompany.com' => 'cn');

$wgLDAPUseLDAPGroups = array('mycompany.com' => true);
$wgLDAPGroupsUseMemberOf = array('mycompany.com' => true ); 

// search in nested groups
$wgLDAPGroupSearchNestedGroups = array('mycompany.com' => true);
$wgLDAPGroupSearchNestedGroupsAD = array('mycompany.com' => true ); // key variable!

// An array of the groups the user is required to be a member of
$wgLDAPRequiredGroups = array(
  'mycompany.com' => array(
   "CN=MyGroup,OU=TopGroups,OU=GROUPS,DC=mycompany,DC=com",
    ) ,
);


[1] http://msdn.microsoft.com/en-us/library/aa746475%28VS.85%29.aspx