Hide Forgot
This bug is created as a clone of upstream ticket: https://fedorahosted.org/sssd/ticket/2385 When id_provider=ad, id mapping is off but tokengroups are used the first initgroups attempt yields empty membership (only primary group is shown). The successive initgroups works correctly. * SIDs are acquired correctly from tokengroups * if SID is already in the cache the membership is updated * missing SIDs are downloaded but membership is not updated Reported by jhodrien on IRC.
master: ed346bcc84b8a326996e5550771773d8e63f17c2 e6fa71b990d7068d66b98015ae54aae399cc84f1 sssd-1-11: e00a71a43980963adf9b9f5e3d2f356f175498e9 c123f5352ac406b5d02acab88642a9564fe31381
Pavel, can you add the steps to verify for QE? Thanks!
The steps are quite simple. 1. create an AD user which is member of at least one non-primary POSIX group 2. disable id mapping and enable tokengroups in sssd.conf 3. run id $user - without this patch only primary group is shown - with this patch all groups are printed
Tested with sssd-1.11.6-14.el6.x86_64 aduser1:*:70001:70001:aduser1:/home/aduser1:/bin/sh :: [ PASS ] :: Running 'getent passwd aduser1' (Expected 0, got 0) uid=70001(aduser1) gid=70001(adgrp01) groups=70001(adgrp01),10000(domain users),70002(adgrp02),70003(adgrp03),70004(adgrp04) :: [ PASS ] :: Running 'id aduser1 | grep adgrp03' (Expected 0, got 0) aduser1 : adgrp01 domain users adgrp02 adgrp03 adgrp04 :: [ PASS ] :: Running 'groups aduser1' (Expected 0, got 0)
Not sure if this issue is related to this fix, but now group lookups are empty if initgroup lookups are run before normal group lookup. 1. Restart sssd with a clear cache 2. Initgroup lookup # id aduser1 uid=70001(aduser1) gid=70001(adgrp01) groups=70001(adgrp01),10000(domain users),70002(adgrp02),70003(adgrp03),70004(adgrp04) 3.Group lookup # getent group adgrp01 adgrp01:*:70001: <= member aduser1 is missing After step 2, domain log shows: (Wed Aug 13 17:16:35 2014) [sssd[be[MARS.CORP.COM]]] [sdap_get_primary_name] (0x0400): Processing object adgrp01 (Wed Aug 13 17:16:35 2014) [sssd[be[MARS.CORP.COM]]] [sdap_save_grpmem] (0x0400): Processing group adgrp01 (Wed Aug 13 17:16:35 2014) [sssd[be[MARS.CORP.COM]]] [sdap_save_grpmem] (0x0400): Adding member users to group [adgrp01] (Wed Aug 13 17:16:35 2014) [sssd[be[MARS.CORP.COM]]] [sysdb_set_entry_attr] (0x0080): ldb_modify failed: [Attribute or value exists] (Wed Aug 13 17:16:35 2014) [sssd[be[MARS.CORP.COM]]] [sysdb_set_entry_attr] (0x0040): Error: 17 (File exists) (Wed Aug 13 17:16:35 2014) [sssd[be[MARS.CORP.COM]]] [sysdb_store_group] (0x0400): Error: 17 (File exists) (Wed Aug 13 17:16:35 2014) [sssd[be[MARS.CORP.COM]]] [sdap_save_grpmem] (0x0080): sysdb_store_group failed: [17][File exists]. (Wed Aug 13 17:16:35 2014) [sssd[be[MARS.CORP.COM]]] [sdap_save_grpmem] (0x0040): Failed to save members of group adgrp01
Since the initial issue is fixed marking as verified.
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. http://rhn.redhat.com/errata/RHBA-2014-1375.html