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

Pavel Březina pbrezina at redhat.com
Thu Jan 30 09:52:31 UTC 2014


On 01/29/2014 04:09 PM, Sumit Bose 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.
>
> It is not disabled permanently but only for the given connection. On
> every reconnect it should be checked again. I think a periodic task is
> not needed here.

Yes, the check is performed on each new connection, however if it 
detects no POSIX attributes in GC, AD_ENABLE_GC is set to false but 
never to true again. Therefore the next tests are done only against LDAP 
-- if I'm not missing anything.

>>
>>> 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.
>>
>>> 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. :-)
>>
>>> 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
>
> yes, the fallback should be avoided but I agree with Jakub that we
> should still allow it.
>
> bye,
> Sumit
>
>> doesn't have POSIX attributes we want to go directly to LDAP on next
>> queries, don't we?
>>
>> _______________________________________________
>> sssd-devel mailing list
>> sssd-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>




More information about the sssd-devel mailing list