summaryrefslogtreecommitdiff
path: root/python/samba/tests/sid_strings.py
AgeCommit message (Collapse)AuthorFilesLines
2024-05-07pytest: sid_strings: Samba DN object refuses sub-auth overflowDouglas Bagnall1-2/+2
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>
2024-05-07pytest: sid_strings: adjust to match Windows 2016Douglas Bagnall1-2/+2
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>
2024-05-07pytest: sid_strings: Windows does allow lowercase s-1-... SIDsDouglas Bagnall1-2/+4
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>
2024-05-07pytest: sid_strings: use more reliable well known SIDDouglas Bagnall1-6/+6
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>
2023-11-15pytests: sid_strings: do not fail if epoch ending has zerosDouglas Bagnall1-1/+1
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>
2023-11-01pytest: sid_strings: handle SDDLValueErrorDouglas Bagnall1-1/+1
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz> Reviewed-by: Andrew Bartlett <abartlet@samba.org>
2023-10-13python:tests: Correct search expressionJoseph Sutton1-1/+1
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz> Reviewed-by: Andrew Bartlett <abartlet@samba.org>
2023-10-13python:tests: Fix commentJoseph Sutton1-1/+1
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz> Reviewed-by: Andrew Bartlett <abartlet@samba.org>
2023-04-28pytest:sid_strings: Do bad SIDs fail differently in simple-bind?Douglas Bagnall1-0/+36
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>
2023-04-28pytest:sid_strings: do bad SIDS work in search filters?Douglas Bagnall1-0/+22
Yes. Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz> Reviewed-by: Andrew Bartlett <abartlet@samba.org>
2023-04-28pytest:sid_strings: test SID DNs with ldb parsingDouglas Bagnall1-0/+75
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>
2023-04-28pytest:sid_strings: test SIDs as search baseDouglas Bagnall1-0/+69
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>
2023-04-28pytest:sid_strings: Windows and Samba divergent testsDouglas Bagnall1-0/+47
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>
2023-04-28pytest:sid_strings: test the strings with local parsingDouglas Bagnall1-0/+28
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>
2023-04-28pytest:sid_strings: separate out expected_sid formattingDouglas Bagnall1-6/+10
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>
2023-04-28pytest:sid_strings: add explicit S-1-* sid testsDouglas Bagnall1-1/+45
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>
2023-04-28pytest:sid_strings: allow other errors to be specifiedDouglas Bagnall1-4/+43
Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz> Reviewed-by: Andrew Bartlett <abartlet@samba.org>
2023-04-28pytest:sid_strings: add a superclass, allowing for derivativesDouglas Bagnall1-2/+5
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>
2023-04-28pytest:sid_strings: use hashed instead of random unique numbersDouglas Bagnall1-5/+5
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>
2023-04-28pytest:sid_strings: same timestamp for all tests in the runDouglas Bagnall1-3/+3
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>
2022-08-25python:tests: Allocate OID range for testing to avoid collisionsJoseph Sutton1-1/+7
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
2022-03-17python:tests: Add tests for SDDL SID stringsJoseph Sutton1-0/+235
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>
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-06 21:22:49 +0000