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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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>
