On Mon, Jul 02, 2018 at 09:52:17AM -0500, Spike White wrote:
> 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.
You should check what happens in teh sssd_apac log around the '(Sun Jul
1 15:21:12 2018)' timestamp. Maybe it is offline ('sssctl domain-status
apac.dell.com.log' might show this as well). There should be a debug
message with an offline error-code in sssd_nss.log as well.
HTH
bye,
Sumit
>
> 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/
_______________________________________________
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/X43BWGUCFVNLTAT346CQCPJZZ5QUGX2Z/
