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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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>
There are 2 different PSO tests:
- make test TESTS=ldap.password_settings
- make test TESTS=samba_tool.passwordsettings
There's also another test that's completely unrelated to PSOs:
- make test TESTS=blackbox.password_settings
This patch renames ldap.password_settings --> ldap.passwordsettings.
This means 'make test TESTS=passwordsettings' will run both PSO tests,
but not the unrelated blackbox test.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Fri Sep 21 22:58:17 CEST 2018 on sn-devel-144
This is not related to PSOs at all, but there's a minor discrepancy
between Windows and Samba password-history-length behaviour that I
noticed during PSO testing.
When the pwdHistoryLength changes from zero to non-zero, Windows
includes the user's current password as invalid immediately, whereas
Samba only includes it as invalid *after* it next changes. It's a
fairly obscure corner-case, and we might not care enough about it to
fix it. However, I've added a test case to highlight the difference and
marked it as a known-fail for now.
I also added a general pwdHistoryLength test case to show that the
basics work (this didn't seem to be tested anywhere else).
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
When calculating the Password-Expiry-Time, we should use the PSO's
max-password-age setting, if one applies to the user.
This is code may be inefficient, as it may repeat the PSO-lookup work
several times (once for each constructed attribute that tries to use
it). For now, I've gone for the simplest code change, and efficiency can
be addressed in a subsequent patch (once we have a good test to measure
it).
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
Honour the settings in the PSO when changing the password, i.e.
msDS-PasswordComplexityEnabled, msDS-PasswordHistoryLength, etc.
The password_hash code populates dsdb_control_password_change_status's
domain_data with the password settings to use - these are currently
based on the settings for the domain.
Now, if the password_hash code has worked out that a PSO applies to the
user, we override the domain settings with the PSO's values.
This change means the password_settings tests now pass.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
Unhobble the PSO test cases so that they not only check the
msDS-ResultantPSO constructed attribute, but also that the corresponding
PSO's password-history, minimum password length, and complexity settings
are actually used.
The tests now fail once more, as actually using the PSO's settings isn't
implemented yet.
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 support for the msDS-ResultantPSO constructed attribute, which
indicates the PSO (if any) that should apply to a given user. First we
consider any PSOs that apply directly to a user. If none apply directly,
we consider PSOs that apply to any groups the user is a member of. (PSO
lookups are done by finding any 'msDS-PSOAppliesTo' links that apply to
the user or group SIDs we're interested in.
Note: the PSO should be selected based on the RevMembGetAccountGroups
membership, which doesn't include builtin groups. Looking at the spec,
it appears that perhaps our tokenGroups implementation should also
exclude builtin groups. However, in the short-term, I've added a new
ACCOUNT_GROUPS option to the enum, which is only used internally for
PSOs.
The PSO test cases (which are currently only checking the constructed
attribute) now pass, showing that the correct msDS-ResultantPSO value is
being returned, even if the corresponding password-policy settings are
not yet being applied.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
a.k.a Fine-Grained Password Policies
These tests currently all run and pass gainst Windows, but fail against
Samba. (Actually, the permissions test case passes against Samba,
presumably because it's enforced by the Schema permissions).
Two helper classes have been added:
- PasswordSettings: creates a PSO object and tracks its values.
- TestUser: creates a user and tracks its password history
This allows other existing tests (e.g. password_lockout, password_hash)
to easily be extended to also cover PSOs.
Most test cases use assert_PSO_applied(), which asserts:
- the correct msDS-ResultantPSO attribute is returned
- the PSO's min-password-length, complexity, and password-history
settings are correctly enforced (this has been temporarily been hobbled
until the basic constructed-attribute support is working).
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
