Incoming replicated object are missing an explicit rdn attribute,
so the receiving server needs to generate the attribute, using
the dn and name attribute.
The following commit was meant to fix that:
Author: Andrew Bartlett <firstname.lastname@example.org>
Date: Wed May 25 14:49:31 2016 +1200
dsdb: Fix rename and RDN handling for replPropertyMetaData
This matches Windows 2012R2, which both has the RDN not sorted last and has it updated with the local
invocation_id and a local version.
The RDN attribute, unlike name, is not replicated over DRS, so the impact for interopability extends only to
the incorrect RDN values that we were finding with dbcheck (values that did not match the name values).
Finally, we always force the RDN to match the name attribute, which avoids issues
in dbcheck where these diverge. As such, we can finally remove dbcheck as a
flapping test, last re-added in e4bab3a8282d263eb2391bc7e8a6fd64ae068935
Signed-off-by: Andrew Bartlett <email@example.com>
Reviewed-by: Garming Sam <firstname.lastname@example.org>
But it uses the raw RDN attribute name from the dn.
For CN=Users,DC=example,DC=com it will
add "CN: Users", but it should normalize the name
via the schema and add 'cn: Users' instead.
We'll need a code change and some dbcheck magic to fix broken databases.
Created attachment 12611 [details]
Part1 patch for master
(In reply to Stefan Metzmacher from comment #1)
This looks like a very reasonable way to fix that.
*** Bug 12302 has been marked as a duplicate of this bug. ***
Created attachment 12655 [details]
Work in progress patches including dbcheck support (untested!)
For now use "Part1 patch for master" on production systems to avoid
the problem in the first place.
(In reply to Stefan Metzmacher from comment #4)
Is the primary issue here the lack of tests for the dbcheck work, or is this otherwise still a WIP?
I may be able to help with dbcheck testing, as I've done a fair bit of that recently.
(In reply to Andrew Bartlett from comment #5)
It's work in progress it misses this:
TODO: we should do this fix up after a possible rename
via self.err_wrong_dn(), that rename is more important
and may already fix the problem...
Attachment #12611 [details] (Part1 patch for master) I pushed to autobuild and it is in master as ec0297bbd0110f8bfddda2e21d94a882094d1c11.
Created attachment 12853 [details]
Patch for v4-5-test
Reassigning to Karolin for inclusion in 4.5.
Please resassing to metze after pushing to 4.5, so he can pursue with the dbcheck fixes.
(In reply to Ralph Böhme from comment #9)
Pushed to autobuild-v4-5-test
(In reply to Stefan Metzmacher from comment #10)
Pushed to v4-5-test.
Closing out bug report.
Reopening and assigning to metze as per my comment #9.