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 <sbose@redhat.com> 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_chan@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 <http://apac.dell.com> is Active*
> *(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_domain_get_state] (0x1000):
> Domain emea.dell.com <http://emea.dell.com> is Active*
> *(Wed Jul  4 01:21:34 2018) [sssd[nss]] [sss_domain_get_state] (0x1000):
> Domain japn.dell.com <http://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_chan@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_chan@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_chan@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_chan@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_chan@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_chan@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_chan@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 = amer.dell.com <http://amer.dell.com>,
> emea.dell.com <http://emea.dell.com>, apac.dell.com <http://apac.dell.com>,
> japn.dell.com <http://japn.dell.com>*
>
>
> As without it, it will search domains in the order listed in "domains" line.
>
> Tried that fix, made no difference.  Next I realized that
> https://lists.fedorahosted.org/pipermail/sssd-users/2015-February/002648.html
> doesn't have these lines in each of his [domain/XXX] stanzas.
>
> ad_enabled_domains = amer.dell.com,apac.dell.com,emea.dell.com,japn.dell.com
> ,dell.com
>
>
> So I removed that line from each [domain/XXX] stanza  and did a:
>
> sssctl cache-remove  (which restarts sssd service)
>
>
> Now sssctl domain-list  shows me no dups:
>
> [root@spikerealmd02 sssd]# sssctl domain-list
> amer.dell.com
> apac.dell.com
> emea.dell.com
> japn.dell.com

Thank you for the feedback, I have seen the ad_enabled_domains options
in your config file as well, but I assumed that since the subdomain
provider was disabled this is basically ignored. But as you've shown it
is not.

>
>
> Now the dispatches out of sssd_nss.log to the various data_providers
> succeed.  And I see remote users:
>
> [root@spikerealmd02 sssd]# id admjesse_chan
> uid=525641(admjesse_chan@apac.dell.com) gid=525641(
> admjesse_chan@apac.dell.com) groups=525641(admjesse_chan@apac.dell.com
> ),1008(apacunixusers@apac.dell.com),1000(apaclinuxeng@apac.dell.com),1001(
> apaclinuxsup@apac.dell.com)
>
> I still don't see all expected groups for these users, so my
> ldap_use_tokengroups is still not 100% right.  Or maybe these missing
> groups are UNIVERSAL groups and I should be additionally querying dell.com.
> Oh, well -problem for another day.  At least now x-subdomain auth is again
> working and tokengroups is (mostly) working.

As long as the missing groups are universal groups from dell.com it
might not be possible to have group memberships with them in your setup.
The tokengroups lookup will return a list of SIDs of all the groups the
user is a member of. SSSD will search in the cache or on the configured
servers for those SIDs. But you have configure each domain individually
with separate [domain/...] sections and disabled the sub-domain
provider. With this SSSD will only look for objects from the configured
domain and will not reach out to other domains.

bye,
Sumit
>
> 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/I5WEXBOQPBHE7GDT4NDM65J2UQVGTD6Z/