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 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 doesn't have
POSIX attributes we want to go directly to LDAP on next queries, don't we?
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel