Pavel and sssd mailing list team members, OK -- I have reproduced this behaviour as requested. I set debug_level = 0x3ff0? for both cases - when the option is set and when it is not.
I have done this for both a RHEL7 server and a RHEL8 server. (Same behavior on both OS versions.) Here is the dropbox URL with the tarballs of the logs: https://www.dropbox.com/sh/yqb4poh9ny9hypg/AAA71mXPDFvZcIThXKofOmVRa?dl=0 That dropbox URL contains two tarballs. RHEL7_good_and_bad.tgz RHEL8_good_and_bad.tgz In each tarball, there's a "good" folder (with domain_resolution_order set in sssd.conf file) and a "bad" folder (without domain_resolution_order set in sssd.conf file). Spike On Wed, Oct 16, 2019 at 2:57 AM Pavel Březina <[email protected]> wrote: > On 10/11/19 6:28 PM, Spike White wrote: > > Without domain_resolution_order set, it does not search the non-local > > domain and find any non-local accounts. (This is on RHEL7 and RHEL8). > > > > So -- domain_resolution_order is required. > > Can you send us sssd_nss.log and sssd_$domain.log logs generated with > debug_level = 0x3ff0? Ideally for both cases - when the option is set > and when it is not. > > > I suspected ldap_search_base would be auto-discovered. However, I got > > lost when parsing the default setting of ldap_search_base in the > > sssd.conf man page: > > > > Default: If not set, the value of the defaultNamingContext > > or namingContexts attribute from the RootDSE of the LDAP > > > > server is used. If defaultNamingContext does not exist or has an empty > > value namingContexts is used. The > > > > namingContexts attribute must have a single value with the DN of the > > search base of the LDAP server to make this work. > > > > Multiple values are are not supported. > > > > > > Spike > > > > PS Thanks for responding. > > > > > > On Wed, Oct 9, 2019 at 11:47 AM Sumit Bose <[email protected] > > <mailto:[email protected]>> wrote: > > > > 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 > > <http://amer.company.com>,apac.company.com > > <http://apac.company.com>, .... > > > ... > > > [domain/amer.company.com <http://amer.company.com>] > > > .... > > > [domain/apac.company.com <http://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 <http://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 <http://amer.company.com> > > > ... > > > [domain/amer.company.com <http://amer.company.com>] > > > ldap_search_base = dc=AMER,dc=COMPANY,dc=COM > > > > > > [domain/amer.company.com/apac.company.com > > <http://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 > > <http://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 > > <http://amer.company.com>, emea.company.com <http://emea.company.com > >, > > > apac.company.com <http://apac.company.com>, japn.company.com > > <http://japn.company.com>, company.com <http://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 -- [email protected] > > <mailto:[email protected]> > > > To unsubscribe send an email to > > [email protected] > > <mailto:[email protected]> > > > 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/[email protected] > > _______________________________________________ > > sssd-users mailing list -- [email protected] > > <mailto:[email protected]> > > To unsubscribe send an email to > > [email protected] > > <mailto:[email protected]> > > 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/[email protected] > > > > > > _______________________________________________ > > sssd-users mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > 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/[email protected] > > > >
_______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
