Nested LDAP groups and filtering

[Christian Svensson]

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.

[Jakub Hrozek]

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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]....

[Christian Svensson]

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

[Jakub Hrozek]

> 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 why I want to see if I can limit the search base to be limited to office1 yet still offer full expansion.

OK, so the search base only points to office1 subtree but office1 objects have members pointing to office2? Then SSSD wouldn’t be able to reach the objects from office2 which explains the message you are seeing..
> 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