Bug 13039 - Samba resolves object DN conflicts differently to Microsoft
Samba resolves object DN conflicts differently to Microsoft
Status: NEW
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB
4.7.0rc6
All All
: P5 normal
: ---
Assigned To: Andrew Bartlett
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-09-19 03:12 UTC by Tim Beale
Modified: 2017-09-19 03:12 UTC (History)
0 users

See Also:


Attachments

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).