IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
These tests are not affected by the reserved_usn change, so there is
no need to run them twice.
The test_repl_get_tgt_multivalued_links fails with or without
reserved_usn set to zero, but it fails differently in either case.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15701
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Jennifer Sutton <josutton@catalyst.net.nz>
This emulates the behaviour of Azure AD.
As this is quite slow we will later reduce the test load in this case,
but for now we want to run all the getncchanges tests this way.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15701
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Jennifer Sutton <josutton@catalyst.net.nz>
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.
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>
This changes the GetNCChanges server to use a per-call state for
extended operations like RID_ALLOC or REPL_OBJ and only maintain
and (more importantly) invalidate the state during normal replication.
This allows REPL_OBJ to be called during a normal replication cycle
that continues using after that call, continuing with the same
highwatermark cookie.
Azure AD will do a sequence of (roughly)
* Normal replication (objects 1..100)
* REPL_OBJ (of 1 object)
* Normal replication (objects 101..200)
However, if there are more than 100 (in this example) objects in the
domain, and the second replication is required, the objects 1..100
are sent, as the replication state was invalidated by the REPL_OBJ call.
RN: Improve GetNChanges to address some (but not all "Azure AD Connect")
syncronisation tool looping during the initial user sync phase.
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>
The NC root, on any replication when it appears, is the first object to be
replicated, including for all subsequent chunks in the replication.
However the tmp_highest_usn is not updated by that USN, it must
only be updated for the non-NC changes (to match Windows exactly),
or at least only updated with the non-NC changes until it would
naturally appear.
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>
This demonstrates the behaviour used by the "Azure AD Connect" cloud sync tool.
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>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=10635
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Stefan Metzmacher <metze@samba.org>
Autobuild-Date(master): Tue Jan 31 13:43:54 UTC 2023 on atb-devel-224
This allows our new tests to pass as these need to be checked first.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=10635
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
We want to totally ignore the string DN if there is a GUID,
as clients like "Microsoft Azure AD connect cloud sync" will
set a literal "DummyDN" string.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=10635
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
This make this funciton the gatekeeper between the wire format and the
internal struct ldb_dn, checking if the DN exists and which NC
it belongs to along the way, and presenting only a DB-returned
DN for internal processing.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=10635
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
We no longer run any *python2* or *python3* specific tests, so
these knownfail lines are just clutter.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Jeremy Allison <jra@samba.org>
Cross-partition links could still be dropped if GET_TGT was already
previously set for the replication.
This was due to a slight error in the order of logic. We never want to
ignore cross-partition links (regardless of whether the TARGETS_UPTODATE
/GET_TGT flag is set). We should only be returning early in the
GET_TGT case if the objects are both in the same partition.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14022
RN: When the AD domain contained a linked attribute that spanned
partitions, DRS replication could drop the link. This dropped link could
then result in subtle differences in behaviour between DCs, as some DCs
would have the link and others wouldn't. When this issue occurred, the
dropped link would be logged in a warning message:
"<target-dn> is Unknown but up to date. Ignoring link from <source-dn>"
This issue would not always occur - it depended a lot on the database
contents. Typically, it would only potentially occur when joining a new
DC to the domain (doing an ldapcmp after the join would also highlight
the problem, if it occurred). This issue has now been resolved.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This adds a test-case to highlight a bug in the client side GetNCChanges
handling.
These tests mostly exercise the server-side behaviour of sending the
GetNCChanges, however, there's a bug in the client-side code when we try
to handle a missing cross-partition link target *in combination* with
the GET_TGT flag already having been set.
The test is exercising the client-side code by using the 'samba-tool drs
replicate' command. By adding a one-way link to a deleted target object,
we force the client code to retry with the GET_TGT flag set.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14022
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Post build & test running under python3 we now run with
'--extra-python=/usr/bin/python2', these tests will get
python2 appended to the test name so we need also to create
new knownfails for these. We will keep the python3 versions
in case we create (and we probably should) some CI job(s)
with
PYTHON=python configure.developer --extra-python=/usr/bin/python3
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Add a test where a source object links to multiple different targets.
First we do the replication without GET_TGT and check that the server
can handle sending a chunk containing only links (in the middle of the
replication). Then we repeat the replication forcing GET_TGT to be used.
To avoid having to create 1500 objects/links, I've lowered the 'max
link sync' setting on the vampire_dc testenv to 250.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
This adds basic DRS_GET_TGT support. If the GET_TGT flag is specified
then the server will use the object cache to store the objects it sends
back. If the target object for a linked attribute is not in the cache
(i.e. it has not been sent already), then it is added to the response
message.
Note that large numbers of linked attributes will not be handled well
yet - the server could potentially try to send more than will fit in a
single repsonse message.
Also note that the client can sometimes set the GET_TGT flag even if the
server is still sending the links last. In this case, we know the client
supports GET_TGT so it's safe to send the links interleaved with the
source objects (the alternative of fetching the target objects but not
sending the links until last doesn't really make any sense).
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
Add tests that delete the source and target objects for linked
attributes in the middle of a replication cycle.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
The code has to handle needing GET_ANC and GET_TGT in combination, i.e.
where we fetch the target object for the linked attribute and the target
object's parent is unknown as well. This patch adds a test case to
exercise this code path.
The second part of this test exercises GET_ANC/GET_TGT for an
incremental replication, where the objects are getting filtered by an
uptodateness-vector/HWM.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
We have identified a case where the Samba server can send linked
attributes but not the target object. In this case, the Samba DRS client
would hit the "Failed to re-resolve GUID" case in replmd and silently
discard the linked attribute.
However, Samba will resend the linked attribute in the next cycle
(because its USN is still higher than the committed HWM), so it should
recover OK. On older releases, this may have caused problems if the
first error resulting in a hanging link (which might mean the second
time it's processed it still fails to be added).
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
test_repl_get_tgt:
- Adds 2 sets of objects
- Links one set to the other
- Changes the order so the target object comes last in the
replication (which means the client has to use GET_TGT)
- Checks that when GET_TGT is used that we have received all target
objects we need to resolve the linked attibutes
- Checks that we expect to receive the linked attributes *before*
the last chunk is sent (by default, Samba sends all the links at
the end, so this fails)
- Checks that we eventually receive all expected objects, and all
links we receive match what is expected
test_repl_get_tgt_chain:
This adds the linked attributes in a more complicated chain. We add
300 objects, but the links for 100 objects will point to a linked
chain of 200 objects.
This was mainly to determine whether or not Windows follows the
target object (i.e. whether it sends all the links for the target
object as well). It turns out Windows maintains its own linked
attribute DB, so it sends the links based on USN.
Note that the 2 testenvs fail for different reasons. promoted_dc fails
because it is sending all the linked attributes last. vampire_dc fails
because it doesn't support GET_TGT yet, so it sends the link before the
peer knows about the target object.
Note that to test against vampire_dc (rather than the ad_dc_ntvfs DC),
we need to send the GetNCChanges requests to DC2 instead of DC1.
I've left the DC numbering scheme as is, but I've addeed a test_ldb_dc
handle to drs_base.py - it defaults to DC1, but tests can override it
easily and still have everything work.
While running the new tests through autobuild, I noticed an intermittent
LDAP_ENTRY_ALREADY_EXISTS failure in the test setup(). This appears to
be due to a timing issue in the background replication between the
multiple testenvs. Adding some randomness so that the test base OU is
unique seems to avoid the problem.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
