mirror of
https://github.com/samba-team/samba.git
synced 2025-01-22 22:04:08 +03:00
8923162028
We send the NC root first, as a special case for every chunk that we send until the natural point where it belongs. We do not bump the tmp_highest_usn in the highwatermark that the client and server use (it is meant to be an opauqe cookie) until the 'natural' point where the object appears, similar to the cache for GET_ANC. The issue is that without this, because the NC root was sorted first in whatever chunk it appeared in but could have a 'high' highwatermark, Azure AD Connect will send back the same new_highwatermark->tmp_highest_usn, and due to a bug, a zero reserved_usn, which makes Samba discard it. The reserved_usn is now much less likely to ever be set because the tmp_higest_usn is now always advancing. RN: Avoid infinite loop in initial user sync with Azure AD Connect when synchronising a large Samba AD domain. BUG: https://bugzilla.samba.org/show_bug.cgi?id=15401 Signed-off-by: Andrew Bartlett <abartlet@samba.org> Reviewed-by: Stefan Metzmacher <metze@samba.org> (cherry picked from commit 79ca6ef28a6f94965cb030c4a7da8c1b9db7150b) Autobuild-User(v4-17-test): Jule Anger <janger@samba.org> Autobuild-Date(v4-17-test): Mon Aug 21 08:42:32 UTC 2023 on sn-devel-184