[SSSD] [PATCHES][PRELIMINARY] Add support for AD's chain matching filter

Jan Zelený jzeleny at redhat.com
Mon Jun 11 13:12:54 UTC 2012


> This is the second set of patches. These aren't quite ready for a
> complete review. They are functional, but they need some discussion.
> 
> These patches attempt to implement
> https://fedorahosted.org/sssd/ticket/1367.
> 
> For details on the "magic" filters, see
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa746475%
> 28v=vs.85%29.aspx (http://goo.gl/Czjlf if that doesn't come through
> email well).
> 
> 
> 
> Patch 0001: Add new option "ldap_use_matching_rule_in_chain". This patch
> is very incomplete. It only adds the new option. It is missing
> SSSDConfig API entries and manpages. It is included because it's
> necessary to test the other two patches.
> 
> 
> 
> Patch 0002: Add support for the chain matching filter when performing
> group lookups. This is the contentious patch. It works, but it does not
> have the performance gain I might have expected. I need to do some
> re-testing on beefier hardware, but this approach has two major
> performance downsides compared to the existing approach.
> 
> 1) The existing approach takes advantage of the ASQ lookup, which (by
> accident or design on Microsoft's part) ignores the limits on page size
> per lookup. As a result, we can do a single lookup for all of the users
> at a particular nesting level. With the match filter, we have to use the
> paging control and request additional pages (meaning additional
> round-trips). Net result is that the existing approach is faster for the
> common case (only one or two nestings).
> 
> 2) This is the bigger issue, though it may be a flawed test (I'll
> explain in a moment). In addition to multiple round-trips to the server,
> each round-trip in my tests was taking between 2x and 3x the time to
> return. I suspect that this may be due in part to the fact that my
> target server was a fairly wimpy CPU-and-memory VM, but it does reveal
> that lookups using this filter against very large groups causes a
> significantly increased strain on the AD server.
> 
> With both of those downsides in mind, I'm considering scrapping this
> portion of the solution. Additional input is welcome.

Well, the document on MSDN states clearly that this operation is likely to be 
CPU-consuming when performed on subtrees. However I wouldn't drop it entirely. 
As you have mentioned, the ASQ search works for some unclear reason. Knowing 
Microsoft, this can change any time. Therefore making the 
LDAP_MATCHING_RULE_IN_CHAIN disabled by default and optional for users that 
require it is the right way to follow.

Of course this is based on the assumption that the ASQ search is just a way 
that that works "for some reason". If you can find any document stating that 
ASQ search without page size limit is supported, we can safely drop this new 
chaining search.

> Patch 0003: Add support for the chain matching filter when performing
> initgroups lookups. This patch is much more performant (due in large
> part to the fact that in the average case, the set of groups a user
> belongs to will almost always fall within a single paged search). With
> this patch, I consistently see 'time id -G <username>' reduced by 50%.
> That makes this patch a clear performance victory in my mind.


Thanks
Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20120611/c144f2b8/attachment.sig>


More information about the sssd-devel mailing list