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:
not really sync service ''per se'' - the referential integrity plugin should work on internal operations such as those generated by winsync
batch move to milestone future
set default ticket origin to Community
Added initial screened field value.
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.
Is this still true?
referential integrity does not work for internal operations
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.
Metadata Update from @nhosoi: - Issue set to the milestone: FUTURE
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/31
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Duplicate)
Login to comment on this ticket.