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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We were mistakenly asserting something that did not happen with
Windows, because Samba already won't parse the DN string.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=10763
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
9 hex-digit subauths like '0xABCDef123' will not fit in 32 bits, so
should be rejected on parsing.
In other situations, such as defaultSecurityDescriptor, overflowing
SID subauths on Windows will saturate to 0xffffffff, resulting in a
valid but probably meaningless SID. It is possible that in previous
testing we saw that here, but it is more likely I got confused. In any
case, now I see them being rejected, and that is good.
The saturating defaultSecurityDescriptor case is tested in
SidStringBehavioursThatWindowsAllows.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=10763
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
And so should we.
Right now, these tests won't pass against Windows because they rely on
ldb pre-parsing of the SIDs, so they fail before Windows gets to see
them. Running them against Windows looks something like this, BTW:
SAMBA_SID_STRINGS_SKIP_LOCAL=1 \
SMB_CONF_PATH=st/ad_dc/etc/smb.conf \
PYTHONPATH=bin/default/python \
DC_SERVER=192.168.122.126 \
DC_USERNAME=Administrator DC_PASSWORD='xxx' \
python3 python/samba/tests/sid_strings.py
When things are right, the only failing tests should be from the
SidStringBehavioursThatSambaPrefers suite.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=10763
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
It seems as if the well-known SID S-1-5-32-579
(DOMAIN_ALIAS_RID_ACCESS_CONTROL_ASSISTANCE_OPS) is
not always present -- specifically, it was not there on the
Windows machine used to develop these tests, but it is there on
the one I am now using.
S-1-5-32-545 (DOMAIN_ALIAS_RID_USERS) is surely going to exist,
so we use that instead.
That changes some of the assertions, making some NO_SUCH_OBJECTs
into successes.
For these tests we are only interested in the parsing of the SIDs, not
their meaning, so it's OK to change it.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=10763
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
To avoid collisions in random OID strings, we started using the epoch
date modulus 100 million. The trouble is we did not strip out the
leading zeros, so the field might be '00000123' when it should be
'123', if the date happened not to correspond to an epoch with a zero
in the eighth to last place. This has been the case for most of the
last 1041 days, but fortunately the bug was only introduced earlier
this year.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15520
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Martin Schwenke <mschwenke@ddn.com>
No.
That's good and expected because a failure here should fall back to the
next thing in the simple bind pecking order (canonical names).
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
By using an ldb.Dn as an intermediary, we get to see which SIDs
Samba thinks are OK but Windows thinks are bad.
It is things like "S-0-5-32-579".
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
As a way of testing the interpretation of a SID string in a remote
server, we search on the base DN "<SID=x>" where x is a non-existent
or malformed SID.
On Windows some or all malformed SIDs are detected before the search
begins, resulting in a complaint about DN syntax rather than one about
missing objects.
From this we can get a picture of what Windows considers to be
a proper SID in this context.
Samba does not make a distinction here, always returning NO_SUCH_OBJECT.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
The Samba side is aspirational -- what we actually do is generally
worse. However the Windows behaviour in these cases seems more
surprising still, and seems to be neither documented nor used.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
The reason the existing tests send the SID over the wire as SDDL for
defaultSecurityDescriptor is it is one of the few ways to force the
server to reckon with a SID-string as a SID. At least, that's the case
with Windows. In Samba we make no effort to decode the SDDL until it
comes to the time of creating an object, at which point we don't notice
the difference between bad SDDL and missing SDDL.
So here we add a set of dynamic tests that push the strings through our
SDDL parsing code. This doesn't tell us very much more, but it is very
quick and sort of confirms that the other tests are on the right track.
To run against Windows without also running the internal Samba tests,
add `SAMBA_SID_STRINGS_SKIP_LOCAL=1` to your environment variables.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This is going to be useful for another test, soon.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
We are mostly testing edge cases around the handling of numeric
limits.
These tests are based on ground truth established by running them
against Windows.
Many fail against Samba, because the defaulSecurityDescriptor
attribute is not validated at the time it is set while on Windows it
is.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This will allow e.g. a suite of tests that assert Windows behaviour that
we might not choose to follow.
Because @DynamicTestCase will mangle the class as it finds it, we can't
use SidStringTests itself as a superclass for others.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This removes the slim chance of flapping failures, and makes tracking
the created class back to the SID string theoretically possible.
To maintain uniqueness of the governs-id, we in chuck some of the
timestamp.
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
We don't care about the exact time of the test, just that we
disambiguate between different runs (each run leaves an immutable scar
on the target server).
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
sid_strings.py used the same OID range as ldap_schema.py, which
occasionally led to test failures when the same OID was generated twice.
Using a different range, and making use of the expected RID if we have
it, should reduce the likelihood of collisions.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Thu Aug 25 13:55:47 UTC 2022 on sn-devel-184
We get the server to decode the SDDL by putting the SID strings in the
defaultSecurityDescriptor of a new class and making an object of that
class. We then check that the resulting SID is what we expect.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
