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

Stephen Gallagher sgallagh at redhat.com
Wed Jun 13 12:04:17 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.
-------------- 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/20120613/3d6af3cc/attachment.sig>


More information about the sssd-devel mailing list