Bug 1296620

Summary:	Properly remove OriginalMemberOf attribute in SSSD cache if user has no secondary groups anymore
Product:	Red Hat Enterprise Linux 6	Reporter:	Sumit Bose <sbose>
Component:	sssd	Assignee:	SSSD Maintainers <sssd-maint>
Status:	CLOSED ERRATA	QA Contact:	Steeve Goveas <sgoveas>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.7	CC:	grajaiya, jgalipea, jhrozek, lslebodn, mkosek, mniranja, mzidek, pbrezina, preichl, sbose, sgoveas, sssd-maint
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	sssd-1.13.3-3.el6	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	1296618	Environment:
Last Closed:	2016-05-10 20:26:19 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:43:06 UTC

+++ This bug was initially created as a clone of Bug #1296618 +++

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:55 UTC

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

Comment 2 Jakub Hrozek 2016-01-08 09:52:17 UTC

A patch is available on the devel list, acking..

Comment 4 Jakub Hrozek 2016-01-12 09:09:44 UTC

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

Comment 6 Niranjan Mallapadi Raghavender 2016-03-21 06:38:21 UTC

Version
========
sssd-1.13.3-22.el6.x86_64
Windows 2008 R2 

Steps to verify
1. On Windows AD , create a new group my unixgroup and Make user Administrator
member of Group "myunixgroup"

2. Setup sssd.conf as below:

[root@dhcp201-105 db]# cat /etc/sssd/sssd.conf 
[sssd]
config_file_version = 2
domains = winpki1.testpki.test
services = nss, pam

[domain/winpki1.testpki.test]
id_provider = ad
auth_provider = ad
access_provider = ad
default_shell = /bin/bash
fallback_homedir = /home/%d/%u
use_fully_qualified_names = True
debug_level = 9
enumerate = False
ldap_id_mapping = True
ad_server = WIN-Q8VKBEJ7H39.winpki1.testpki.test
ad_domain = winpki1.testpki.test
enum_cache_timeout = 30
entry_cache_nowait_percentage = 50

3. Authenticate the system to AD using below command:
$ authconfig --enablesssd --enablesssdauth --krb5kdc=WIN-Q8VKBEJ7H39.winpki1.testpki.test 
--krb5adminserver=WIN-Q8VKBEJ7H39.winpki1.testpki.test -krb5realm=WINPKI1.TESTPKI.TEST --enablemkhomedir --updateall

$ id Administrator.test

uid=1739400500(administrator.test) gid=1739400513(domain users.test) groups=1739400513(domain users.test),1739400520(group policy creator owners.test),1739400519(enterprise admins.test),1739400512(domain admins.test),1739401104(myunixgroup.test),1739400572(denied rodc password replication group.test),1739400518(schema admins.test)

4. Run ldbsearch

$ ldbsearch -H cache_winpki1.testpki.test.ldb  -b name=Administrator,cn=users,cn=winpki1.testpki.test,cn=sysd
dn: name=Administrator,cn=users,cn=winpki1.testpki.test,cn=sysdb
createTimestamp: 1458539437
fullName: Administrator
gecos: Administrator
gidNumber: 1739400513
name: Administrator
objectClass: user
uidNumber: 1739400500
objectSIDString: S-1-5-21-2826619844-1825486024-3854887371-500
uniqueID: f13d5e6e-ff8f-4482-b027-da78bc53188d
originalDN: CN=Administrator,CN=Users,DC=winpki1,DC=testpki,DC=test
originalModifyTimestamp: 20160318091005.0Z
entryUSN: 42883
adUserAccountControl: 512
nameAlias: administrator
originalMemberOf: CN=myunixgroup,CN=Users,DC=winpki1,DC=testpki,DC=test
originalMemberOf: CN=Group Policy Creator Owners,CN=Users,DC=winpki1,DC=testpk
 i,DC=test
originalMemberOf: CN=Domain Admins,CN=Users,DC=winpki1,DC=testpki,DC=test
originalMemberOf: CN=Enterprise Admins,CN=Users,DC=winpki1,DC=testpki,DC=test
originalMemberOf: CN=Schema Admins,CN=Users,DC=winpki1,DC=testpki,DC=test
originalMemberOf: CN=Administrators,CN=Builtin,DC=winpki1,DC=testpki,DC=test
lastUpdate: 1458540403
dataExpireTimestamp: 1458545803
initgrExpireTimestamp: 1458545803
memberof: name=Group Policy Creator Owners,cn=groups,cn=winpki1.testpki.test,c
 n=sysdb
memberof: name=Enterprise Admins,cn=groups,cn=winpki1.testpki.test,cn=sysdb
memberof: name=Domain Admins,cn=groups,cn=winpki1.testpki.test,cn=sysdb
memberof: name=Domain Users,cn=groups,cn=winpki1.testpki.test,cn=sysdb
memberof: name=myunixgroup,cn=groups,cn=winpki1.testpki.test,cn=sysdb
memberof: name=Denied RODC Password Replication Group,cn=groups,cn=winpki1.tes
 tpki.test,cn=sysdb
memberof: name=Schema Admins,cn=groups,cn=winpki1.testpki.test,cn=sysdb
distinguishedName: name=Administrator,cn=users,cn=winpki1.testpki.test,cn=sysdb


5. From Windows AD, Remove Administrator From "myunixgroup"

6. Restart sssd

7. Run id command and verify if User Administrator is still member of "myunixgroup"

[root@dhcp201-105 db]# id Administrator.test
uid=1739400500(administrator.test) gid=1739400513(domain users.test) groups=1739400513(domain users.test),1739400520(group policy creator owners.test),1739400519(enterprise admins.test),1739400512(domain admins.test),1739400518(schema admins.test),1739401104(myunixgroup.test),1739400572(denied rodc password replication group.test)

8.Running ldbsearch still shows myunixgroup in originalMemberof entry

[root@dhcp201-105 db]# ldbsearch -H cache_winpki1.testpki.test.ldb  -b name=Administrator,cn=users,cn=winpki1.testpki.test,cn=sysdb
asq: Unable to register control with rootdse!
# record 1
dn: name=Administrator,cn=users,cn=winpki1.testpki.test,cn=sysdb
createTimestamp: 1458539437
fullName: Administrator
gecos: Administrator
gidNumber: 1739400513
name: Administrator
objectClass: user
uidNumber: 1739400500
objectSIDString: S-1-5-21-2826619844-1825486024-3854887371-500
uniqueID: f13d5e6e-ff8f-4482-b027-da78bc53188d
originalDN: CN=Administrator,CN=Users,DC=winpki1,DC=testpki,DC=test
originalModifyTimestamp: 20160318091005.0Z
entryUSN: 42883
adUserAccountControl: 512
nameAlias: administrator
originalMemberOf: CN=myunixgroup,CN=Users,DC=winpki1,DC=testpki,DC=test
originalMemberOf: CN=Group Policy Creator Owners,CN=Users,DC=winpki1,DC=testpk
 i,DC=test
originalMemberOf: CN=Domain Admins,CN=Users,DC=winpki1,DC=testpki,DC=test
originalMemberOf: CN=Enterprise Admins,CN=Users,DC=winpki1,DC=testpki,DC=test
originalMemberOf: CN=Schema Admins,CN=Users,DC=winpki1,DC=testpki,DC=test
originalMemberOf: CN=Administrators,CN=Builtin,DC=winpki1,DC=testpki,DC=test
lastUpdate: 1458540403
memberof: name=Group Policy Creator Owners,cn=groups,cn=winpki1.testpki.test,c
 n=sysdb
memberof: name=Enterprise Admins,cn=groups,cn=winpki1.testpki.test,cn=sysdb
memberof: name=Domain Admins,cn=groups,cn=winpki1.testpki.test,cn=sysdb
memberof: name=Domain Users,cn=groups,cn=winpki1.testpki.test,cn=sysdb
memberof: name=myunixgroup,cn=groups,cn=winpki1.testpki.test,cn=sysdb
memberof: name=Denied RODC Password Replication Group,cn=groups,cn=winpki1.tes
 tpki.test,cn=sysdb
memberof: name=Schema Admins,cn=groups,cn=winpki1.testpki.test,cn=sysdb
dataExpireTimestamp: 1
initgrExpireTimestamp: 1
distinguishedName: name=Administrator,cn=users,cn=winpki1.testpki.test,cn=sysdb

9. Cleared sssd cache and ran ldbsearch, i still see the entry


Going through the original customer case, i see that scenario is IPA AD trust, Does this work only in such a scenario ?

Comment 7 Sumit Bose 2016-03-21 07:54:21 UTC

Frist, I'm pretty sure that the Administrator user was not removed properly from the myunixgroup because after removing the cache there would be no other source to relate to user with the group.

Second, although the group membership should be removed for the Administrator user as well the Administrator user is not a good choice here, because the ticket is about the case where the user is not a member of any secondary group anymore after the test group, myunixgroup in your case, is removed. I would suggest to create a new user, say myunixuser, and add it to the group first and look it up from the client, then remove it from the group in AD, flush the cache on the client and call id for the user again.

Third, it should work with both direct integration with the AD provider and indirect integration with the IPA provider. In the IPA case you only have to take care that the cache in the IPA server is flushed after the user is removed from the group as well.

Comment 8 Niranjan Mallapadi Raghavender 2016-03-21 09:42:26 UTC

10.
Created user: myunixuser

[root@dhcp201-105 db]# id myunixuser.test
uid=1739401124(myunixuser.test) gid=1739400513(domain users.test) groups=1739400513(domain users.test)
[root@dhcp201-105 db]# 



[root@dhcp201-105 db]# ldbsearch -H cache_winpki1.testpki.test.ldb  -b name=myunixuser,cn=users,cn=winpki1.testpki.test,cn=sysdb
asq: Unable to register control with rootdse!
# record 1
dn: name=myunixuser,cn=users,cn=winpki1.testpki.test,cn=sysdb
createTimestamp: 1458550849
fullName: myunixuser
gecos: myunixuser
gidNumber: 1739400513
name: myunixuser
objectClass: user
uidNumber: 1739401124
objectSIDString: S-1-5-21-2826619844-1825486024-3854887371-1124
uniqueID: 4f0de737-2bf9-4a1e-962f-abb99dd4e1fe
originalDN: CN=myunixuser,CN=Users,DC=winpki1,DC=testpki,DC=test
originalModifyTimestamp: 20160321085903.0Z
entryUSN: 43318
userPrincipalName: myunixuser.TEST
adUserAccountControl: 512
nameAlias: myunixuser
lastUpdate: 1458550849
dataExpireTimestamp: 1458556249
memberof: name=Domain Users,cn=groups,cn=winpki1.testpki.test,cn=sysdb
initgrExpireTimestamp: 1458556250
distinguishedName: name=myunixuser,cn=users,cn=winpki1.testpki.test,cn=sysdb

11. Add the user "myunixuser" member of group "myunixgroup"

uid=1739401124(myunixuser.test) gid=1739400513(domain users.test) groups=1739400513(domain users.test),1739401104(myunixgroup.test)

[root@dhcp201-105 db]# ldbsearch -H cache_winpki1.testpki.test.ldb  -b name=myunixuser,cn=users,cn=winpki1.testpki.test,cn=sysdb
asq: Unable to register control with rootdse!
# record 1
dn: name=myunixuser,cn=users,cn=winpki1.testpki.test,cn=sysdb
createTimestamp: 1458550849
fullName: myunixuser
gecos: myunixuser
gidNumber: 1739400513
name: myunixuser
objectClass: user
uidNumber: 1739401124
objectSIDString: S-1-5-21-2826619844-1825486024-3854887371-1124
uniqueID: 4f0de737-2bf9-4a1e-962f-abb99dd4e1fe
originalDN: CN=myunixuser,CN=Users,DC=winpki1,DC=testpki,DC=test
originalModifyTimestamp: 20160321085903.0Z
entryUSN: 43318
userPrincipalName: myunixuser.TEST
adUserAccountControl: 512
nameAlias: myunixuser
memberof: name=Domain Users,cn=groups,cn=winpki1.testpki.test,cn=sysdb
memberof: name=myunixgroup,cn=groups,cn=winpki1.testpki.test,cn=sysdb
originalMemberOf: CN=myunixgroup,CN=Users,DC=winpki1,DC=testpki,DC=test
lastUpdate: 1458551236
dataExpireTimestamp: 1458556636
initgrExpireTimestamp: 1458556636
distinguishedName: name=myunixuser,cn=users,cn=winpki1.testpki.test,cn=sysdb

# returned 1 records


12. Remove the user "myunixuser" from the group "myunixgroup"


13. Restart sssdStarting sssd:                                             [  OK  ]
[root@dhcp201-105 db]# id myunixuser.test
uid=1739401124(myunixuser.test) gid=1739400513(domain users.test) groups=1739400513(domain users.test)
[root@dhcp201-105 db]# 

14. Running ldbsearch again.
[root@dhcp201-105 db]# ldbsearch -H cache_winpki1.testpki.test.ldb  -b name=myunixuser,cn=users,cn=winpki1.testpki.test,cn=sysdb
asq: Unable to register control with rootdse!
# record 1
dn: name=myunixuser,cn=users,cn=winpki1.testpki.test,cn=sysdb
createTimestamp: 1458550849
fullName: myunixuser
gecos: myunixuser
gidNumber: 1739400513
name: myunixuser
objectClass: user
uidNumber: 1739401124
objectSIDString: S-1-5-21-2826619844-1825486024-3854887371-1124
uniqueID: 4f0de737-2bf9-4a1e-962f-abb99dd4e1fe
originalDN: CN=myunixuser,CN=Users,DC=winpki1,DC=testpki,DC=test
originalModifyTimestamp: 20160321085903.0Z
entryUSN: 43318
userPrincipalName: myunixuser.TEST
adUserAccountControl: 512
nameAlias: myunixuser
lastUpdate: 1458553141
dataExpireTimestamp: 1458558541
memberof: name=Domain Users,cn=groups,cn=winpki1.testpki.test,cn=sysdb
initgrExpireTimestamp: 1458558542
distinguishedName: name=myunixuser,cn=users,cn=winpki1.testpki.test,cn=sysdb

There is no "originalMemberOf: CN=myunixgroup,CN=Users,DC=winpki1,DC=testpki,DC=test" in the updated cache entry.

Comment 10 errata-xmlrpc 2016-05-10 20:26:19 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/RHBA-2016-0782.html