On Mon, Dec 02, 2013 at 02:43:22PM +0100, Sumit Bose wrote:
On Mon, Dec 02, 2013 at 01:24:53PM +0100, Jakub Hrozek wrote:
> 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
do you mean #2, because in #1 there are no hooks?
Perhaps, or maybe a combination of #1 and #2 where we would allow
multiple results, just for a specific schema.
bye,
Sumit
> 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.
> _______________________________________________
> 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