Bug 1122158

Summary:	ad: group membership is empty when id mapping is off and tokengroups are enabled
Product:	Red Hat Enterprise Linux 6	Reporter:	Jakub Hrozek <jhrozek>
Component:	sssd	Assignee:	Jakub Hrozek <jhrozek>
Status:	CLOSED ERRATA	QA Contact:	Kaushik Banerjee <kbanerje>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.0	CC:	grajaiya, jgalipea, jhrozek, lslebodn, mkosek, nkarandi, pbrezina, preichl, warren
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	sssd-1.11.6-12.el6	Doc Type:	Bug Fix
Doc Text:	Cause: ID provider is set to AD, ID mapping is disabled but tokengroups are enabled. When initgroups is performed SSSD resolves SIDs to groups but does not store the membership. Consequence: Group membership was not resolved correctly - only primary group was aquired. Fix: SSSD updates user's membership after SIDs are resolved. Result: Group membership is resolved correctly.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-10-14 04:49:09 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jakub Hrozek 2014-07-22 16:32:10 UTC

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.

Comment 1 Jakub Hrozek 2014-07-22 16:36:37 UTC

    master:
        ed346bcc84b8a326996e5550771773d8e63f17c2
        e6fa71b990d7068d66b98015ae54aae399cc84f1 
    sssd-1-11:
        e00a71a43980963adf9b9f5e3d2f356f175498e9
        c123f5352ac406b5d02acab88642a9564fe31381

Comment 4 Jakub Hrozek 2014-07-28 13:44:26 UTC

Pavel, can you add the steps to verify for QE? Thanks!

Comment 6 Pavel Březina 2014-07-30 08:50:02 UTC

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

Comment 7 Nirupama Karandikar 2014-08-07 06:03:16 UTC

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)

Comment 8 Nirupama Karandikar 2014-08-13 11:42:15 UTC

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

Comment 14 Nirupama Karandikar 2014-08-14 08:02:46 UTC

Since the initial issue is fixed marking as verified.

Comment 15 errata-xmlrpc 2014-10-14 04:49:09 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.

http://rhn.redhat.com/errata/RHBA-2014-1375.html