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/

Reply via email to