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.
> On 20 May 2018, at 14:23, Christian Svensson <christ...@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. 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? > > _______________________________________________ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/TBUDKSJXU43XL4X3FMVGKCPJQOMVFNPZ/ _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/CF4RXQXBRLKRIKRL2FBLO3KBEUMC7N3W/