LDAP searching has some built-in rules, one of which is the LDAP_MATCHING_RULE_IN_CHAIN.
From MSDN:
1.2.840.113556.1.4.1941 LDAP_MATCHING_RULE_IN_CHAIN This rule is limited to filters that apply to the DN. This is a special "extended" match operator that walks the chain of ancestry in objects all the way to the root until it finds a match.
They go on to say how it is intended for recursive searching, instead of going back and forth to the server:
The LDAP_MATCHING_RULE_IN_CHAIN is a matching rule OID that is designed to provide a method to look up the ancestry of an object. ... Previously, applications performed transitive group expansion to figure out group membership, which used too much network bandwidth; applications needed to make multiple roundtrips to figure out if an object fell "in the chain" if a link is traversed through to the end.
They also say it has two obvious use cases:
- check if a user "user1" is a member of group "group1"
- find all the groups that "user1" is a member of
That being said, many people have found that in practice, using LDAP_MATCHING_RULE_IN_CHAIN is much slower (in our case, a factor of 10x) than simply doing the recursive "member-of" search that the above quote says LDAP_MATCHING_RULE_IN_CHAIN was intended to replace.
So, why is the LDAP_MATCHING_RULE_IN_CHAIN approach slower? Are we missing something? Is there an edge case we don't cover? Is there any reason ever in the world to ever use the LDAP_MATCHING_RULE_IN_CHAIN, and why, if it's unnecessarily slow, isn't it fixed?
