Apply referential integrity against the internal operations such as WinSync.

[389-ds-bot]

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/31

• Created at 2012-01-04 19:21:32 by mkosek
• Closed as Duplicate
• Assigned to nobody
• Associated bugzillas
  • https://bugzilla.redhat.com/show_bug.cgi?id=739677

---

https://bugzilla.redhat.com/show_bug.cgi?id=739677

Description of problem:

Now that 389 has support for moving an entry in AD when moved between OU's.hat 
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:

[389-ds-bot]

Comment from rmeggins (@richm) at 2012-01-06 22:12:26

not really sync service ''per se'' - the referential integrity plugin should work on internal operations such as those generated by winsync

[389-ds-bot]

Comment from rmeggins (@richm) at 2012-01-10 06:14:47

batch move to milestone future

[389-ds-bot]

Comment from rmeggins (@richm) at 2012-08-14 19:57:05

set default ticket origin to Community

[389-ds-bot]

Comment from nkinder (@nkinder) at 2012-08-28 04:14:46

Added initial screened field value.

[389-ds-bot]

Comment from nhosoi (@nhosoi) at 2015-11-20 01:31:39

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

Comment by Rich:
https://bugzilla.redhat.com/show_bug.cgi?id=739677#c4

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.

[389-ds-bot]

Comment from nhosoi (@nhosoi) at 2015-11-20 01:33:15

Is this still true?

referential integrity does not work for internal operations

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2015-12-23 02:40:43

This was essentially fix by https://fedorahosted.org/389/ticket/218 where you can configure the RI plugin to process replicated ops. This would cover the winsync scenario.

[389-ds-bot]

Comment from nhosoi (@nhosoi) at 2017-02-11 23:09:19

Metadata Update from @nhosoi:

• Issue set to the milestone: FUTURE