Bug 1044142

Summary:	winsync doesn't sync DN valued attributes if DS DN value doesn't exist
Product:	Red Hat Enterprise Linux 7	Reporter:	Nathan Kinder <nkinder>
Component:	389-ds-base	Assignee:	Rich Megginson <rmeggins>
Status:	CLOSED ERRATA	QA Contact:	Viktor Ashirov <vashirov>
Severity:	unspecified	Docs Contact:
Priority:	medium
Version:	7.0	CC:	nhosoi, vashirov
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	389-ds-base-1.3.3.1-1.el7	Doc Type:	Bug Fix
Doc Text:	1) Problem: A group on AD has a member which is not a target of windows sync and exists only on AD. The member value in the group is synchronized to DS. If an operation is executed on AD so that the member is replaced with other members which are the target of the windows sync, the new member values are not synchronized. Fix: In windows_generate_update_mods, even if a sync'ed member value in a DS entry is not the target of windows sync and it is does not exist on DS, a following modify operation including the member value is proceeded by confirming the existence on AD. 2) Problem: If a group on AD and DS have members which are local and are not synchronized and the members are removed in the group on the other side, the delete operation is synchronized and deletes all the members including the local members. Fix: Added the code to check if an attribute is completely deleted on one side, then the each value on the other side is in the sync scope or not. Put the value to the mod for the delete only if the value is in the sync scope.	Story Points:	---
Clone Of:
Clones:	1109381 (view as bug list)		Environment:
Last Closed:	2015-03-05 09:29:36 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:
Bug Depends On:
Bug Blocks:	1109381

Description Nathan Kinder 2013-12-17 21:21:12 UTC

This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/415

Steps:
0) add a cn=Test User1 to AD - see that it is synced over to DS

1) add an entry to AD with a member: DN that only exists in AD - for example
member: cn=Administrator,cn=Users,dc=example,dc=com

2) see that the ADD is synced over to DS - the DS will see that member is DN valued and try to map appropriately
member: uid=administrator,ou=people,dc=example,dc=com

3) Change the member attribute in AD to a real user that is synced over
member: cn=Test User1,cn=Users,dc=example,dc=com

DS will not update member because the code in windows_generate_update_mods() attempts to verify the existence of the DN member attribute value in DS in order to generate a mod/delete before doing the mod/add for the new value.

Comment 2 Viktor Ashirov 2015-01-17 19:06:34 UTC

0) Add test entries to AD - see that it is synced over to DS
$ ldapmodify -x -D "cn=Administrator,cn=users,dc=adrelm,dc=com" -w Secret123 -H ldap://win2k8.adrelm.com -a << EOF
dn: CN=AD_ONLY,cn=users,dc=adrelm,dc=com
objectClass: top
objectClass: user
cn: AD_ONLY
uid: AD_ONLY
sAMAccountName: AD_ONLY
distinguishedName: CN=AD_ONLY,cn=users,dc=adrelm,dc=com

dn: CN=AD_AND_DS,cn=users,dc=adrelm,dc=com
objectClass: top
objectClass: user
cn: AD_AND_DS
sn: AD_AND_DS
uid: AD_AND_DS
sAMAccountName: AD_AND_DS
distinguishedName: CN=AD_AND_DS,cn=users,dc=adrelm,dc=com

dn: CN=grp0,cn=users,dc=adrelm,dc=com
objectClass: top
objectClass: Group
cn: grp0
distinguishedName: CN=grp0,cn=users,dc=adrelm,dc=com
name: grp0
sAMAccountName: grp0
EOF
adding new entry "CN=AD_ONLY,cn=users,dc=adrelm,dc=com"

adding new entry "CN=AD_AND_DS,cn=users,dc=adrelm,dc=com"

adding new entry "CN=grp0,cn=users,dc=adrelm,dc=com"

1) Add an entry to AD with a member: DN that only exists in AD
$ ldapmodify -x -D "cn=Administrator,cn=users,dc=adrelm,dc=com" -w Secret123  -H ldap://win2k8.adrelm.com  << EOF
dn: CN=grp0,cn=users,DC=adrelm,DC=com
changetype: modify
add: member
member: CN=AD_ONLY,CN=Users,DC=adrelm,DC=com
EOF
modifying entry "CN=grp0,cn=users,DC=adrelm,DC=com"

2) See that the ADD is synced over to DS - the DS will see that member is DN valued and try to map appropriately
$ ldapsearch -LLL -H ldap://localhost:1189 -D "cn=Directory Manager" -w Secret123 -x -b dc=example,dc=com "(cn=grp*)" uniquemember
dn: cn=grp0,ou=dswinsync,dc=example,dc=com
uniquemember: uid=AD_ONLY,ou=dswinsync,dc=example,dc=com

3) Change the member attribute in AD to a real user that is synced over
$ ldapmodify -x -D "cn=Administrator,cn=users,dc=adrelm,dc=com" -w Secret123  -H ldap://win2k8.adrelm.com  << EOF
dn: CN=grp0,CN=Users,DC=adrelm,DC=com
changetype: modify
replace: member
member: CN=AD_AND_DS,CN=Users,DC=adrelm,DC=com

EOF
modifying entry "CN=grp0,CN=Users,DC=adrelm,DC=com"

4) MOD is synced over to DS
$ ldapsearch -LLL -H ldap://localhost:1189 -D "cn=Directory Manager" -w Secret123 -x -b dc=example,dc=com "(cn=grp*)" uniquemember
dn: cn=grp0,ou=dswinsync,dc=example,dc=com
uniquemember: uid=AD_AND_DS,ou=dswinsync,dc=example,dc=com


Marking as VERIFIED

Comment 4 errata-xmlrpc 2015-03-05 09:29:36 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/RHSA-2015-0416.html