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_c...@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_c...@japn.dell.com]
(Sun Jul 1 15:21:12 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #1653: [admjesse_c...@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_c...@japn.dell.com] in cache
(Sun Jul 1 15:21:12 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #1653: Object [admjesse_c...@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_c...@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_c...@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_c...@japn.dell.com:-]
(Sun Jul 1 15:21:12 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400):
Entering request [0x55f842febb50:1:admjesse_c...@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_c...@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_c...@japn.dell.com] in cache
(Sun Jul 1 15:21:12 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #1653: Object [admjesse_c...@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_c...@dell.com
(Sun Jul 1 15:21:12 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #1653: Checking negative cache for [admjesse_c...@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_c...@dell.com]
(Sun Jul 1 15:21:12 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #1653: [admjesse_c...@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_c...@dell.com] in cache
(Sun Jul 1 15:21:12 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #1653: Object [admjesse_c...@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_c...@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_c...@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_c...@dell.com:-]
(Sun Jul 1 15:21:12 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400):
Entering request [0x55f842febb50:1:admjesse_c...@dell.com@dell.com]
(Sun Jul 1 15:21:12 2018) [sssd[nss]] [sss_dp_req_destructor] (0x0400):
Deleting request: [0x55f842febb50:1:admjesse_c...@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_c...@dell.com] in cache
(Sun Jul 1 15:21:12 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #1653: Object [admjesse_c...@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_c...@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_c...@apac.dell.com
(Sun Jul 1 15:21:12 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #1653: Checking negative cache for [admjesse_c...@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_c...@apac.dell.com]
(Sun Jul 1 15:21:12 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #1653: [admjesse_c...@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_c...@apac.dell.com] in cache
(Sun Jul 1 15:21:12 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #1653: Object [admjesse_c...@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_c...@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_c...@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_c...@apac.dell.com:-]
(Sun Jul 1 15:21:12 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400):
Entering request [0x55f842febb50:1:admjesse_c...@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_c...@apac.dell.com] in cache
(Sun Jul 1 15:21:12 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #1653: Object [admjesse_c...@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_c...@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_wh...@amer.dell.com) gid=2025431(
admspike_wh...@amer.dell.com) groups=2025431(admspike_wh...@amer.dell.com
),1002(amerlinux...@amer.dell.com),1041(linux-core-engineer...@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 <sb...@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-le...@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-le...@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/
>
_______________________________________________
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://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/BKO5ZSU5AORKKVINJS4O6CZHRDXSQOF3/
