Replication USN semantics around Azure AD Connect
metze at samba.org
Wed Jun 28 08:15:27 UTC 2023
> I've been working to make Azure AD connect work with Samba.
> This is working for small domains, but for larger domains we hit a
> Our USN handling in GetNCChanges can sometimes return the same
> tmp_hightest_usn, so we have this code:
> * We need to make sure that we never return the
> * same highwatermark within the same replication
> * cycle more than once. Otherwise we cannot detect
> * when the client uses an unexptected highwatermark.
> * This is a HACK which is needed because our
> * object ordering is wrong and set tmp_highest_usn
> * to a value that is higher than what we already
> * sent to the client (destination dsa).
> r->out.ctr->ctr6.new_highwatermark.reserved_usn += 1;
> To make a new higher USN for this case.
> However, Azure AD connect comes back only with the tmp_highest_usn, eg
> reserved_usn is always zero. This means we declare the client-supplied
> highwatermark as being older, and start replication from scratch.
> Starting from zero then means we give the same data, end in the same
> place and the client has an infinite loop against us.
> Do you have any clues, other than a revamp of our replication logic, to
> fix this both sort-term and to remember for the longer term?
> In the meantime I've suggested 'drs max objects sync = 100000' and 'drs
> max link sync = 100000' in the smb.conf to avoid multiple chunks.
> Thanks for any clues,
I think I hit some similar when migrating large samba domains to
Windows 2008R2. But I don't remember it 100%.
Currently we're using these branches to avoid it:
They are also in https://git.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master-drsuapi,
as the top 16 commits, but that also contains a lot of unfinished unrelated stuff, e.g. implementing timed group memberships.
More information about the samba-technical