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
,
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:
- 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 <spikewhitetx(a)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(a)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(a)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(a)lists.fedorahosted.org
> > <mailto:sssd-users@lists.fedorahosted.org>
> > > To unsubscribe send an email to
> > sssd-users-leave(a)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.fedorahoste...
> > _______________________________________________
> > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> > <mailto:sssd-users@lists.fedorahosted.org>
> > To unsubscribe send an email to
> > sssd-users-leave(a)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.fedorahoste...
> >
> >
> > _______________________________________________
> > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-leave(a)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.fedorahoste...
> >
>
>