sssd experts, I think this is proper and expected sssd behavior. Since I'm using short names for all lookups, that is called a "domain-less search".
Look at https://docs.pagure.org/SSSD.sssd/design_pages/shortnames.html, where the implementation of the "shortnames in trusted domains" feature is discussed. The author explicitly says: Overview of the solution <https://docs.pagure.org/SSSD.sssd/design_pages/shortnames.html#overview-of-the-solution> In order to have it implemented a few internal changes have to be done in order to use the shared cache_req module for responder look-ups, allowing then SSSD to perform the domain-less look-ups when not explicitly set up in the domain to use only fully-qualified names for those operations. Once domain-less searches are allowed, SSSD will have to support receiving an ordered list of domains which will be looked-up first so the Administrator can have a better control and avoid a bunch of unnecessary look-ups. The list of the ordered domains can be provided in three different ways and those are described below according to their precedence order: - sssd.conf: the admin can set up the domain_resolution_order option in the [sssd] section; - ipaDomainResolutionOrder set by IPA ID-view: the admin can set up the attribute per views on IPA server; - ipaDomainResolutionOrder set globally: the admin can set up the attribute globally on IPA server; Without setting the list of ordered domains (via any of those 3 methods above), I'm thinking that SSSD should do domain-less searches in the local domain only. Which is exactly what happens. Spike On Fri, Oct 18, 2019 at 1:23 PM Spike White <[email protected]> wrote: > 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]
