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:
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;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:That dropbox URL contains two tarballs.RHEL7_good_and_bad.tgz
RHEL8_good_and_bad.tgzIn 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).SpikeOn Wed, Oct 16, 2019 at 2:57 AM Pavel Březina <pbrezina@redhat.com> 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 <sbose@redhat.com
> <mailto:sbose@redhat.com>> 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 -- sssd-users@lists.fedorahosted.org
> <mailto:sssd-users@lists.fedorahosted.org>
> > To unsubscribe send an email to
> sssd-users-leave@lists.fedorahosted.org
> <mailto:sssd-users-leave@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
> <mailto:sssd-users@lists.fedorahosted.org>
> To unsubscribe send an email to
> sssd-users-leave@lists.fedorahosted.org
> <mailto:sssd-users-leave@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-leave@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
>