[SSSD-users] Re: Nested LDAP groups and filtering
> On 2 Jun 2018, at 10:24, Christian Svensson wrote: > > Hi Jakub, > > On Fri, Jun 1, 2018 at 6:52 PM, Jakub Hrozek 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 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.” This is indeed not supported in SSSD because internally the users are all put into a flattened database where the DN of the object (the sssd database is LDAP-like) is something like cn=username,dc=groups,dc=$domain,dc=sysdb. So two objects with the same name would be stored with the same DN.. > 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
[SSSD-users] Re: Nested LDAP groups and filtering
Hi Jakub, On Fri, Jun 1, 2018 at 6:52 PM, Jakub Hrozek 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 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] Re: Nested LDAP groups and filtering
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 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/
