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