Bug 728499
Summary: | WinSync: Users deletion sync from AD to DS fails, if the user is originated/synced from the DS. | ||
---|---|---|---|
Product: | [Retired] 389 | Reporter: | Sankar Ramalingam <sramling> |
Component: | Sync Service | Assignee: | Rich Megginson <rmeggins> |
Status: | CLOSED NOTABUG | QA Contact: | Chandrasekar Kannan <ckannan> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 1.2.9 | CC: | benl, edewata, nhosoi, nkinder, rmeggins |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-08-09 17:16: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: |
Description
Sankar Ramalingam
2011-08-05 11:10:14 UTC
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. |