Replication USN semantics around Azure AD Connect
Andrew Bartlett
abartlet at samba.org
Thu Jun 29 06:19:02 UTC 2023
On Wed, 2023-06-28 at 10:15 +0200, Stefan Metzmacher wrote:
> Hi Andrew,
> > I've been working to make Azure AD connect work with Samba.
> > This is working for small domains, but for larger domains we hit
> > aproblem.
> > Our USN handling in GetNCChanges can sometimes return the
> > sametmp_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,
> > egreserved_usn is always zero. This means we declare the client-
> > suppliedhighwatermark as being older, and start replication from
> > scratch.
> > Starting from zero then means we give the same data, end in the
> > sameplace and the client has an infinite loop against us.
> > Do you have any clues, other than a revamp of our replication
> > logic, tofix this both sort-term and to remember for the longer
> > term?
> > In the meantime I've suggested 'drs max objects sync = 100000' and
> > 'drsmax 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
> toWindows 2008R2. But I don't remember it 100%.
> Currently we're using these branches to avoid it:
> https://git.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/v4-10-drsuapi
> https://git.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/v4-13-drsuapi
>
> 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.
Thanks. I've taken a look over those, but I don't see how it would
impact on the USN or the highwatermark.
Am I missing something in those changes that would help ensure the USN
keeps moving or could this be a different loop?
Andrew Bartlett
--
Andrew Bartlett (he/him) https://samba.org/~abartlet/
Samba Team Member (since 2001) https://samba.org
Samba Team Lead https://catalyst.net.nz/services/samba
Catalyst.Net Ltd
Proudly developing Samba for Catalyst.Net Ltd - a Catalyst IT group
company
Samba Development and Support: https://catalyst.net.nz/services/samba
Catalyst IT - Expert Open Source Solutions
More information about the samba-technical
mailing list