[SSSD-users] Re: Why is my sssd deployment not doing cross-subdomain AD authentication?

[Spike White]

Thanks, I'll check it out.

On Sun, Jul 8, 2018 at 2:30 PM Michael Ströder  wrote:

> Disclaimer: I did not follow this thread closely.
>
> On 07/08/2018 08:06 PM, Spike White wrote:
> > Yes, most of the groups missing when I set 'ldap_use_tokengroups = true'
> > are universal groups.
>
> I vaguely remember that Volker said something about this in his FOSDEM
> talk:
>
> https://fosdem.org/2018/schedule/event/samba_authentication_authorization/
>
> See slide 12 of his presentation especially:
>
> "Domain Controllers calculate membership at login time"
>
> This could be the cause of your issues.
>
> Ciao, Michael.
>
>
___
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/7XZH6ISDE77MLTXIT6ZRWRMBKYKDQ2PE/

[SSSD-users] Re: Why is my sssd deployment not doing cross-subdomain AD authentication?

[Michael Ströder]

Disclaimer: I did not follow this thread closely.

On 07/08/2018 08:06 PM, Spike White wrote:
Yes, most of the groups missing when I set 'ldap_use_tokengroups = true' 
are universal groups.


I vaguely remember that Volker said something about this in his FOSDEM talk:

https://fosdem.org/2018/schedule/event/samba_authentication_authorization/

See slide 12 of his presentation especially:

"Domain Controllers calculate membership at login time"

This could be the cause of your issues.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature
___
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/FPJ56S2WUHS7ATPICIYU37AI2TA4NOL4/

[SSSD-users] Re: Why is my sssd deployment not doing cross-subdomain AD authentication?

[Spike White]

Yes, most of the groups missing when I set 'ldap_use_tokengroups = true'
are universal groups.I don't know where universal groups reside.
Whether it's in the parent domain (dell.com), or in the GC or where.  (I'm
not a AD expert -- I'm a Linux engineer that has has done some AD
integration over the years.)

But not all the missing groups are universal groups.  A few missing groups
for certain accounts are domain-local groups.

Surprisingly, when I set 'ldap_use_tokengroups = false', all the group
memberships for all accounts are 100% correct.  But my strong preference is
to use tokengroups (& of course, cross-domain authentication is
mandatory).

 It sounds like you're suggesting an alternative configuration that would
allow tokengroups to behave as expected.  My concern is if that alternative
configuration will break cross domain authentication again.

I will write up the details of the missing AD groups in this configuration
in the next couple of days.

Spike

On Wed, Jul 4, 2018 at 9:13 AM Sumit Bose  wrote:

> On Wed, Jul 04, 2018 at 03:24:47AM -0500, Spike White wrote:
> > Thanks for responding.
> >
> > what you said was not exactly my situation, but it got me poking around
> and
> > finally I got the configuration working.
> >
> > I find this interesting item when looking at various sssd subcommands;
> >
> > [root@spikerealmd02 ~]# sssctl domain-list
> > amer.dell.com
> > apac.dell.com
> > emea.dell.com
> > japn.dell.com
> > dell.com
> > apac.dell.com
> > emea.dell.com
> > japn.dell.com
> >
> >
> > *Why are the remote subdomains duplicated?  *
> >
> > Ultimately, this was my problem.
> >
> > When I clear my logs:
> >
> > sssctl remove-logs
> >
> >
> > and II do a: getent passwd admjesse_chan
> > which still fails.
> >
> > via 'grep -il admjesse_chan sssd_*.log',  I find string only in
> > sssd_amer.dell.com.log  and sssd_nss.log.
> >
> > sssd_apac.dell.com.log does the usual site-awareness lookup and
> identified
> > primary LDAP server optimally.  So this sssd_be subprocess is working
> > correctly.
> >
> > Yet this log file never receives a query request for '
> > admjesse_c...@apac.dell.com'.
> >
> > sssd_nss.log gets a query request for admjesse_chan.  It knows about
> remote
> > subdomains:
> >
> > (Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_set_plugin] (0x2000):
> CR
> > #1753: Setting "User by name" plugin
> > (Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_send] (0x0400): CR
> #1753:
> > New request 'User by name'
> > (Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_process_input]
> (0x0400):
> > CR #1753: Parsing input name [admjesse_chan]
> > *(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_domain_get_state] (0x1000):
> > Domain apac.dell.com  is Active*
> > *(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_domain_get_state] (0x1000):
> > Domain emea.dell.com  is Active*
> > *(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_domain_get_state] (0x1000):
> > Domain japn.dell.com  is Active*
> >
> >
> > Since admjesse_chan was specified with domain, it performs a multi-domain
> > search.  it searches local domain first.  It searches cache for
> > admjesse_c...@amer.dell.com and then data_provider first:
> >
> > (Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_parse_name_for_domains]
> > (0x0200): name 'admjesse_chan' matched without domain, user is
> admjesse_chan
> > (Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_set_name] (0x0400): CR
> > #1753: Setting name [admjesse_chan]
> > (Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_select_domains]
> (0x0400):
> > CR #1753: Performing a multi-domain search
> > (Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_search_domains]
> (0x0400):
> > CR #1753: Search will check the cache and check the data provider
> > ...
> >
> > (Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
> > CR #1753: Object [admjesse_c...@amer.dell.com] was not found in cache
> > (Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR
> > #1753: Looking up [admjesse_c...@amer.dell.com] in data provider
> >
> >
> > It dispatches to data_provider (child process sssd_be for amer.dell.com)
> > and receives successful response back (no records found):
> >
> > (Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400):
> > Creating request for [amer.dell.com
> > ][0x1][BE_REQ_USER][name=admjesse_c...@amer.dell.com:-]
> > (Wed Jul  4 01:21:34 2018) [sssd[nss]] [sbus_add_timeout] (0x2000):
> > 0x55f844a5cac0
> > (Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_dp_internal_get_send]
> (0x0400):
> > Entering request [0x55f842febb50:1:admjesse_c...@amer.dell.com@
> amer.dell.com
> > ]
> > (Wed Jul  4 01:21:34 2018) [sssd[nss]] [sbus_remove_timeout] (0x2000):
> > 0x55f844a5cac0
> > (Wed Jul  4 01:21:34 2018) [sssd[nss]] [sbus_dispatch] (0x4000): dbus
> conn:
> > 0x55f844a330f0
> > *(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sbus_dispatch] (0x4000):
> > Dispatching.*
> > *(Wed Jul  4 

[SSSD-users] Re: Why is my sssd deployment not doing cross-subdomain AD authentication?

[Sumit Bose]

On Wed, Jul 04, 2018 at 03:24:47AM -0500, Spike White wrote:
> Thanks for responding.
> 
> what you said was not exactly my situation, but it got me poking around and
> finally I got the configuration working.
> 
> I find this interesting item when looking at various sssd subcommands;
> 
> [root@spikerealmd02 ~]# sssctl domain-list
> amer.dell.com
> apac.dell.com
> emea.dell.com
> japn.dell.com
> dell.com
> apac.dell.com
> emea.dell.com
> japn.dell.com
> 
> 
> *Why are the remote subdomains duplicated?  *
> 
> Ultimately, this was my problem.
> 
> When I clear my logs:
> 
> sssctl remove-logs
> 
> 
> and II do a: getent passwd admjesse_chan
> which still fails.
> 
> via 'grep -il admjesse_chan sssd_*.log',  I find string only in
> sssd_amer.dell.com.log  and sssd_nss.log.
> 
> sssd_apac.dell.com.log does the usual site-awareness lookup and identified
> primary LDAP server optimally.  So this sssd_be subprocess is working
> correctly.
> 
> Yet this log file never receives a query request for '
> admjesse_c...@apac.dell.com'.
> 
> sssd_nss.log gets a query request for admjesse_chan.  It knows about remote
> subdomains:
> 
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_set_plugin] (0x2000): CR
> #1753: Setting "User by name" plugin
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_send] (0x0400): CR #1753:
> New request 'User by name'
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_process_input] (0x0400):
> CR #1753: Parsing input name [admjesse_chan]
> *(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_domain_get_state] (0x1000):
> Domain apac.dell.com  is Active*
> *(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_domain_get_state] (0x1000):
> Domain emea.dell.com  is Active*
> *(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_domain_get_state] (0x1000):
> Domain japn.dell.com  is Active*
> 
> 
> Since admjesse_chan was specified with domain, it performs a multi-domain
> search.  it searches local domain first.  It searches cache for
> admjesse_c...@amer.dell.com and then data_provider first:
> 
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_parse_name_for_domains]
> (0x0200): name 'admjesse_chan' matched without domain, user is admjesse_chan
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_set_name] (0x0400): CR
> #1753: Setting name [admjesse_chan]
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_select_domains] (0x0400):
> CR #1753: Performing a multi-domain search
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_search_domains] (0x0400):
> CR #1753: Search will check the cache and check the data provider
> ...
> 
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
> CR #1753: Object [admjesse_c...@amer.dell.com] was not found in cache
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR
> #1753: Looking up [admjesse_c...@amer.dell.com] in data provider
> 
> 
> It dispatches to data_provider (child process sssd_be for amer.dell.com)
> and receives successful response back (no records found):
> 
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400):
> Creating request for [amer.dell.com
> ][0x1][BE_REQ_USER][name=admjesse_c...@amer.dell.com:-]
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [sbus_add_timeout] (0x2000):
> 0x55f844a5cac0
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400):
> Entering request [0x55f842febb50:1:admjesse_c...@amer.dell.com@amer.dell.com
> ]
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [sbus_remove_timeout] (0x2000):
> 0x55f844a5cac0
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [sbus_dispatch] (0x4000): dbus conn:
> 0x55f844a330f0
> *(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sbus_dispatch] (0x4000):
> Dispatching.*
> *(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got
> reply from Data Provider - DP error code: 0 errno: 0 error message: Success*
> 
> 
> 
> So next, it searches the next domain -- emea.dell.com:
> 
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400):
> Creating request for [emea.dell.com
> ][0x1][BE_REQ_USER][name=admjesse_c...@emea.dell.com:-]
> ...
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [sbus_dispatch] (0x4000):
> Dispatching.
> *(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got
> reply from Data Provider - DP error code: 3 errno: 5 error message:
> Input/output error*
> *(Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_common_dp_recv]
> (0x0040): CR #1753: Data Provider Error: 3, 5, Input/output error*
> *(Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_common_dp_recv]
> (0x0400): CR #1753: Due to an error we will return cached data*
> (Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
> CR #1753: Looking up [admjesse_c...@emea.dell.com] in cache
> 
> 
> It catches the same I/O error when dispatching to the other
> data_providers:  apac.dell.com, japn.dell.com
> 
> So I focused on -- why are there duplicate entries in  

[SSSD-users] Re: Why is my sssd deployment not doing cross-subdomain AD authentication?

[Spike White]

Thanks for responding.

what you said was not exactly my situation, but it got me poking around and
finally I got the configuration working.

I find this interesting item when looking at various sssd subcommands;

[root@spikerealmd02 ~]# sssctl domain-list
amer.dell.com
apac.dell.com
emea.dell.com
japn.dell.com
dell.com
apac.dell.com
emea.dell.com
japn.dell.com


*Why are the remote subdomains duplicated?  *

Ultimately, this was my problem.

When I clear my logs:

sssctl remove-logs


and II do a: getent passwd admjesse_chan
which still fails.

via 'grep -il admjesse_chan sssd_*.log',  I find string only in
sssd_amer.dell.com.log  and sssd_nss.log.

sssd_apac.dell.com.log does the usual site-awareness lookup and identified
primary LDAP server optimally.  So this sssd_be subprocess is working
correctly.

Yet this log file never receives a query request for '
admjesse_c...@apac.dell.com'.

sssd_nss.log gets a query request for admjesse_chan.  It knows about remote
subdomains:

(Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_set_plugin] (0x2000): CR
#1753: Setting "User by name" plugin
(Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_send] (0x0400): CR #1753:
New request 'User by name'
(Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_process_input] (0x0400):
CR #1753: Parsing input name [admjesse_chan]
*(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_domain_get_state] (0x1000):
Domain apac.dell.com  is Active*
*(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_domain_get_state] (0x1000):
Domain emea.dell.com  is Active*
*(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_domain_get_state] (0x1000):
Domain japn.dell.com  is Active*


Since admjesse_chan was specified with domain, it performs a multi-domain
search.  it searches local domain first.  It searches cache for
admjesse_c...@amer.dell.com and then data_provider first:

(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_parse_name_for_domains]
(0x0200): name 'admjesse_chan' matched without domain, user is admjesse_chan
(Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_set_name] (0x0400): CR
#1753: Setting name [admjesse_chan]
(Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_select_domains] (0x0400):
CR #1753: Performing a multi-domain search
(Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_search_domains] (0x0400):
CR #1753: Search will check the cache and check the data provider
...

(Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #1753: Object [admjesse_c...@amer.dell.com] was not found in cache
(Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_search_dp] (0x0400): CR
#1753: Looking up [admjesse_c...@amer.dell.com] in data provider


It dispatches to data_provider (child process sssd_be for amer.dell.com)
and receives successful response back (no records found):

(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400):
Creating request for [amer.dell.com
][0x1][BE_REQ_USER][name=admjesse_c...@amer.dell.com:-]
(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sbus_add_timeout] (0x2000):
0x55f844a5cac0
(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_dp_internal_get_send] (0x0400):
Entering request [0x55f842febb50:1:admjesse_c...@amer.dell.com@amer.dell.com
]
(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sbus_remove_timeout] (0x2000):
0x55f844a5cac0
(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sbus_dispatch] (0x4000): dbus conn:
0x55f844a330f0
*(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sbus_dispatch] (0x4000):
Dispatching.*
*(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got
reply from Data Provider - DP error code: 0 errno: 0 error message: Success*



So next, it searches the next domain -- emea.dell.com:

(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_dp_get_account_msg] (0x0400):
Creating request for [emea.dell.com
][0x1][BE_REQ_USER][name=admjesse_c...@emea.dell.com:-]
...
(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sbus_dispatch] (0x4000):
Dispatching.
*(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got
reply from Data Provider - DP error code: 3 errno: 5 error message:
Input/output error*
*(Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_common_dp_recv]
(0x0040): CR #1753: Data Provider Error: 3, 5, Input/output error*
*(Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_common_dp_recv]
(0x0400): CR #1753: Due to an error we will return cached data*
(Wed Jul  4 01:21:34 2018) [sssd[nss]] [cache_req_search_cache] (0x0400):
CR #1753: Looking up [admjesse_c...@emea.dell.com] in cache


It catches the same I/O error when dispatching to the other
data_providers:  apac.dell.com, japn.dell.com

So I focused on -- why are there duplicate entries in  sssctl domain-list?
Might it be trying to dispatch to some "ghost" data_provider (non-existent
sssd_be child process)?  Thus I focused on my sssd.conf file.

i realized I don't need this line:

[sssd]
debug_level = 6
domains = amer.dell.com,apac.dell.com,emea.dell.com,japn.dell.com
*domain_resolution_order = 

[SSSD-users] Re: Why is my sssd deployment not doing cross-subdomain AD authentication?

[Sumit Bose]

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):

[SSSD-users] Re: Why is my sssd deployment not doing cross-subdomain AD authentication?

[Spike White]

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 

[SSSD-users] Re: Why is my sssd deployment not doing cross-subdomain AD authentication?

[Sumit Bose]

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/