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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
