On 10/24/19 6:32 AM, Spike White wrote:
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".
Yes, if you are using short names the domain_resolution_order is required.
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 <spikewhit...@gmail.com
<mailto:spikewhit...@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 <pbrez...@redhat.com
<mailto:pbrez...@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 <sb...@redhat.com
<mailto:sb...@redhat.com>
> <mailto:sb...@redhat.com <mailto:sb...@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>
> <http://amer.company.com>,apac.company.com
<http://apac.company.com>
> <http://apac.company.com>, ....
> > ...
> > [domain/amer.company.com <http://amer.company.com>
<http://amer.company.com>]
> > ....
> > [domain/apac.company.com <http://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>
<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> <http://amer.company.com>
> > ...
> > [domain/amer.company.com <http://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>
> <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>
> <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>
> <http://amer.company.com>, emea.company.com
<http://emea.company.com> <http://emea.company.com>,
> > apac.company.com <http://apac.company.com>
<http://apac.company.com>, japn.company.com
<http://japn.company.com>
> <http://japn.company.com>, company.com
<http://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>
> <mailto:sssd-users@lists.fedorahosted.org
<mailto:sssd-users@lists.fedorahosted.org>>
> > To unsubscribe send an email to
> sssd-users-le...@lists.fedorahosted.org
<mailto:sssd-users-le...@lists.fedorahosted.org>
> <mailto:sssd-users-le...@lists.fedorahosted.org
<mailto:sssd-users-le...@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>
> <mailto:sssd-users@lists.fedorahosted.org
<mailto:sssd-users@lists.fedorahosted.org>>
> To unsubscribe send an email to
> sssd-users-le...@lists.fedorahosted.org
<mailto:sssd-users-le...@lists.fedorahosted.org>
> <mailto:sssd-users-le...@lists.fedorahosted.org
<mailto:sssd-users-le...@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-le...@lists.fedorahosted.org
<mailto:sssd-users-le...@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-le...@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
