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(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel