First, I’m sorry that I missed the e-mail in the moderation queue. We get a fair amount of spam and things sometimes slip through.
Yes, I must admit I got a bit confused. Is the issue related to both members in your example having the same name? IOW, if you have “everybody” and “nobody” in different subtrees, are those resolved correctly?
> On 20 May 2018, at 14:23, Christian Svensson <christian@cmd.nu> wrote:
>
> Hi sssd-users,
>
> My LDAP setup contains two bases:
> dc=office1,dc=company,dc=tld
> dc=office2,dc=company,dc=tld
>
> Groups can cross-reference other groups in the two bases, like this:
> cn=printer-access,ou=groups,dc=office1,dc=company,dc=tld
> - member: cn=everybody,ou=groups,dc=office1,dc=company,dc=tld
> - member: cn=everybody,ou=groups,dc=office2,dc=company,dc=tld
> cn=printer-access,ou=groups,dc=office2,dc=company,dc=tld
> - member: cn=everybody,ou=groups,dc=office2,dc=company,dc=tld
>
> What I'm trying achieve is to have a server belonging to office1 being able to expand all groups, even if the references are across office boundary, but only see the leaf groups that are in its own base.
>
> What I've tried is something like this:
> [domain/office1]
> debug_level = 9
> enumerate = true
> cache_credentials = true
> entry_cache_timeout = 600
> id_provider = ldap
> auth_provider = ldap
> chpass_provider = ldap
> ldap_search_base = dc=company,dc=tld
> ldap_group_search_base = dc=office1,dc=company,dc=tld
> # Also tried with:
> # ldap_group_search_base = dc=company,dc=tld?subtree?(dc:dn:=office1)
> ldap_schema = rfc2307bis
> ldap_group_member = member
> ldap_group_nesting_level = 5
> ldap_uri = ldaps://xxx
> ldap_tls_reqcert = hard
> ldap_tls_cacert = /etc/ssl/ldap-ca.crt
>
> Sadly this does not work, which I'm not that surprised over. The lookup logic reports:
> (Sun May 20 14:00:29 2018) [sssd[be[ office1]]] [sdap_save_grpmem] (0x0400): Adding member users to group [printer-access@office1]
> (Sun May 20 14:00:29 2018) [sssd[be[ office1]]] [sdap_find_entry_by_origDN] (0x4000): Searching cache for [cn=everybody,ou=groups,dc=office2,dc=company,dc=tld].
> (Sun May 20 14:00:29 2018) [sssd[be[ office1]]] [sdap_fill_memberships] (0x0080): Member [ cn=everybody,ou=groups,dc=office2,dc=company,dc=tld] was not found in cache. Is it out of scope?
>
> Looking at the way things are executed in code and logs it seems like there is no "post processing" to drop groups based on LDAP attributes, nor is there any way for me to add attributes to the full name of the resource to disambiguate them. Those are the two ways I've been attacking this, and both seems to not be supported.
>
> Are my observations correct? Is there a workaround other than making sure groups have unique names across the whole company?
>
> When groups are not colliding in name everything works just fine if I put " ldap_group_search_base = dc=company,dc=tld", but I'd prefer if I could avoid having to resort to globally unique group names.
>
> Thanks,
>
> P.S. My groups are named differently and have been renamed in the log messages. Let me know if something doesn't make sense and I might have typo'd a replacement.