mirror of
https://github.com/samba-team/samba.git
synced 2025-01-07 17:18:11 +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
|
||
|---|---|---|
| .. | ||
| backupkey | ||
| browser | ||
| common | ||
| dnsserver | ||
| drsuapi | ||
| echo | ||
| epmapper | ||
| eventlog | ||
| lsa | ||
| netlogon | ||
| remote | ||
| samr | ||
| srvsvc | ||
| tests | ||
| unixinfo | ||
| winreg | ||
| wkssvc | ||
| dcerpc_server.c | ||
| dcerpc_server.h | ||
| dcerpc_server.pc.in | ||
| service_rpc.c | ||
| wscript_build | ||