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 <christian(a)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(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)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.fedorahost...