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>> 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-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
_______________________________________________
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
