[SSSD] [PATCH] LDAP: Detect the presence of POSIX attributes

Pavel Březina pbrezina at redhat.com
Thu Jan 30 13:16:11 UTC 2014


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.




More information about the sssd-devel mailing list