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

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


> 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.

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/beb94789/attachment.sig>


More information about the sssd-devel mailing list