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

Stephen Gallagher sgallagh at redhat.com
Tue Jun 12 01:19:17 UTC 2012


On Mon, 2012-06-11 at 11:06 -0400, Stephen Gallagher wrote:
> In response to your other email, I suppose I should create two options
> instead of one. One for initgroups and one for group lookups. We could
> recommend the use of the initgroups one for the general case and the
> group lookup one only in the extremely-complex nesting case.
> 
> On Mon, 2012-06-11 at 16:35 +0200, Jan Zelený wrote:
> > 
> > Ok, here is the first round. I didn't focus my review on details, just the 
> > concept and that all parts look to be sane.
> > 
> > 
> > 
> > Patch #0006:
> > see comment below. Other than that the patch is fine.
> > 
> > 
> > 
> > Patch #0007:
> > Setting ldap_use_matching_rule_in_chain should be conditionally dependant on 
> > the right schema being used (just to avoid any inconsistencies). Currently you 
> > test only for schema != rfc2307, I'd be more defensive about that.
> > 
> 
> I was remaining consistent with the current code (which assumes that
> anything that isn't RFC2307 must use the DN method of memberships). I'd
> rather leave this as-is and open a ticket to correct all such
> assumptions elsewhere.
> 
> > Definition of SDAP_AD_MATCHING_RULE would be semantically better in patch 
> > #0006.
> 
> Yeah, sorry. These were originally a single patch that I split. I should
> have moved this. I'll do so when I send the updated patches.
> 
> > 
> > attrs argument for sdap_get_ad_match_rule_members_send() Is it necessary? You 
> > don't use it anywhere.
> 
> This was just defensive programming. I can remove it if you prefer.
> 
> > 
> > I don't think your approach for copying origDN values in 
> > sdap_ad_match_rule_members_process() is correct. If user is without origDN, 
> > the sdap_nested_group_populate_users() will fail prior to your test here.
> > 
> 
> Ah, I see what you mean. I'd be leaving a NULL and effectively
> truncating the values. I suppose I should probably just fail if we don't
> have an origDN. That would be a bug anyway. The origDN should always
> exist.
> 
> > 
> > 
> > Patch #0008:
> > Preliminary Ack
> > 
> > 
> > 
> > I will do the testing during the second round. Could you please send me a 
> > config file so I don't have to set up testing AD server and can use your config 
> > instead?
> 
> Sent privately.


New patches attached, along with the results of my (limited) performance
testing.

These patches split the option into two, so it can be enabled for
initgroups or group lookups separately. The testing I did on group
lookups seems to suggest that it's a distinct performance hit.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0006-LDAP-Add-ldap_-_use_matching_rule_in_chain-options.patch
Type: text/x-patch
Size: 8551 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20120611/6416c787/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0007-LDAP-Add-support-for-AD-chain-matching-extension-in-.patch
Type: text/x-patch
Size: 18846 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20120611/6416c787/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0008-LDAP-Add-support-for-AD-chain-matching-extension-in-.patch
Type: text/x-patch
Size: 15130 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20120611/6416c787/attachment-0002.bin>
-------------- next part --------------
Tests were performed against a single-CPU VM running AD 2008 R2 with 1GB RAM. Monitoring with Windows Task Manager did not reveal any perod during which the CPU went above 35% or the RAM above 850MB.

The server was located across the internet (VPN) to simulate real-world remote network conditions.

The server has one group (topgroup) that contains 3000 test users, as well as a nesting chain of nestedgroup, topgroup, abovetopgroup, aboveabovetop and aboveeventhat. I set ldap_group_nesting_level = 10 in sssd.conf to ensure both approaches showed complete results.

The user kurashima is a direct member of nestedgroup (part of the nesting chain) and sssdgroup (no parents).

My analysis of the performance degradation with the complete id lookup is that there are three pieces to it.
1) Lookups take longer againt the AD server, as the match rule lookups are more CPU intensive. The time on the wire for each LDAP round-trip was approximately double. This is most highly-visible across the internet, as these tests were performed.
2) Switching from the ASQ lookups meant that we lost its (possibly unintended) side-effect that it can return more values than the configured paging limit. This meant more trips back across the network, made worse by 1).
3) 'id' loops through the groups. With the nested approach, if we processed a parent group in that loop before its children, we'd have a reduction in the number of round-trips to the server (since the nested processing with ASQ is relatively fast). With this match rule enabled, we don't process the nests, so we go to the LDAP server for every group we need to look up. Which because of 2) and 3) may mean a significantly longer time to respond.

===================================
== Baseline (no extensibleMatch) ==
===================================

[sgallagh at testmachine ~]# time id -G kurashima at adtest

100514 101108 101109 104696 104698 104700 104699 101110

real	0m2.426s


[sgallagh at testmachine ~]# time id  kurashima at adtestuid=101146(kurashima) gid=100514(domain users) groups=100514

(domain users),101108(sssdgroup),101109(topgroup),104696(uppergroup),104698(abovetopgroup),104700(aboveeventhat),104699(aboveabovetop),101110(nestedgroup)

real	0m10.371s


[sgallagh at testmachine ~]# time getent group aboveeventhat at adtest
...
real	0m5.198s


=================================================
== With ldap_groups_use_matching_rule_in_chain ==
=================================================

[sgallagh at testmachine ~]# time id -G kurashima at adtest

100514 101108 101109 104696 104698 104700 104699 101110

real	0m2.482s



[sgallagh at testmachine ~]# time id  kurashima at adtest

uid=101146(kurashima) gid=100514 groups=100514,101108(sssdgroup),101109(topgroup),104696(uppergroup),104698(abovetopgroup),104700(aboveeventhat),104699(aboveabovetop),101110(nestedgroup)

real	0m25.671s


[sgallagh at testmachine ~]# time getent group aboveeventhat at adtest
...
real	0m4.797s



=====================================================
== With ldap_initgroups_use_matching_rule_in_chain ==
=====================================================

[sgallagh at testmachine ~]# time id -G kurashima at adtest
100514 104698 101108 101109 101110 104699 104700 104696

real	0m1.258s


[sgallagh at testmachine ~]# time id  kurashima at adtest
uid=101146(kurashima) gid=100514(domain users) groups=100514(domain users),104698(abovetopgroup),101108(sssdgroup),101109(topgroup),101110(nestedgroup),104699(aboveabovetop),104700(aboveeventhat),104696(uppergroup)

real	0m9.425s


[sgallagh at testmachine ~]# time getent group aboveeventhat at adtest
...
real	0m5.375s


===================================
==      With both                ==
===================================
[sgallagh at testmachine ~]# time id -G kurashima at adtest
100514 104698 101108 101109 101110 104699 104700 104696

real	0m1.232s


[sgallagh at testmachine ~]# time id  kurashima at adtest
uid=101146(kurashima) gid=100514 groups=100514,104698(abovetopgroup),101108(sssdgroup),101109(topgroup),101110(nestedgroup),104699(aboveabovetop),104700(aboveeventhat),104696(uppergroup)

real	0m26.142s


[sgallagh at testmachine ~]# time getent group aboveeventhat at adtest
...
real	0m4.084s

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


More information about the sssd-devel mailing list