Bug 1212610 - sssd ad groups work intermittently
Summary: sssd ad groups work intermittently
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.6
Hardware: x86_64
OS: Linux
Target Milestone: rc
: ---
Assignee: SSSD Maintainers
QA Contact: Kaushik Banerjee
: 1206632 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2015-04-16 18:53 UTC by Sam Yangsao
Modified: 2020-05-02 18:03 UTC (History)
11 users (show)

Fixed In Version: sssd-1.12.4-43.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-07-22 06:44:07 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Github SSSD sssd issues 3687 None closed Disapeared groups with ad providers and enabled ignore_group_members 2020-09-05 04:16:20 UTC
Red Hat Product Errata RHBA-2015:1448 normal SHIPPED_LIVE sssd bug fix and enhancement update 2015-07-20 18:43:53 UTC

Description Sam Yangsao 2015-04-16 18:53:56 UTC
## Description of problem:

users sometimes are missing groups when using sssd-ad

## Version-Release number of selected component (if applicable):


RHEL 6.6 <kernel-2.6.32-504.el6.x86_64>

## How reproducible:

Intermittent per customer

## Steps to Reproduce:

Customer did not have the "ldap_use_tokengroups" entry originally, assuming this is on by default or set to "True" since the workaround is to set this value to "False" for their Active Directory groups to show up.

# service sssd stop
# rm -f /var/log/sssd/*
# rm -f /var/lib/sss/db/*
# vi /etc/sssd/sssd.conf

id_provider = ad
ldap_use_tokengroups = True *** OR remove this line

# service sssd start

## Actual results:

AD groups associated with the id do not show up.

## Expected results:

AD groups should always show up

## Additional info:

This bz was created per:


Workaround that was given to customer and seems to have fixed the groups issue

id_provider = ad
ldap_use_tokengroups = False
ldap_group_objectsid = objectSID
ldap_user_objectsid = objectSID

Comment 7 Lukas Slebodnik 2015-04-17 15:52:50 UTC
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 
           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.

Comment 10 Lukas Slebodnik 2015-04-21 10:52:38 UTC
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.

* 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.

Comment 20 Lukas Slebodnik 2015-04-30 06:56:10 UTC
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

Comment 21 Lukas Slebodnik 2015-04-30 07:02:05 UTC
Upstream ticket:

Comment 22 Jakub Hrozek 2015-05-27 17:43:26 UTC
*** Bug 1206632 has been marked as a duplicate of this bug. ***

Comment 24 Jakub Hrozek 2015-06-08 11:16:03 UTC
Upstream fixes:
    master: ee44aac95e42c3cb634876286a2aa4960ac69a2b
    sssd-1-12: 44f35a0f32785bf460b5d05424f5e9a15f4f4028

Comment 25 Nirupama Karandikar 2015-06-09 09:18:02 UTC
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.

Comment 27 errata-xmlrpc 2015-07-22 06:44:07 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.