Double-check that I have this sssd.conf right....

[Spike White]

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,apac.company.com, ....
   ...
   [domain/amer.company.com]
   ....
   [domain/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).

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
   ...
   [domain/amer.company.com]
   ldap_search_base = dc=AMER,dc=COMPANY,dc=COM

   [domain/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 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, emea.company.com,
apac.company.com, japn.company.com, company.com

Now all works 100%.

Is this all legit?  Do you see any problems with above final sssd.conf
setting?

Spike

[Sumit Bose]

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,apac.company.com, ....
>     ...
>     [domain/amer.company.com]
>     ....
>     [domain/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).
>  
>  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
>     ...
>     [domain/amer.company.com]
>     ldap_search_base = dc=AMER,dc=COMPANY,dc=COM
>  
>     [domain/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 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, emea.company.com,
>  apac.company.com, japn.company.com, 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
>  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/[e-mail]...

[Spike White]

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.

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&gt; 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,apac.company.com, ....
>  >    ...
>  >    [domain/amer.company.com]
>  >    ....
>  >    [domain/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).
>  >
>  > 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
>  >    ...
>  >    [domain/amer.company.com]
>  >    ldap_search_base = dc=AMER,dc=COMPANY,dc=COM
>  >
>  >    [domain/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 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, emea.company.com,
>  > apac.company.com, japn.company.com, 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
>  > 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/[e-mail]...
>  _______________________________________________
>  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/[e-mail]...
>

[Pavel Březina]

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:[e-mail]>> 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:[e-mail]>
>       > To unsubscribe send an email to
>      sssd-users-leave(a)lists.fedorahosted.org
>      <mailto:[e-mail]>
>       > 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/[e-mail]...
>      _______________________________________________
>      sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>      <mailto:[e-mail]>
>      To unsubscribe send an email to
>      sssd-users-leave(a)lists.fedorahosted.org
>      <mailto:[e-mail]>
>      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/[e-mail]...
>  
>  
>  _______________________________________________
>  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/[e-mail]...
>

[Spike White]

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&gt; 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:[e-mail]>> 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:[e-mail]>
>  >      > To unsubscribe send an email to
>  >     sssd-users-leave(a)lists.fedorahosted.org
>  >     <mailto:[e-mail]>
>  >      > 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/[e-mail]...
>  >     _______________________________________________
>  >     sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  >     <mailto:[e-mail]>
>  >     To unsubscribe send an email to
>  >     sssd-users-leave(a)lists.fedorahosted.org
>  >     <mailto:[e-mail]>
>  >     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/[e-mail]...
>  >
>  >
>  > _______________________________________________
>  > 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/[e-mail]...
>  >
>
>

[Spike White]

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-o...

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&gt; 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&gt; 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:[e-mail]>> 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:[e-mail]>
> > >      > To unsubscribe send an email to
> > >     sssd-users-leave(a)lists.fedorahosted.org
> > >     <mailto:[e-mail]>
> > >      > 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/[e-mail]...
> > >     _______________________________________________
> > >     sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> > >     <mailto:[e-mail]>
> > >     To unsubscribe send an email to
> > >     sssd-users-leave(a)lists.fedorahosted.org
> > >     <mailto:[e-mail]>
> > >     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/[e-mail]...
> > >
> > >
> > > _______________________________________________
> > > 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/[e-mail]...
> > >
> >
> >

[Pavel Březina]

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.htm...
>  
>  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 
>  <mailto:[e-mail]>> 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
>      <mailto:[e-mail]>> 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:[e-mail]>
>           > <mailto:[e-mail] <mailto:[e-mail]>>> 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(a)lists.fedorahosted.org
>          <mailto:[e-mail]>
>           >     <mailto:[e-mail]
>          <mailto:[e-mail]>>
>           >      > To unsubscribe send an email to
>           > sssd-users-leave(a)lists.fedorahosted.org
>          <mailto:[e-mail]>
>           >     <mailto:[e-mail]
>          <mailto:[e-mail]>>
>           >      > 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/[e-mail]...
>           >     _______________________________________________
>           >     sssd-users mailing list --
>          sssd-users(a)lists.fedorahosted.org
>          <mailto:[e-mail]>
>           >     <mailto:[e-mail]
>          <mailto:[e-mail]>>
>           >     To unsubscribe send an email to
>           > sssd-users-leave(a)lists.fedorahosted.org
>          <mailto:[e-mail]>
>           >     <mailto:[e-mail]
>          <mailto:[e-mail]>>
>           >     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/[e-mail]...
>           >
>           >
>           > _______________________________________________
>           > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>          <mailto:[e-mail]>
>           > To unsubscribe send an email to
>          sssd-users-leave(a)lists.fedorahosted.org
>          <mailto:[e-mail]>
>           > 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/[e-mail]...
>           >
>