[SSSD] [RFC] How to fix #2148 Individual group search returned multiple results in GC lookups

Jakub Hrozek jhrozek at redhat.com
Mon Dec 2 12:24:53 UTC 2013


On Mon, Dec 02, 2013 at 01:06:12PM +0100, Sumit Bose wrote:
> Hi,
> 
> I have two ideas how to fix #2148 "Individual group search returned
> multiple results in GC lookups".
> 
> First a short summary of the issue. In an AD forest where domain have
> hierarchical DNS name, e.g. example.com, child.example.com,
> grandchild.example.com, a global catalog search for the group 'Domain
> Users' from the domain example.com will currently return the 'Domain
> Users' groups from child.example.com and grandchild.example.com as well.
> The reason is that we are doing a LDAP sub-tree search with
> 'dc=example,dc=com' as a base which includes the bases of the other
> domains as well. Currently we fail, because we only proceed if one
> result is returned.
> 
> To solve this we can just drop the limitation that we only expect a
> single result and just process all results returned. This is currently
> already done for user lookups and has the advantage that we could easily
> implement * searches for groups, e.g. a* means find all groups where the
> name starts with an 'a'. A drawback would be that with a broken LDAP
> server, where there are multiple groups with the same name in the same
> domain we will not fail completely anymore but process the first
> returned group successfully and will fail with the second. But since we
> already said in other situation that it is the responsibility of the
> LDAP admin to makes sure that the information is consistent I think we
> can accept it here as well. Additionally this scheme has to be
> implemented wherever needed, e.g. sdap_get_initgr_user() would be the
> next candidate.
> 
> My second idea is to add a hook at all places where we expect one result
> but multiple are returned and call a provider specific function which
> can try to single out the expected result. For the time being only the
> AD provider will implement this function. For AD this function can check
> the DN component of all results following the search base. Since the dc
> attribute is not used by AD in the containers names following the search
> base all results which have dc=something following the search base must
> come from a different domain.
> 
> Originally I preferred the second one, but since I've seen that user
> lookups uses the first I'm not sure which one will be better.
> 
> Comments or alternatives are welcome.

Can we do #1 but instead of 'hooks' (I imagine function pointers) branch
based on LDAP schema and then only allow multiple objects if LDAP schema
is AD ? Then you don't have to add the complexity of hooks, which are
currently mostly used if we need to use an external library that we
don't want the LDAP provider to depend on (libndr).

In general I think we should protect against multiple results in getpwnam()
in responder code, not backend. We still can't return multiple entries
for a single get-by-name or get-by-uid request, but I think that with
Global Catalog, supporting multiple records on the provider side can't be
avoided.



More information about the sssd-devel mailing list