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

Jan Zelený jzeleny at redhat.com
Tue Jun 12 13:29:39 UTC 2012


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

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


More information about the sssd-devel mailing list