Description of problem: Winsync plugin fails to synchronize the deletion of user entries from AD to DS. The users were actually created and synced from DS to AD. Version-Release number of selected component (if applicable): How reproducible: Consistently Steps to Reproduce: 1. Install 389-ds-base latest packages and configure WinSync, bi-directional. 2. Run "Initiate Full-Resynchronization" to sync entries from both sides. 3. Once the users are in sync at both sides, create an user at DS. 4. Check whether the user is synced to AD. Synced successfully to AD. 5. Delete the user at AD, which is synced from DS to AD. 6. Create few more users at DS to be synced to AD. This step is required to reproduce the exact problem. 7. Click on "Send and Receive Updates Now" option now. 8. User deletion fails to sync to DS. Actual results: Users deletion not synced from AD to DS. Expected results: Users deletion should be synced irrespective where the entry is created. Additional info: I couldn't succeed syncing the deletion from AD to DS, though I tried restarting DS, restarting Pass Sync service on AD and many times "Send and Receive Updates now" option. No error messages printed in the access/error logs.
This is likely caused by a dirsync operation not occurring between the add of the user being sync'd to AD and the deletion happening on the AD side. The user on the DS and AD side are not completely tied together until the add operation comes back to DS full circle as a part of the dirsync update. I'll do some tests, but I'm fairly certain that this issue would not happen if the dirsync update is run between steps 4 and 5 (either by waiting 5 minutes for the sync interval, or by doing a "Send and Receive Updates Now").
When add operation that originated on DS comes back around from AD as a part of the dirsync update, we get the ntUniqueId value from AD and update the DS entry with the value. When a deletion on AD is picked up by DS as a part of the dirsync update, we get an AD tombstone entry. To map an AD tombstone to it's matching DS entry, we need to use the GUID that is used as part of the tombstone naming. If we don't yet have the GUID stored on the DS side in the ntUniqueID attribute, we can't map the AD tombstone to the matching DS entry. This is why we don't delete the DS entry. Here's a snippet of this happening in the errors log: -------------------------------------------------------------------------------- [09/Aug/2011:09:58:29 -0700] NSMMReplicationPlugin - received entry from dirsync: CN=Delete Me\0ADEL:904b6248-0574-4470-8e53-8f9dd3e05648,CN=Deleted Objects,DC=example,DC=com [09/Aug/2011:09:58:29 -0700] NSMMReplicationPlugin - agmt="cn=meTo10.14.54.184389" (10:389): windows_process_dirsync_entry: failed to map tombstone dn. -------------------------------------------------------------------------------- I believe that this issue is not a bug, as it's by design that we don't sync a delete unless the GUID has been sync'd. It's also not a regression and is also an uncommon case, so I feel that the behavior is acceptable. If one waits 5 minutes (or uses a shorter dirsync interval), the deletion will sync just fine. Closing this as NOTABUG.