Learn more about these different git repos.
Other Git URLs
Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 6): Bug 1212610
Please note that this Bug is private and may not be accessible as it contains confidential Red Hat customer information.
## Description of problem: users sometimes are missing groups when using sssd-ad ## Version-Release number of selected component (if applicable): sssd-ad-1.11.6-30.el6.x86_64 RHEL 6.6 <kernel-2.6.32-504.el6.x86_64> ## How reproducible: Intermittent per customer ## Steps to Reproduce: * configure ad provider * enable option "ignore_group_members = true" * call id for some user twice id user; id user 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 [domain/company.com] 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: https://bugzilla.redhat.com/show_bug.cgi?id=1203440#c14 Workaround that was given to customer and seems to have fixed the groups issue [domain/company.com] id_provider = ad ldap_use_tokengroups = False
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)
Groups are returned for the first time of "id call" because after initial initgroups groups are stored with SID name:
[root@vm-049 sssd]# id -G neilan 180200513 182036014 182036016 182036018 182036022 182036029 182036030 182036031 182036032 182036033 182036034 182036046 182036050 182036051 182036052 182036053 182036054 182036056 182036058 182036060 182036062 182036063 182036069 182036072 182036073 182036081 182036082 182036085 182036086 182036089 182036092 182036093 182036094 182036097 182036103 182036108 182036109 182036112 182036113 182036114 182036115 182036119 182036121 182036123 182036124 182036126 182036130 182036131 182036133 [root@vm-049 sssd]# ldbsearch -H /var/lib/sss/db/cache_ad.example.comcom.ldb "(gidNumber = 182036097)" gidNumber name memberuid asq: Unable to register control with rootdse! # record 1 dn: name=S-1-5-21-2997650941-1802118864-3094776726-1836097,cn=groups,cn=ad.example.com,cn=sysdb gidNumber: 182036097 name: S-1-5-21-2997650941-1802118864-3094776726-1836097 memberuid: neilan sh# id neilan; id neilan //snip [root@vm-049 sssd]# ldbsearch -H /var/lib/sss/db/cache_ad.example.com.ldb "(gidNumber = 182036097)" gidNumber name memberuid asq: Unable to register control with rootdse! # record 1 dn: name=Exchange Public Folder Administrators,cn=groups,cn=ad.example.com,cn=sysdb gidNumber: 182036097 name: Exchange Public Folder Administrators
The memberuid attribute is missing in the second ldb output.
_comment0: Groups are returned for the first time of "id call" because after initial initgroups groups are stored with SID name:
{{{ [root@vm-049 sssd]# id -G neilan 180200513 182036014 182036016 182036018 182036022 182036029 182036030 182036031 182036032 182036033 182036034 182036046 182036050 182036051 182036052 182036053 182036054 182036056 182036058 182036060 182036062 182036063 182036069 182036072 182036073 182036081 182036082 182036085 182036086 182036089 182036092 182036093 182036094 182036097 182036103 182036108 182036109 182036112 182036113 182036114 182036115 182036119 182036121 182036123 182036124 182036126 182036130 182036131 182036133
[root@vm-049 sssd]# ldbsearch -H /var/lib/sss/db/cache_tbad.idm.lab.eng.brq.redhat.com.ldb "(gidNumber = 182036097)" gidNumber name memberuid asq: Unable to register control with rootdse!
dn: name=S-1-5-21-2997650941-1802118864-3094776726-1836097,cn=groups,cn=tbad.idm.lab.eng.brq.redhat.com,cn=sysdb gidNumber: 182036097 name: S-1-5-21-2997650941-1802118864-3094776726-1836097 memberuid: neilan
sh# id neilan; id neilan //snip
dn: name=Exchange Public Folder Administrators,cn=groups,cn=tbad.idm.lab.eng.brq.redhat.com,cn=sysdb gidNumber: 182036097 name: Exchange Public Folder Administrators }}}
The memberuid attribute is missing in the second ldb output. => 1430378076840716 blockedby: => blocking: => changelog: => coverity: => design: => design_review: => 0 feature_milestone: => fedora_test_page: => mark: no => 0 review: True => 0 selected: => testsupdated: => 0
It is related to error message
[sysdb_store_group] (0x0080): A group with the same GID [182036097] was removed from the cache
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.12.5
owner: somebody => jhrozek status: new => assigned
patch: 0 => 1
resolution: => fixed status: assigned => closed
Metadata Update from @lslebodn: - Issue assigned to jhrozek - Issue set to the milestone: SSSD 1.12.5
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/3687
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.