Replication USN semantics around Azure AD Connect

[Andrew Bartlett]

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

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,

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