On Mon, Oct 07, 2019 at 09:53:35AM -0500, Spike White wrote: > All, > > I worked an sssd configuration case with my OS vendor in the last 3 weeks. > I have resolution and it's working 100% correctly. > > Just wanted to double-check. A second set of eyes to verify this solution > is all above board. > > The problem manifested itself in our multi-domain AD forest with Posix > Attributes. One parent domain that has a transitive trust with 4 > (regional) child domains. > > Thus all 4 child domains trust each other. All users and groups are stored > in the 4 child domains. > > The original problem was that I was disabling subdomains_provider and > explicitly defining each of the 4 child domains. I had: > > domains = amer.company.com,apac.company.com, .... > ... > [domain/amer.company.com] > .... > [domain/apac.company.com] > ... > > That worked great -- for everything except universal groups. Universal > groups exist in the first domain in which they're created, but they're > replicated to each domain. However, each child domain for this group's > membership only has the local users of that domain. The full universal > group membership is stored only in the global catalog (GC). > > The problem? The GC lookups are done in the subdomain_provider's code. So > by disabling subdomains_provider, I was disabling GC lookups. Thus, I was > getting the group membership only of the first child domain queried ( > amer.company.com). > > What that amounted to is that remote support personnel couldn't log into > local boxes, because they weren't listed in the allowed groups. > > So I re-wrote the sssd.conf file and only explicitly defined the one local > child domain. I left on subdomain_provider, so it auto-discovered the > other domains (sssctl domain-list confirms this). > > Like this: > > domains = amer.company.com > ... > [domain/amer.company.com] > ldap_search_base = dc=AMER,dc=COMPANY,dc=COM > > [domain/amer.company.com/apac.company.com] > ldap_search_base = dc=APAC,dc=COMPANY,dc=COM > > So then, universal groups showed all memberships. The only remaining > problem was that now it was only searching the amer.company.com child > domain. So while a remote user was listed as a member of an allowed > universal group, the details of that user's account was not known. > > I couldn't add these auto-discovered domains to the "domains" line. (only > domains explicitly defined in sssd.conf file are allowed in this line > apparently). But I was able to add: > > domain_resolution_order = amer.company.com, emea.company.com, > apac.company.com, japn.company.com, company.com > > Now all works 100%. > > Is this all legit? Do you see any problems with above final sssd.conf > setting?
Hi, the changes are ok. However in theory both are not needed. The ldap_search_base should be discovered automatically and domain_resolution_order is only needed if you want SSSD to search the different domains in exactly that order, without SSSD should still search all domains until a matching user or group is found, but the order is not defined. bye, Sumit > > Spike > _______________________________________________ > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org _______________________________________________ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
