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
> > 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
> > 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.
> 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
> sssd-devel mailing list
sssd-devel mailing list