Hi Jakub, On Fri, Jun 1, 2018 at 6:52 PM, Jakub Hrozek <jhro...@redhat.com> wrote:
> 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. > No worries, I thought it would take some time when I got the manual moderation message - I would have subscribed and re-sent if it would have take much longer, no hard feelings :-). > > > 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? > If I understand your question, yes - it's related to having the same name of sorts, but only indirectly. The naive search base would be the common ancestor DN, which would be in this example dc=company,dc=tld. Given that sssd-ldap says: "Note: It is unsupported to have multiple search bases which reference identically-named objects (for example, groups with the same name in two different search bases). This will lead to unpredictable behavior on client machines." that scares me a bit (problem 1) - but also because I want to limit the amount of groups the servers are exposed to when belonging to office1 and office2 in this case (problem 2). If I change the name of the groups to be everybody-office1 etc. (unique names across the common ancestor) everything works (solved problem 1) but problem 2 still remains. Actually, the above solution is what we're currently running while I try to figure out if it's feasible to take this a step further to solve problem 2. That's why I want to see if I can limit the search base to be limited to office1 yet still offer full expansion. Does that make sense or did I just make it less clear? :-) I've since found the dynlist overlay in OpenLDAP which may solve this need by having OpenLDAP flatten the group membership attribute, which would then make this work as I want if I set the per-office search base. But if SSSD can/should do it by itself that would of course be neater for me. Chris
_______________________________________________ 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/BMF77LEKFNKPK4GDFQTQCNB2Q5HT6FVC/
