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