On 01/29/2014 05:11 PM, Jakub Hrozek wrote:
On Wed, Jan 29, 2014 at 03:39:41PM +0100, Pavel Březina wrote:
> On 01/27/2014 11:33 PM, Jakub Hrozek wrote:
>> Hi,
>>
>> When the schema is set to AD and ID mapping is used, there is a one-time
>
> you wanted to say "when ID mapping is *not* used"
>
>> check ran when searching for users to detect the presence of POSIX attributes
>> in LDAP. If this check fails, the search fails as if no entry was found
>> and returns a special error code.
>>
>> If the AD identity lookup finds this error code, the GC is disabled for
>> the next search.
>>
>> The sdap_server_opts structure is filled every time a client connects to
>> a server so the posix check boolean is reset to false again on connecting
>> to the server.
>
> GC lookups should not be disabled permanently. Administrator can
> setup POSIX attribute propagation to GC any time and SSSD should
> notice it
> without restarting.
>
> So we should rather perform the check periodically and not only
> disable GC lookups, but also re-enable it if it succeeds.
See the attached patch, I added a timeout of 3600 seconds for the next
detection. I don't think we want to have the timeout configurable but
maybe we want the timeout to be reset on changing the online status as
well?
>
>> It might be better to move the check to where the rootDSE is retrieved,
>> but the check depends on several features that are not known to the code
>> that retrieves the rootDSE (or the connection code for example) such as what
>> the attribute mappings are or the authentication method that should be used.
>>
>> Currently this patch only runs the check when users are requested. It
>> would be trivial to add the same code (about 70 lines) to the group
>> request as well.
>>
>> Additionally, I wonder if the absence of POSIX attributes in GC should
>> be reported louder. Currently there is just MINOR_FAILURE.
>
> We have SSSDBG_IMPORTANT_INFO for such things.
Done.
>
>> We could go as far as report to syslog when a user or a group from
>> subdomains is requested and the GC was already disabled, but I wanted to
>> check with the other developers before implementing this.
>
> I haven't made up my mind on this question yet, but I'm more
> inclined to avoid using syslog for this situation. :-)
Yes, me too.
>
>> One additional question -- currently the AD ID provider always retries
>> in LDAP if search in GC didn't find the result. With the possibility of
>> detecting the POSIX attributes, do we want to remove this fallback if we
>> were able to run the detection and know that GC is available but doesn't
>> contain the POSIX attributes?
>>
>> I would say the fallback should stay, because there is still a chance
>> other required attribute will be missing, after all the user can
>> configure additional filter and this fallback only affects negative
>> searches.
>
> I'm not sure if I understand you. Isn't the whole point of this
> patch to actually avoid the fallback? I mean if we detect that GC
> doesn't have POSIX attributes we want to go directly to LDAP on next
> queries, don't we?
I meant the other way. Currently even if we know that GC *has* POSIX
attributes and we don't find the user in GC, we still retry LDAP. I was
wondering whether we can remove this fallback if we know that POSIX
attributes are present. But I think we shouldn't remove the fallback for
the general case because admins can still configure a custom filter in
the search base and this custom filter can contain any attributes.
Ah, OK. I agree.