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

Simo Sorce simo at redhat.com
Tue Jun 12 12:28:59 UTC 2012


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.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list