Bug 1212610

I checked log files without any workaround recommended by you. The issue is not related to tokengroups.

The Clean-up task is executed 10 seconds after start of sssd. It removes inactive users and entries from sssd cache. The groups are missing just sometimes due to perfect timing between starting sssd and executing command "id user". It might happen more often for user with many groups. In this case, it took 3 seconds to download 123 groups from AD (123 LDAP searches have to be done). So there is high probability that clean-up task will be started between resolving groups and will remove unlinked groups.

I would recommend to remove all "workarounds" and disable the clean-up task.

man sssd-ldap says: 
       ldap_purge_cache_timeout (integer) 
           Determine how often to check the cache for inactive entries (such 
           as groups with no members and users who have never logged in) and 
           remove them to save space. 
                                                                               
           Setting this option to zero will disable the cache cleanup 
           operation. 
                                                                               
           Default: 10800 (3 hours) 

Please put "ldap_purge_cache_timeout = 0" into domain section.
If it does not help then there is also another problem. So please provide new log files.

I could not see any problem in log files.

I have a few ideas which can helps us to identify problem.
We will need to see a dump of sssd cache to confirm there isn't any change before and after authentication.

Please:
* install package ldb-tools.
* run "id ${username}" command after starting sssd
* dump sssd cache before authentication
   ldbsearch -H /var/lib/sss/db/cache_${domain_name} > /tmp/dump_before
* try to authenticate
* dump sssd cache after authentication
   ldbsearch -H /var/lib/sss/db/cache_${domain_name} > /tmp/dump_after
* print just GIDs returned by id command
  id --groups ${username}

NOTE: Customer does not use pam_sss for authentication. They are using pam_krb5 and customized pam stack. But it should not influence returned groups.

Thank you very much for log files. I finally was able to reproduce issue.

The simple reproducer is:
* configure ad provider
* enable option "ignore_group_members = true"
* call id for some user twice
  id user; id user

The missing groups are caused by different processing of groups with enabled and disabled token groups. So the bug is reproducible with enabled options ignore_group_members and (it's enabled by default for ad provider)

The workaround is to disable tokengroups and groups will not disappear.
    ldap_use_tokengroups = false

Upstream ticket:
https://fedorahosted.org/sssd/ticket/2646

*** Bug 1206632 has been marked as a duplicate of this bug. ***

Upstream fixes:
    master: ee44aac95e42c3cb634876286a2aa4960ac69a2b
    sssd-1-12: 44f35a0f32785bf460b5d05424f5e9a15f4f4028

Tested with sssd-1.12.4-45.el6.

1. Install sssd-1.12.4-42.el6.x86_64.

2. Configure sssd with ad backend and set "ignore_group_members = true" in sssd.conf.

3. Call id command for aduser1 twice.
 
# id aduser1
uid=1999201104(aduser1) gid=1999200513(domain users) groups=1999200513(domain users),1999201117(grp1),1999201123(grp7),1999201124(grp8),1999201122(grp6),1999201120(grp4),1999201119(grp3),1999201125(grp9),1999201118(grp2),1999201121(grp5)

# id aduser1
uid=1999201104(aduser1) gid=1999200513(domain users) groups=1999200513(domain users)

4. Update sssd to sssd-1.12.4-45.el6 version. Invalidate sssd cache.

5. Run "id aduser1" multiple times 
# id aduser1
uid=1999201104(aduser1) gid=1999200513(domain users) groups=1999200513(domain users),1999201117(grp1),1999201123(grp7),1999201125(grp9),1999201121(grp5),1999201119(grp3),1999201124(grp8),1999201120(grp4),1999201122(grp6),1999201118(grp2)

The groups appear properly.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1448.html