Thanks for prompt reply.

Yes, user name is strewn throughout sssd_nss.log.    Here's the last little bit:

(Sun Jul  1 15:21:12 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #1653: Checking negative cache for [admjesse_chan@japn.dell.com]
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/japn.dell.com/admjesse_chan@japn.dell.com]
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #1653: [admjesse_chan@japn.dell.com] is not present in negative cache
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #1653: Looking up [admjesse_chan@japn.dell.com] in cache
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #1653: Object [admjesse_chan@japn.dell.com] was not found in cache
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR #1653: Looking up [admjesse_chan@japn.dell.com] in data provider
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x55f842febb50:1:admjesse_chan@japn.dell.com@japn.dell.com]
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [japn.dell.com][0x1][BE_REQ_USER][name=admjesse_chan@japn.dell.com:-]
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x55f842febb50:1:admjesse_chan@japn.dell.com@japn.dell.com]
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x55f842febb50:1:admjesse_chan@apac.dell.com@apac.dell.com]
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #1653: Looking up [admjesse_chan@japn.dell.com] in cache
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #1653: Object [admjesse_chan@japn.dell.com] was not found in cache
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR #1653: Looking up admjesse_chan@dell.com
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #1653: Checking negative cache for [admjesse_chan@dell.com]
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/dell.com/admjesse_chan@dell.com]
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #1653: [admjesse_chan@dell.com] is not present in negative cache
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #1653: Looking up [admjesse_chan@dell.com] in cache
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #1653: Object [admjesse_chan@dell.com] was not found in cache
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR #1653: Looking up [admjesse_chan@dell.com] in data provider
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x55f842febb50:1:admjesse_chan@dell.com@dell.com]
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [dell.com][0x1][BE_REQ_USER][name=admjesse_chan@dell.com:-]
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x55f842febb50:1:admjesse_chan@dell.com@dell.com]
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x55f842febb50:1:admjesse_chan@japn.dell.com@japn.dell.com]
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #1653: Looking up [admjesse_chan@dell.com] in cache
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #1653: Object [admjesse_chan@dell.com] was not found in cache
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x55f842febb50:1:admjesse_chan@dell.com@dell.com]

Specifically, this user is in apac.dell.com, so I want to make sure it's querying that subdomain.  It is.

[root@spikerealmd02 sssd]# grep 'admjesse_chan.*apac' sssd_nss.log
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR #1653: Looking up admjesse_chan@apac.dell.com
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #1653: Checking negative cache for [admjesse_chan@apac.dell.com]
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/apac.dell.com/admjesse_chan@apac.dell.com]
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400): CR #1653: [admjesse_chan@apac.dell.com] is not present in negative cache
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #1653: Looking up [admjesse_chan@apac.dell.com] in cache
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #1653: Object [admjesse_chan@apac.dell.com] was not found in cache
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR #1653: Looking up [admjesse_chan@apac.dell.com] in data provider
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x55f842febb50:1:admjesse_chan@apac.dell.com@apac.dell.com]
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [apac.dell.com][0x1][BE_REQ_USER][name=admjesse_chan@apac.dell.com:-]
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x55f842febb50:1:admjesse_chan@apac.dell.com@apac.dell.com]
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #1653: Looking up [admjesse_chan@apac.dell.com] in cache
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [cache_req_search_cache] (0x0400): CR #1653: Object [admjesse_chan@apac.dell.com] was not found in cache
(Sun Jul  1 15:21:12 2018) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x55f842febb50:1:admjesse_chan@apac.dell.com@apac.dell.com]

Yes, sss is in /etc/nsswitch.conf:

[root@spikerealmd02 sssd]# grep sss /etc/nsswitch.conf
passwd:     files sss
shadow:     files sss
group:      files sss
#initgroups: files sss
#netgroup:   files sss

But I knew that already, as users in the local domain get resolved fine:

[root@spikerealmd02 sssd]# id admspike_white
uid=2025431(admspike_white@amer.dell.com) gid=2025431(admspike_white@amer.dell.com) groups=2025431(admspike_white@amer.dell.com),1002(amerlinuxeng@amer.dell.com),1041(linux-core-engineering@amer.dell.com)

Curiously, I see these local account lookups both in sssd_nss.log and in sssd_amer.dell.com.log  (AMER.DELL.COM is the local domain).  But for that   APAC user, I see the entries (above) in  sssd_nss.log, but no equiv entries in  sssd_apac.dell.com.log.

Here's the systemctl status for sssd:

[root@spikerealmd02 sssd]# systemctl status sssd
● sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2018-06-25 00:05:10 CDT; 1 weeks 0 days ago
 Main PID: 82591 (sssd)
   CGroup: /system.slice/sssd.service
           ├─82591 /usr/sbin/sssd -i --logger=files
           ├─82592 /usr/libexec/sssd/sssd_be --domain amer.dell.com --uid 0 --gid 0 --logger=files
           ├─82593 /usr/libexec/sssd/sssd_be --domain apac.dell.com --uid 0 --gid 0 --logger=files
           ├─82594 /usr/libexec/sssd/sssd_be --domain emea.dell.com --uid 0 --gid 0 --logger=files
           ├─82595 /usr/libexec/sssd/sssd_be --domain japn.dell.com --uid 0 --gid 0 --logger=files
           ├─82596 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files
           └─82597 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files

It's as if sssd_nss is properly invoking sub sssd process 82592 for amer.dell.com lookups.  But not invoking sub sssd process 82593 for apac.dell.com lookups.

Spike


On Mon, Jul 2, 2018 at 2:32 AM Sumit Bose <sbose@redhat.com> wrote:
On Sun, Jul 01, 2018 at 03:25:26PM -0500, Spike White wrote:
> sssd subject matter experts,
>
> Why is my sssd deployment not doing cross-subdomain AD authentication?
>
>
>
> *Background:*
>
> I have a parent AD domain DELL.COM with trusted subdomains AMER.DELL.COM,
> APAC.DELL.COM, EMEA.DELL.COM and JAPN.DELL.COM  Each subdomain has a
> transitive trust with DELL.COM.
>
> So all subdomains trust each other.
>
> I set up a first test VM deployment using sssd.  I set up the cross
> subdomain auth as in:
>
> https://lists.fedorahosted.org/pipermail/sssd-users/2015-February/002648.html
>
>  It worked great – allowed cross subdomain authentication.  The only thing
> it would not do was use tokengroups.  That is, the VM was fully functional,
> but I had to add ‘ldap_use_tokengroups = false’  to the sssd.conf file.
>
> My AD experts have advised me that ‘tokengroups’ are an important AD
> optimization and I should use them, if at all possible.
>
> Using ldapsearch, I was able to verify that machine account didn’t have the
> necessary privileges to query a user’s tokengroups.  Thus, the fault was
> mine – that this first sssd deployment couldn’t use tokengroups.
>
> So I did another sssd deployment, using another test VM.  Apparently, I did
> the realm join command correct this time, as it’s able to use tokengroups.
>
> BUT!  This second test VM is not allowing cross subdomain authentication
> and login.    How do I fix this so that I have use of both tokengroups and
> cross subdomain authentication?
>

...

>
> If I do the same query on the bad VM (spikerealmd02):
>
>
>
> [root@spikerealmd02 sssd]# id admjesse_chan
>
> id: admjesse_chan: no such user

How do you know that tokengroups are working if the request fails and
the lookup is not recorded in the logs?

>
>
>
> and I see nothing in the sssd_apac.dell.com.log file:
>
>
>
> [root@spikerealmd02 sssd]# grep -i admjesse_chan sssd_apac.dell.com.log
>
> [root@spikerealmd02 sssd]#

Do you see the user name in sssd_nss.log? If not, is 'sss' listed in the
passwd line of /etc/nsswitch.conf?

bye,
Sumit

>
>
>
> Please help,
>
> Spike

> _______________________________________________
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/HHNJ6AMXTSKF4UW3PLS6Y5MY5ADF6VCV/
_______________________________________________
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/BASM657T2U6AVKBKVBQVJQQ7PNVU7UC7/