Bug 13039 - Samba resolves object DN conflicts differently to Microsoft
Summary: Samba resolves object DN conflicts differently to Microsoft
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: 4.7.0rc6
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-09-19 03:12 UTC by Tim Beale
Modified: 2021-02-26 19:15 UTC (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Beale 2017-09-19 03:12:41 UTC 
If 2 objects on 2 different DCs end up with the same DN, then when the DCs replicate with each other, they should resolve this conflict by renaming one of the objects. Currently, Samba may rename a different object compared to Microsoft.

If the RMD_VERSION for the objects (name attribute) differs, then Samba will pick the object with the highest RMD_VERSION. Currently Microsoft seems to ignore RMD_VERSION and just uses the time-stamp and GUID to resolve the conflict.

This could cause problems in a mixed network with both Samba and Microsoft DCs. I haven't tested it, but presumably the conflicting DN would end up using a different GUID on the Microsoft DC compared to the Samba DC.

Windows behaviour seems to match their current spec (4.1.10.6.12 ResolveNameConflict).
https://msdn.microsoft.com/en-us/library/dd207782.aspx

Note if working on this bug: If possible, it might be worth testing the behaviour when the timestamps are identical. From the Docs, it looks like Microsoft may use the object GUID whereas Samba uses the DC GUID (originating_invocation_id).