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

Jan Zelený jzeleny at redhat.com
Wed Jun 13 12:16:12 UTC 2012


> On Wed, 2012-06-13 at 14:00 +0200, Jan Zelený wrote:
> > > On Tue, 2012-06-12 at 09:33 -0400, Stephen Gallagher wrote:
> > > > On Tue, 2012-06-12 at 15:29 +0200, Jan Zelený wrote:
> > > > > > On Tue, 2012-06-12 at 08:28 -0400, Simo Sorce wrote:
> > > > > > > On Tue, 2012-06-12 at 07:37 -0400, Stephen Gallagher wrote:
> > > > > > > > On Tue, 2012-06-12 at 10:50 +0200, Jan Zelený wrote:
> > > > > > > > > > On Mon, 2012-06-11 at 21:19 -0400, Stephen Gallagher 
wrote:
> > > > > > > > > > > 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.
> > > > > > > > > > 
> > > > > > > > > > I'm wondering if we shouldn't try at least the initgroups
> > > > > > > > > > by default. What's the error for servers that do not
> > > > > > > > > > recognize the syntax ? Can we 'probe' the syntax at
> > > > > > > > > > connection time (like we check for the rootdse) and set
> > > > > > > > > > a flag about whether it work or not ?
> > > > > > > > > > 
> > > > > > > > > > That way we can set at least
> > > > > > > > > > ldap_initgroups_use_matching_rule_in_chain = auto or
> > > > > > > > > > similar by default and have the benefit any time the
> > > > > > > > > > option is available w/o forcing the admins to find out.
> > > > > > > > > > It would be a pretty obscure toggle anyway, very few
> > > > > > > > > > would take benefit if we do not find a way to
> > > > > > > > > > auto-discover it.
> > > > > > > > > > 
> > > > > > > > > > Simo.
> > > > > > > > > 
> > > > > > > > > The auto-discovery is possible to some degree but a bit
> > > > > > > > > ugly. You can do following search [1]:
> > > > > > > > > 
> > > > > > > > > base: CN=<domain_name>,OU=Domain Controllers,<suffix>
> > > > > > > > > scope: base
> > > > > > > > > attributes: operatingSystemVersion,
> > > > > > > > > operatingSystemServicePack
> > > > > > > > > 
> > > > > > > > > And then use following condition to detect if server
> > > > > > > > > supports the feature (the code is not accurate, it only
> > > > > > > > > demonstrates the idea. Some processing of both attributes
> > > > > > > > > would be necessary beforehand):
> > > > > > > > > 
> > > > > > > > > if ((operatingSystemVersion == 3790 &&
> > > > > > > > > 
> > > > > > > > >      operatingSystemServicePack >= 2) ||
> > > > > > > > >      operatingSystemVersion > 3790)
> > > > > > > > >      
> > > > > > > > >          return true;
> > > > > > > > > 
> > > > > > > > > else
> > > > > > > > > 
> > > > > > > > >          return false;
> > > > > > > > > 
> > > > > > > > > Of course the code only detects if the AD server supports
> > > > > > > > > chaining. If there is possibilty to turn it off somehow, I
> > > > > > > > > don't know how to detect it. I checked both
> > > > > > > > > supportedControl and supportedCapabilities attributes in
> > > > > > > > > rootDSE of Stephen's testing AD server, there is no
> > > > > > > > > mention about this one.
> > > > > > > > 
> > > > > > > > This is an interesting idea, but there are still problems
> > > > > > > > with it. First, you need to identify the domain name (which
> > > > > > > > is not retrievable from the RootDSE, so you'd need to
> > > > > > > > configure that). Second, this only reports what the OS is
> > > > > > > > installed on the server, but Windows Server can be
> > > > > > > > configured to operate in compatibility mode with older
> > > > > > > > versions. (i.e. Windows 2008 R2 servers operating in Windows
> > > > > > > > 2003 compatibility mode during a phased migration).
> > > > > > > > 
> > > > > > > > So this is not sufficient information to make this
> > > > > > > > determination.
> > > > > > > > 
> > > > > > > > However! It looks like we should be able to autodetect this
> > > > > > > > by performing a request using the match rule OID. When I
> > > > > > > > tried to use it against an openldap server, I got back:
> > > > > > > > 
> > > > > > > > search: 4
> > > > > > > > result: 12 Critical extension is unavailable
> > > > > > > > text: Bad search filter
> > > > > > > > 
> > > > > > > > So this is probably sufficient to enable-disable this
> > > > > > > > feature. We need to figure out what would be a reasonable
> > > > > > > > search request to make, however.
> > > > > > > 
> > > > > > > The actual search doesn't really matter, we care only if we get
> > > > > > > back a result or an error. We could search a random user name
> > > > > > > or any other info we normally search at rootdse discovery
> > > > > > > time.
> > > > > > 
> > > > > > Well, at RootDSE discovery time, we search only the RootDSE with
> > > > > > a base search. Base searches ignore the filter, so we need to
> > > > > > make a separate request. I'm currently investigating just doing
> > > > > > a onelevel search of the user_search_base for an attribute
> > > > > > unlikely to exist. This should be sufficient.
> > > > > 
> > > > > Quoting the documentation you sent earlier:
> > > > > 
> > > > > "Note that when using LDAP_MATCHING_RULE_IN_CHAIN, scope is not
> > > > > limited—it can be base, one-level, or subtree."
> > > > 
> > > > Ah, you know what. I could have sworn I got a different result the
> > > > first time, but I just re-tested against an openldap server and did
> > > > in fact get the
> > > > result: 12 Critical extension is unavailable
> > > > when trying to use this filter.
> > > > 
> > > > So I suppose we probably can just do a second base search against the
> > > > rootdse with this specified.
> > > 
> > > Ok, I've added one new patch to the set, patch 0009. This patch makes
> > > the following additions:
> > > 1) Support for LDAP_MATCHING_RULE_IN_CHAIN is now auto-detected during
> > > the RootDSE check phase if either groups or initgroups are supported
> > > 2) The meaning of "True" for either option becomes "auto".
> > > 3) The default for initgroups is now True/Auto.
> > > 
> > > I'm also attaching a new set of performance tests I ran. I realized
> > > that my initial run was slightly flawed, in that each test was run
> > > from a fresh startup of SSSD (meaning it incurred the costs of the
> > > initial connection as well). With this second round, I first performed
> > > a 'getent passwd notarealuserinldap' before each timed test, to ensure
> > > that the SSSD was working from a live connection.
> > > 
> > > The results for groups were largely unchanged, but for initgroups it
> > > reveals something closer to a 3x performance boost in the example data
> > > set, as compared to the 2x boost seen in my first shot at this.
> > 
> > I have found no further issues with this patch set. If noone else has
> > problems with it, I give all patches ACK.
> > 
> > 
> > Please note that my ghost users patch is necessary for this to be fully
> > functional.
> 
> I thought we figured out that your ghost users patch was only relevant
> when NOT using the features provided by this patch (because we
> effectively have no nested groups when using this approach).
> 
> That said, I'll be reviewing the ghost patch today.

Sorry, I phrased that poorly. My point was that the patch is necessary for 
full testing (both with and without chaining). It was just for the record in 
order to spare time of anyone else who might want to test this.

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/20120613/98595db5/attachment.sig>


More information about the sssd-devel mailing list