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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
samba-net-join links to python and so needs the variable name
with the python ABI tag, while samba-net is a normal C library
and can be included in a package without python dependencies.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Alexander Bokovoy <ab@samba.org>
Found by covscan.
Signed-off-by: Pavel Filipenský <pfilipen@redhat.com>
Reviewed-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
The current length of 128-255 UTF-16 characters currently causes
generation of crypt() passwords to typically fail. This commit
decreases the length to 120 UTF-16 characters, which is the same as
that used by Windows.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14621
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
From v4.8 onwards, Samba may not be able join a DC older than 2008R2
because the Windows DC doesn't support GET_TGT.
If the dsdb repl_md code can't resolve a link target it returns an
error, and the calling code (e.g. drs_util.py) should retry with
GET_TGT. However, GET_TGT is only supported on Windows 2008R2 and later,
so if you try to join an earlier Windows DC, the join will throw an
error that you can't work-around.
We can avoid this problem by setting the same DSDB flag that GET_TGT
sets to indicate that the link targets are as up-to-date as possible,
and so there's no point retrying. Missing targets are still logged, so
this at least allows the admin to fix up any problems after the join
completed.
I've only done this for the join case (problems during periodic
replication are probably still worth escalating to an error).
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14021
RN: From Samba v4.8 onwards, joining a Windows 2003 or 2008 (non-R2) AD
DC may not have worked. When this problem occurred, the following
message would be displayed:
'Failed to commit objects: DOS code 0x000021bf'
This particular issue has now been resolved. Note that there may still
be other potential problems that occur when joining an older Windows DC.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
provision_get_schema returns a ldb_context object which is stored
in a python object. As a result the parent python object is never
decrefed and probably not released ever.
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reset the debug counters once we have finished replicating a given
partition. This helps if we replicate the same partition immediately
afterward with different options.
This helps the DC join debug look less weird. Because it replicates the
critical objects first, and then the base partition, previously it
always ended up overcounting, e.g.
Partition[DC=addom,DC=samba,DC=example,DC=com] objects[314/218]
linked_values[48/24]
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Update the replication debug (for joins/backups) so that it's easier to
see how far through syncing the links we are. E.g. with 150,000 links,
you just get screeds of debug like this, with no real idea how far
through the replication is.
Partition[DC=addom,DC=samba,DC=example,DC=com] objects[11816/11720]
linked_values[1500/150024]
Partition[DC=addom,DC=samba,DC=example,DC=com] objects[11816/11720]
linked_values[1500/150024]
Partition[DC=addom,DC=samba,DC=example,DC=com] objects[11816/11720]
linked_values[1500/150024]
This patch now applies to links the same debug logic we use for objects,
and changes it to look like:
Partition[DC=addom,DC=samba,DC=example,DC=com] objects[11816/11720]
linked_values[57024/150024]
Partition[DC=addom,DC=samba,DC=example,DC=com] objects[11816/11720]
linked_values[58524/150024]
Partition[DC=addom,DC=samba,DC=example,DC=com] objects[11816/11720]
linked_values[60024/150024]
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Signed-off-by: Andrej Gessel <Andrej.Gessel@janztec.com>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
In schema_load_init, we find that the writing of indices is not locked
in any way. This leads to race conditions. To resolve this, we need to
have a new state (SCHEMA_COMPARE) which can report to the caller that we
need to open a transaction to write the indices.
Signed-off-by: Garming Sam <garming@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This is used in the client and in the server
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
We are going to end up supporting 2 different server schemes:
A. the old/default behaviour of sending all the linked attributes last,
at the end of the replication cycle.
B. the new/Microsoft way of sending the linked attributes interleaved
with the source/target objects.
Normally if we're talking to a server using the old scheme-A, we won't
ever use the GET_TGT flag. However, there are a couple of cases where
it can happen:
- A link to a new object was added during the replication cycle.
- An object was deleted while the replication was in progress (and
the linked attribute got queued before the object was deleted).
Talking to an Samba DC running the old scheme will just cause it to
start the replication cycle from scratch again, which is fairly
harmless. However, there is a chance that the same thing can happen
again, in which case the replication cycle will fail (because GET_TGT
was already set).
Even if we're using the new scheme (B), we could still potentially hit
this case, as we can still queue up linked attributes between requests
(group memberships can be larger than what can fit into a single
replication chunk).
If GET_TGT is set in the GetNcChanges request, then the local copy of
the target object should always be up-to-date when we process the linked
attribute. So if we still think the target object is deleted/recycled at
this point, then it's safe to ignore the linked attribute (because we
know our local copy is up-to-date). This logic matches the MS spec logic
in ProcessLinkValue().
Not failing the replication cycle may be beneficial if we're trying to
do a full-sync of a large database. Otherwise it might be time-consuming
and frustrating to repeat the sync unnecessarily.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Garming Sam <garming@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=12972
If the DRS client received a linked attribute that it couldn't resolve
the target for, then it would just ignore that link and keep going. That
link would then be lost forever (although a full-sync would resolve
this). Instead of silently ignoring the link, fail the transaction.
This *can* happen on Samba, but it is unusual. The target object and
linked-attribute would need to be added while a replication is still in
progress. It can also happen fairly easily when talking to a Windows DC.
There are two import exceptions to this:
1). Linked attributes that span partitions. We can never guarantee that
we will have received the target object, because it may be in a partition
we haven't replicated yet. Samba doesn't have a great way of handling
this currently, but we shouldn't fail the replication (because that breaks
basic join tests). Just skip that linked attribute and hope that a
subsequent full-sync will fix it.
(I queried Microsoft and they said resolving cross-partition linked
attributes is a implementation-specific problem to solve. GET_TGT won't
resolve it)
2). When the replication involves a subset of objects, e.g.
critical-only. In these cases, we don't increase the highwater-mark, so
it is probably not such a dire problem if we don't add the link. In the
case of critical-only, we will do a subsequent full sync which will then
add the links.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Garming Sam <garming@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=12972
Instead, write it once in the module init, if required, and after a
modify to the schema partition is detected
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
This may help when an object has been incorrectly locally removed from the NC
or there is an urgent need to replicate a specific object (say when full
replication is inoperable).
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
The WERROR codes are more descriptive for DSDB issues, and almost all the code was
converting from WERROR to NTSTATUS. This will allow us to better catch specific
errors like WERR_DS_DRA_MISSING_PARENT
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=12398
This attempts to make it clear what memory is short term and what memory is long term
BUG: https://bugzilla.samba.org/show_bug.cgi?id=12115
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
When we were processing an EXOP, we would pass in a DN specific to that
operation, but this stopped repl_meta_data from finding the parent object
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
Previously this would only be set when we did server-to-server replication
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
We should never get a secret from a server when we specify DRSUAPI_DRS_SPECIAL_SECRET_PROCESSING
This asserts that this is the case.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
The issue is that the DN contains a pointer to the ldb it belongs to,
and if this is not kept around long enough, we might reference memory
after it is de-allocated.
Andrew Bartlett
Change-Id: I040a6c37a3164b3309f370e32e598dd56b1a1bbb
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Pair-Programmed-With: Matthieu Patou <mat@matws.net>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Thu May 23 14:18:03 CEST 2013 on sn-devel-104
Replicated schema might have attributes and auxilary classes on some
critical classes (ie. top, user, computer ) that are not in the bootstrap
schema. Without those new attributes and classes, bootstrap schema is
unable to translate those critical classes in the schema constructed
from the replicated data. Without thoses classes new schema is useless
and can't be indexed properly.
In order to overcome this problem, we put all new attributes and classes
definitions into the bootstrap schema so that foundations classes can be
translated.
Pair-Programmed-With: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Matthieu Patou <mat@matws.net>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Instead of showing:
Partition[CN=RODC,OU=Domain Controllers,DC=samba,DC=example,DC=com]
objects[1] linked_values[8]
Report a exop based on CN=RODC,OU=Domain Controllers,DC=samba,DC=example,DC=com
as
Exop on CN=RODC,OU=Domain Controllers,DC=samba,DC=example,DC=com, ...
Signed-off-by: Matthieu Patou <mat@matws.net>
Reviewed-By: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Matthieu Patou <mat@samba.org>
Autobuild-Date(master): Wed Jan 9 09:01:30 CET 2013 on sn-devel-104
At that moment we have all the information to set the invocation id so
let's set it, it will avoid useless messages about missing invocation
id.
Signed-off-by: Matthieu Patou <mat@matws.net>
Reviewed-By: Andrew Bartlett <abartlet@samba.org>
Working schema cache will be used to convert replicated Schema objects
again later, i.e. used as reference, so we don't need to resolve all
attribute OIDs for working Schema cache to be usable.
Autobuild-User: Kamen Mazdrashki <kamenim@samba.org>
Autobuild-Date: Tue Mar 1 03:45:16 CET 2011 on sn-devel-104
thi ensures we are using the header corresponding to the version of
ldb we're linking against. Otherwise we could use the system ldb for
link and the in-tree one for include
Pair-Programmed-With: Andrew Bartlett <abartlet@samba.org>
working_schema is to be used while committing a Schema replica.
When we replicate Schema, then we most probably won't be
able to convert all replicated objects using the current
Schema cache (as we don't know anything about those new objects).
Thus, during Schema replication, we make a temporary
working_schema that contains both our current Schema +
all objects we get on the wire.
When we commit those new objects, we should use our working_schema
(by setting it to the ldb), and after all changes are commited,
we can refresh the schema cache so we have a brand new,
full-featured Schema cache
This includes dom_sid.h and security_token.h and will be moved
to the top level shortly.
Andrew Bartlett
Autobuild-User: Andrew Bartlett <abartlet@samba.org>
Autobuild-Date: Tue Oct 12 03:35:36 UTC 2010 on sn-devel-104
