The Samba-Bugzilla – Bug 12013
domain join is not as strict on integrity check as standard replication
Last modified: 2016-07-06 22:34:46 UTC
When doing a "samba-tool domain join", the integrity checks that are run are not the same as for replication.
For instance, you can have a "samba-tool domain join" that finishes happily (ie. join succeed, samba start, samba-tool drs showrepl is fine both ways), but it actually copied corrupted entries (ie entries that cannot be replicated).
Those corrupted entries will stayed dormant as long as there is not replication on that specific entry. As soon as you have replication on the corrupted attribute, the replication will fail each time.
I'd say a good practice would be to join the new DC with the --domain-critical-only options, so most objects are going through the standard replication and integrity checks.
It would be more coherent to have the same integrity checks to apply when doing standard join or replication
An example that trigger this issue is bug #12012 . The join process will succeed and dc will start and work properly and replicate, but replication will fail when one trigger a change on a SD. If I do a join with the --domain-critical-only option, it would show directly the problem.
I think "domain join" should be at least as strict on integrity as replication in order to show problems as early as possible.
Can you retry on master?
We have fixed a lot of replication bugs.
That said, it is largely the same code that processes the replication in both samba-tool and in the runtime server, so I'm very keen to learn what is going wrong here.