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 739677 - Apply referential integrity against the internal operations such as WinSync.
Summary: Apply referential integrity against the internal operations such as WinSync.
Keywords:
Status: CLOSED DUPLICATE of bug 410951
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.0
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: rc
: 7.3
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks: 389_1.3.0 690319
TreeView+ depends on / blocked
 
Reported: 2011-09-19 19:16 UTC by Brian Junker
Modified: 2020-09-13 19:46 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-22 20:41:50 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 31 0 None None None 2020-09-13 19:46:23 UTC

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