Bug 1296618

Summary:	Properly remove OriginalMemberOf attribute in SSSD cache if user has no secondary groups anymore
Product:	Red Hat Enterprise Linux 7	Reporter:	Sumit Bose <sbose>
Component:	sssd	Assignee:	SSSD Maintainers <sssd-maint>
Status:	CLOSED ERRATA	QA Contact:	Steeve Goveas <sgoveas>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.2	CC:	grajaiya, jgalipea, jhrozek, lslebodn, mkosek, mniranja, mzidek, pbrezina
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	sssd-1.14.0-0.1.alpha.el7	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1296620 (view as bug list)		Environment:
Last Closed:	2016-11-04 07:14:29 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Sumit Bose 2016-01-07 16:40:26 UTC

Description of problem:
Since the DNs in the SSSD cache differ from the DNs of the original objects SSSD saves the original DN in attributes prefixed by 'original'. The is done for the memberOf attributes of a user as well. If now e.g. from a AD user all secondary group memberships are removed, i.e. the user is only member of the primary group which is 'Domain Users' in the AD case, there are no memberOf attributes in the original object anymore. In this case any existing OriginalMemberOf attributes are not removed from the cache. This can be seen by checking the cache entry with the ldbsearch utility.

Comment 1 Jakub Hrozek 2016-01-07 16:46:14 UTC

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

Comment 2 Jakub Hrozek 2016-01-12 09:09:37 UTC

Fixed upstream:
    master: 9a2f018c0f68a3ada4cea4128a861a7f85893f22
    sssd-1-13: 93b758232f57fb02ab4f9208f997448668f289f8

Comment 3 Mike McCune 2016-03-28 23:37:25 UTC

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Comment 5 Niranjan Mallapadi Raghavender 2016-09-19 10:39:11 UTC

Versions:
========
sssd-ad-1.14.0-41.el7.x86_64
sssd-proxy-1.14.0-41.el7.x86_64
sssd-krb5-common-1.14.0-41.el7.x86_64
sssd-ldap-1.14.0-41.el7.x86_64
python-sssdconfig-1.14.0-41.el7.noarch
sssd-common-1.14.0-41.el7.x86_64
sssd-krb5-1.14.0-41.el7.x86_64
sssd-ipa-1.14.0-41.el7.x86_64
sssd-client-1.14.0-41.el7.x86_64
sssd-common-pac-1.14.0-41.el7.x86_64
sssd-1.14.0-41.el7.x86_64


1. Join the system to AD using realm using client software sssd

[root@client1 tmp]# realm join CENTAUR.TEST --client-software=sssd  -v
 * Resolving: _ldap._tcp.centaur.test
 * Performing LDAP DSE lookup on: 192.168.122.27
 * Performing LDAP DSE lookup on: 192.168.122.187
 * Successfully discovered: CENTAUR.TEST
Password for Administrator:
 * Required files: /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/sbin/sssd, /usr/bin/net
 * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.5Q4YNY -U Administrator ads join CENTAUR.TEST
Enter Administrator's password:DNS update failed: NT_STATUS_UNSUCCESSFUL

Using short domain name -- CENTAUR
Joined 'CLIENT1' to dns domain 'CENTAUR.TEST'
DNS Update for client1.example.test failed: ERROR_DNS_UPDATE_FAILED
 * LANG=C LOGNAME=root /usr/bin/net -s /var/cache/realmd/realmd-smb-conf.5Q4YNY -U Administrator ads keytab create
Enter Administrator's password:
 * /usr/bin/systemctl enable sssd.service
 * /usr/bin/systemctl restart sssd.service
 * /usr/bin/sh -c /usr/sbin/authconfig --update --enablesssd --enablesssdauth --enablemkhomedir --nostart && /usr/bin/systemctl enable oddjobd.service && /usr/bin/systemctl start oddjobd.service
 * Successfully enrolled machine in realm


3. Create a AD user foobar1

4. Create a group myunix group in AD and make foobar1 member of group myunixgroup

[root@client1 db]# id foobar1
uid=1993601561(foobar1) gid=1993600513(domain users) groups=1993600513(domain users),1993601669(myunixgroup)


5.  Search Domain cache using ldbsearch

$ldbsearch -H cache_CENTAUR.TEST.ldb
dn: name=foobar1,cn=users,cn=CENTAUR.TEST,cn=sysdb
createTimestamp: 1474277849
fullName: foobar1
gecos: foobar1
gidNumber: 1993600513
name: foobar1
objectClass: user
uidNumber: 1993601561
objectSIDString: S-1-5-21-2018725737-2313711822-3824173085-1561
uniqueID: 088d78ae-90f3-43bb-b571-6442170c8006
originalDN: CN=foobar1,CN=Users,DC=CENTAUR,DC=TEST
originalModifyTimestamp: 20160919065624.0Z
userPrincipalName: foobar1
adUserAccountControl: 512
nameAlias: foobar1
memberof: name=Domain Users,cn=groups,cn=CENTAUR.TEST,cn=sysdb
memberof: name=myunixgroup,cn=groups,cn=CENTAUR.TEST,cn=sysdb
initgrExpireTimestamp: 1474283249
originalMemberOf: CN=myunixgroup,CN=Users,DC=CENTAUR,DC=TEST
entryUSN: 155993
lastUpdate: 1474278282
dataExpireTimestamp: 1474283682
distinguishedName: name=foobar1,cn=users,cn=CENTAUR.TEST,cn=sysdb

6. Remove foobar1 from myunixgroup 

7. Expire cache and restart sssd

8. Run ldbsearch again  and verify originalMemberOf attribute in foobar1 cache entry doesn't exist.

createTimestamp: 1474277849
fullName: foobar1
gecos: foobar1
gidNumber: 1993600513
name: foobar1
objectClass: user
uidNumber: 1993601561
objectSIDString: S-1-5-21-2018725737-2313711822-3824173085-1561
uniqueID: 088d78ae-90f3-43bb-b571-6442170c8006
originalDN: CN=foobar1,CN=Users,DC=CENTAUR,DC=TEST
originalModifyTimestamp: 20160919065624.0Z
userPrincipalName: foobar1
adUserAccountControl: 512
nameAlias: foobar1
initgrExpireTimestamp: 1474283249
memberof: name=Domain Users,cn=groups,cn=CENTAUR.TEST,cn=sysdb
entryUSN: 167055
lastUpdate: 1474281452
dataExpireTimestamp: 1474286852
distinguishedName: name=foobar1,cn=users,cn=CENTAUR.TEST,cn=sysdb

Comment 7 errata-xmlrpc 2016-11-04 07:14:29 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.

https://rhn.redhat.com/errata/RHEA-2016-2476.html