Bug 739677

Summary:	Apply referential integrity against the internal operations such as WinSync.
Product:	Red Hat Enterprise Linux 7	Reporter:	Brian Junker <bjunker99>
Component:	389-ds-base	Assignee:	Noriko Hosoi <nhosoi>
Status:	CLOSED DUPLICATE	QA Contact:	Viktor Ashirov <vashirov>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.0	CC:	mreynolds, nhosoi, nkinder, rmeggins
Target Milestone:	rc
Target Release:	7.3
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-12-22 20:41:50 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:	495079, 690319

Description Brian Junker 2011-09-19 19:16:29 UTC

Description of problem:

Now that 389 has support for moving an entry in AD when moved between OU's.  The entry is moved properly, however the manager attribute is not updated to reflect the move.

Version-Release number of selected component (if applicable):

1.2.9.9

How reproducible:

100%

Steps to Reproduce:
1. Create sync agreement between 389 and Active Directory, replicating the DS subtree (ou=People,dc=example,dc=com) and the Windows subtree (dc=example,dc=local)
2. Create two OU's on the Active Directory side, Finance (ou=Finance,dc=example,dc=local) and HR (ou=HR,dc=example,dc=local)
3. Create two users on the Active Directory side, User1 under the Finance OU and User2 under the HR OU, and set User1's manager to User2.
4. Create the Finance OU and HR OU on the 389 side under ou=People,dc=example,dc=com;
5. On the Active Directory agreement setup in step 1, Initiate Full Re-syncronization, and the two entries will be created on the 389 side under their respective OU's.  Take note that user1's manager value should be set to uid=user2,OU=HR,ou=People,dc=example,dc=com.
6. On the Active Directory side, move User2 to the Finance OU.  After User2 has been moved, on 389, run Send and Receive Updates Now under the Active Directory agreement.
7. On 389, User2 should have been moved from HR to Finance OU, however the manager attribute under User1 does not reflect this, and has the old value.
  
Actual results:

Manager value is uid=user2,OU=HR,ou=People,dc=example,dc=com

Expected results:

Manager value should be uid=user2,ou=Finance,ou=People,dc=example,dc=com

Additional info:

Comment 1 Rich Megginson 2011-10-17 21:12:11 UTC

You will need to enable the Referential Integrity plugin, and configure it to handle the manager attribute.

Comment 2 Brian Junker 2011-10-18 18:37:55 UTC

I enabled and configured the Referential Integrity plugin.  To make sure that I configured the plugin correctly, I tested it on some user objects outside the Active Directory sync, and it worked properly.  The manager attribute on those users updated properly.

When I moved the objects around on the Active Directory side, the objects are moved on the 389 side, however the manager attribute is still not updated correctly.

I also did an additional test of moving user objects on the 389 side that are within the sync agreement with Active Directory.  When I do this, it looks like it breaks the sync agreement with Active Directory.  I enabled replication logging and grabbed the following:

[18/Oct/2011:11:13:12 -0700] - Calling dirsync search request plugin
[18/Oct/2011:11:13:12 -0700] - Sending dirsync search request
[18/Oct/2011:11:13:12 -0700] NSMMReplicationPlugin - changelog program - _cl5GetDBFileByReplicaName: found DB object 8a38020 for database /var/lib/dirsrv/slapd-localhost/changelogdb/67603202-1dd211b2-9515c5f9-52d77ef8_4e9dbbf5000000010000.db4
[18/Oct/2011:11:13:12 -0700] NSMMReplicationPlugin - ruv_update_ruv: successfully committed csn 4e9dc1b8000000010000
[18/Oct/2011:11:13:12 -0700] NSMMReplicationPlugin - agmt="cn=Test" (10:389): Beginning linger on the connection
[18/Oct/2011:11:13:12 -0700] NSMMReplicationPlugin - agmt="cn=Test" (10:389): State: sending_updates -> wait_for_changes
[18/Oct/2011:11:13:12 -0700] NSMMReplicationPlugin - agmt="cn=Test" (10:389): State: wait_for_changes -> ready_to_acquire_replica
[18/Oct/2011:11:13:12 -0700] - acquire_replica, supplier RUV:
[18/Oct/2011:11:13:12 -0700] NSMMReplicationPlugin - supplier: {replicageneration} 4e9dbbf5000000010000
[18/Oct/2011:11:13:12 -0700] NSMMReplicationPlugin - supplier: {replica 1 ldap://localhost.localdomain:389} 4e9dbc3d000000010000 4e9dc1b8000100010000 4e9dc1b8
[18/Oct/2011:11:13:12 -0700] - acquire_replica, consumer RUV:
[18/Oct/2011:11:13:12 -0700] NSMMReplicationPlugin - consumer: {replicageneration} 4e9dbbf5000000010000
[18/Oct/2011:11:13:12 -0700] NSMMReplicationPlugin - consumer: {replica 1 ldap://localhost.localdomain:389} 4e9dbc3d000000010000 4e9dc15f000100010000 00000000
[18/Oct/2011:11:13:12 -0700] - acquire_replica, supplier RUV is newer
[18/Oct/2011:11:13:12 -0700] NSMMReplicationPlugin - agmt="cn=Test" (10:389): Cancelling linger on the connection
[18/Oct/2011:11:13:12 -0700] NSMMReplicationPlugin - windows_acquire_replica returned success (101)
[18/Oct/2011:11:13:12 -0700] NSMMReplicationPlugin - agmt="cn=Test" (10:389): State: ready_to_acquire_replica -> sending_updates
[18/Oct/2011:11:13:12 -0700] - csngen_adjust_time: gen state before 4e9dc1b80004:1318961592:0:0
[18/Oct/2011:11:13:12 -0700] NSMMReplicationPlugin - changelog program - _cl5GetDBFile: found DB object 8a38020 for database /var/lib/dirsrv/slapd-localhost/changelogdb/67603202-1dd211b2-9515c5f9-52d77ef8_4e9dbbf5000000010000.db4
[18/Oct/2011:11:13:12 -0700] - _cl5PositionCursorForReplay (agmt="cn=Test" (10:389)): Consumer RUV:
[18/Oct/2011:11:13:12 -0700] NSMMReplicationPlugin - agmt="cn=Test" (10:389): {replicageneration} 4e9dbbf5000000010000
[18/Oct/2011:11:13:12 -0700] NSMMReplicationPlugin - agmt="cn=Test" (10:389): {replica 1 ldap://localhost.localdomain:389} 4e9dbc3d000000010000 4e9dc15f000100010000 00000000
[18/Oct/2011:11:13:12 -0700] - _cl5PositionCursorForReplay (agmt="cn=Test" (10:389)): Supplier RUV:
[18/Oct/2011:11:13:12 -0700] NSMMReplicationPlugin - agmt="cn=Test" (10:389): {replicageneration} 4e9dbbf5000000010000
[18/Oct/2011:11:13:12 -0700] NSMMReplicationPlugin - agmt="cn=Test" (10:389): {replica 1 ldap://localhost.localdomain:389} 4e9dbc3d000000010000 4e9dc1b8000100010000 4e9dc1b8
[18/Oct/2011:11:13:12 -0700] agmt="cn=Test" (10:389) - session start: anchorcsn=4e9dc15f000100010000
[18/Oct/2011:11:13:12 -0700] NSMMReplicationPlugin - changelog program - agmt="cn=Test" (10:389): CSN 4e9dc15f000100010000 found, position set for replay
[18/Oct/2011:11:13:12 -0700] agmt="cn=Test" (10:389) - load=1 rec=1 csn=4e9dc1b8000000010000
[18/Oct/2011:11:13:12 -0700] NSMMReplicationPlugin - agmt="cn=Test" (10:389): windows_replay_update: Looking at rename operation local dn="uid=user.one,ou=hr,ou=people,dc=example,dc=com" (ours,user,not group)
[18/Oct/2011:11:13:12 -0700] NSMMReplicationPlugin - agmt="cn=Test" (10:389): map_entry_dn_outbound: looking for AD entry for DS dn="uid=user.one,ou=Finance,ou=People,dc=example,dc=com" guid="10c4a0a92d45114fb624b7cd73d691c4"
[18/Oct/2011:11:13:12 -0700] - Calling windows entry search request plugin
[18/Oct/2011:11:13:12 -0700] - windows_search_entry: received 2 messages, 1 entries, 0 references
[18/Oct/2011:11:13:12 -0700] NSMMReplicationPlugin - agmt="cn=Test" (10:389): map_entry_dn_outbound: return code 0 from search for AD entry dn="<GUID=10c4a0a92d45114fb624b7cd73d691c4>" or dn="CN=User 1,OU=HR,DC=example,DC=local"
[18/Oct/2011:11:13:12 -0700] NSMMReplicationPlugin - agmt="cn=Test" (10:389): windows_replay_update: Processing rename operation local dn="uid=user.one,ou=hr,ou=people,dc=example,dc=com" remote dn="<GUID=10c4a0a92d45114fb624b7cd73d691c4>"
[18/Oct/2011:11:13:12 -0700] NSMMReplicationPlugin - agmt="cn=Test" (10:389): Received result code 53 (00000057: LdapErr: DSID-0C0909A4, comment: Old RDN must be deleted, data 0, vece) for rename operation 
[18/Oct/2011:11:13:12 -0700] NSMMReplicationPlugin - agmt="cn=Test" (10:389): Consumer failed to replay change (uniqueid 8b237809-1dd211b2-9515c5f9-52d77ef8, CSN 4e9dc1b8000000010000): DSA is unwilling to perform. Will retry later.
[18/Oct/2011:11:13:12 -0700] agmt="cn=Test" (10:389) - session end: state=0 load=1 sent=1 skipped=0
[18/Oct/2011:11:13:12 -0700] NSMMReplicationPlugin - agmt="cn=Test" (10:389): Beginning linger on the connection
[18/Oct/2011:11:13:12 -0700] NSMMReplicationPlugin - agmt="cn=Test" (10:389): State: sending_updates -> start_backoff
[18/Oct/2011:11:13:15 -0700] NSMMReplicationPlugin - agmt="cn=Test" (10:389): State: start_backoff -> backoff

Comment 3 Brian Junker 2011-10-18 18:42:21 UTC

I'm sorry, on the last comment, where I mentioned the following:

I also did an additional test of moving user objects on the 389 side that are
within the sync agreement with Active Directory.  When I do this, it looks like
it breaks the sync agreement with Active Directory.  I enabled replication
logging and grabbed the following.

I just discovered that I had deleteoldrdn set to 0, when I set it to 1, it moved the object in Active Directory properly.

Comment 4 Rich Megginson 2011-10-18 21:12:26 UTC

Looks like the problem here is that referential integrity does not work for internal operations, such as are generated by windows sync.  We should allow referint to be used for internal operations.  The memberof code is an example of a post op plugin that can be used for both external and internal operations.

Comment 7 Martin Kosek 2012-01-04 13:21:36 UTC

Upstream ticket:
https://fedorahosted.org/389/ticket/31

Comment 9 Noriko Hosoi 2015-11-19 23:27:44 UTC

Original summary: WinSync: Manager attribute not updated when object moved in Active Directory

Comment 11 mreynolds 2015-12-22 20:41:50 UTC

This was essentially fix by https://bugzilla.redhat.com/show_bug.cgi?id=410951 where you can configure the RI plugin to process replicated ops.  This would cover the winsync scenario.

Closing as duplicate

*** This bug has been marked as a duplicate of bug 410951 ***