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

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:


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 <spikewhitetx@gmail.com> 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 <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
>