Jakub,

Thank you to answering so promptly.  

We are currently testing this in a lab before full deployment, so I have some degree of time before we deploy sssd in a bigger context.  If you would prefer for me to work with you directly off-line, please advise.  As an example, the attached sssd_amer.dell.com.log file was originally 40 MB.  (I presume because of debugging level).  Out of respect for others on the mailing list, I severely trimmed the log file to only the lines of interest (I hope).  But it's entirely possible I may have over-trimmed.

You asked:
    Can you send logs for a single lookup of "id username" with tokengroups enabled? 

Last week, I attached the logs.  for one specific lookup.  Even though I severely trimmed the logs, it exceeded the max file size for this mailing list.

It was the  sssd_amer.dell.com.log and sssd_nss.log, for this lookup:

   [root@spikerealmd02 sssd]# id admpatrick_wheeler
   uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) groups=2604370(admpatrick_wheeler),1010(amerunixusers)

This is with ldap_use_tokengroups = True, so the above lookup is incorrect.

What it should show is:
 id admpatrick_wheeler 
uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler) groups=2604370(admpatrick_wheeler),1033(amer_server_mgmt),1003(amerlinuxsup),1010(amerunixusers)

You asked:
   Why do you disable the subdomains provider? Isn't it easier to just list
   the domains you want to enable using the ad_enabled_domains option?

   btw this can actually cause issues because the subdomains provider is
   needed to fetch the joined domain SID at least, among other things. 

When I ran with:
      ad_enabled_domains = amer.dell.com, apac.dell.com, emea.dell.com, japn.dell.com, dell.com

it broke cross-subdomain authentication.  that is, I could resolve accounts from the local domain (AMER), but not from any other domain (like apac).  When I reviewed the logs, I saw the sssd_nss.log would do a dispatch to the apac.dell.com child, but the dispatch would always fail.

In sssd_apac.dell.com.log -- the dispatch was never picked up.

I also noticed that sssctl domain-list gave me this:
amer.dell.com
apac.dell.com
emea.dell.com
japn.dell.com
dell.com
amer.dell.com
apac.dell.com
emea.dell.com
japn.dell.com

I suspect that sssd_nss was attempting to dispatch into this apac.dell.com "ghost" domain and failing.  When I removed ad_enabled_domains (& commented out dell.com as a domain), I noticed sssctl domain-list gave me the expected:

amer.dell.com
apac.dell.com
emea.dell.com
japn.dell.com

And cross-subdomain authentication worked (modulo this tokengroups problem where not all groups show up when tokengroups == True).

You stated:
> ldap_schema = rfc2307bis

Please don't set ldap_schema to anything else than 'ad' (the default) with id_provider=ad. 

Unfortunately, our erstwhile AD administrators when they extended our AD schema years ago did not use an rfc2307 schema extension.  They used a rfc2307bis schema extension instead.  

I had fits with even basic sssd AD integration until I realized this.  (I thought I was going to have to manually set up ldap_filters for the few quirky LDAP attributes associated with an account, but then I realized this conformed 100% to rfc2307bis.) When I set ldap_schema to rfc2307bis, the basic (same domain) authentication worked (without tokengroups).