RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1044142 - winsync doesn't sync DN valued attributes if DS DN value doesn't exist
Summary: winsync doesn't sync DN valued attributes if DS DN value doesn't exist
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Rich Megginson
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks: 1109381
TreeView+ depends on / blocked
 
Reported: 2013-12-17 21:21 UTC by Nathan Kinder
Modified: 2020-09-13 20:14 UTC (History)
2 users (show)

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.
Clone Of:
: 1109381 (view as bug list)
Environment:
Last Closed: 2015-03-05 09:29:36 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 415 0 None None None 2020-09-13 20:14:17 UTC
Red Hat Product Errata RHSA-2015:0416 0 normal SHIPPED_LIVE Important: 389-ds-base security, bug fix, and enhancement update 2015-03-05 14:26:33 UTC

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
Note You need to log in before you can comment on or make changes to this bug.