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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
In a typical user login query, the code tries to work out the PSO 2-3
times - once for the msDS-ResultantPSO attribute, and then again for the
msDS-User-Account-Control-Computed & msDS-UserPasswordExpiryTimeComputed
constructed attributes.
The PSO calculation is reasonably expensive, mostly due to the nested
groups calculation. If we've already constructed the msDS-ResultantPSO
attribute, then we can save ourselves extra work by just re-fetching the
result directly, rather than expanding the nested groups again from
scratch.
The previous patch improves efficiency when there are no PSOs in the
system. This should improve the case where there are PSOs that apply to
the users. (Unfortunately, it won't help where there are some PSOs in
the system, but no PSO applies to the user being queried).
Also updated sam.c so the msDS-ResultantPSO gets calculated first,
before the other constructed attributes.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
Autobuild-User(master): Garming Sam <garming@samba.org>
Autobuild-Date(master): Wed May 23 10:09:11 CEST 2018 on sn-devel-144
The new PSO code adds some additional overhead in extra lookups. To
avoid penalizing existing setups, we can short-circuit the PSO
processing and return early if there are no actual PSO objects in the
DB. The one-level search should be very quick, and it avoids the need to
do more complicated PSO processing (i.e. expanding the nested groups).
The longer-term plan is to rework the tokenGroups lookup so that it only
gets done once, and the result can then be reused by the resultant-PSO
code (rather than computing the nested-groups again). However, in the
short-term, a slight decrease in performance is the price for any users
that want to deploy PSOs.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
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>
Anonymous structs and 80 character line-lengths don't mix well. Allow
the struct to be referenced directly.
With the introduction of PSOs, the password-settings are now calculated
per-user rather than per-domain. I've tried to reflect this in the
struct name.
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 a user's password-hash is modified, we need the PSO settings for
that user, so that any lockout settings get applied correctly.
To do this, we query the msDS-ResultantPSO in the user search. Then, if
a PSO applies to the user, we add in a extra search to retrieve the
PSO's settings. Once the PSO search completes, we continue with the
modify operation.
In the event of error cases, I've tried to fallback to logging the
problem and continuing with the default domain settings. However,
unusual internal errors will still fail the operation.
We can pass the PSO result into dsdb_update_bad_pwd_count(), which means
the PSO's lockout-threshold and observation-window are now used. This is
enough to get the remaining lockout tests passing.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
To get the SAMR password_lockout test passing, we now just need to query
the msDS-ResultantPSO attribute for the user in the SAMR code. The
common code will then determine that a PSO applies to the user, and use
the PSO's lockout settings.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
The lockOutObservationWindow is used to calculate the badPwdCount. When
a PSO applies to a user, we want to use the PSO's lockout-observation
window rather the the default domain setting.
This is finally enough to get some of the PSO password_lockout tests
to 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>
msDS-User-Account-Control-Computed uses the effective-lockoutDuration to
determine if a user is locked out or not. If a PSO applies to the user,
then the effective-lockoutDuration is the PSO's msDS-LockoutDuration
setting. Otherwise it is the domain default lockoutDuration value.
Signed-off-by: Tim Beale <timbeale@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
If a PSO applies to a user, use its lockOutThreshold/Duration settings
instead of the domain setting. When we lookup a user, we now include the
msDS-ResultantPSO attribute. If the attribute is present for a user,
then we lookup the corresponding PSO object to get the lockOutThreshold/
Duration settings.
Note: This is not quite enough to make the PSO lockout tests pass, as
msDS-User-Account-Control-Computed is still constructed based on the
domain lockoutDuration setting rather than the PSO.
Updating the password_hash.c code properly will be done in a subsequent
commit.
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>
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue May 22 02:42:32 CEST 2018 on sn-devel-144
Selftest logs are full of calls to security_token_debug() with no context
and this is never a log level 0 event, so tidy it up.
The RODC would trigger this each time there is an attempted preload
of a user in the Denied RODC replication group.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
../source4/torture/basic/mangle_test.c: In function ‘gen_name’:
../source4/torture/basic/mangle_test.c:148:3: error: ‘strncpy’ output
truncated before terminating nul copying 5 bytes from a string of the
same length [-Werror=stringop-truncation]
strncpy(p, "ABCDE", 5);
^~~~~~~~~~~~~~~~~~~~~~
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13437
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Guenther Deschner <gd@samba.org>
../source4/torture/smb2/session.c: In function ‘test_session_reauth5’:
../source4/torture/smb2/session.c:645:36: error: ‘\file.dat’ directive output may be truncated writing 9 bytes into a region of size between 1 and 256 [-Werror=format-truncation=]
snprintf(fname, sizeof(fname), "%s\\file.dat", dname);
^~~~~~~~~~
../source4/torture/smb2/session.c:645:2: note: ‘snprintf’ output between 10 and 265 bytes into a destination of size 256
snprintf(fname, sizeof(fname), "%s\\file.dat", dname);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../source4/torture/smb2/session.c:696:38: error: ‘\file2.dat’ directive output may be truncated writing 10 bytes into a region of size between 1 and 256 [-Werror=format-truncation=]
snprintf(fname2, sizeof(fname2), "%s\\file2.dat", dname);
^~~~~~~~~~~
../source4/torture/smb2/session.c:696:2: note: ‘snprintf’ output between 11 and 266 bytes into a destination of size 256
snprintf(fname2, sizeof(fname2), "%s\\file2.dat", dname);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13437
Guenther
Signed-off-by: Guenther Deschner <gd@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Noel Power <noel.power@suse.com>
Autobuild-User(master): Noel Power <npower@samba.org>
Autobuild-Date(master): Thu May 17 14:28:19 CEST 2018 on sn-devel-144
Although we can pass unicode to py_net_change_password unfortunately in
Python2 unicode strings are encoded with the default encoding (e.g. ascii)
when extracting the unicode string to buffer.
In Python3 the default encoding for "s" format is utf8. Use the "es"
format instead of "s" so we can specify the encoding so behaviour is
correct in py2/py3.
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Found by Coverity.
Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: David Disseldorp <ddiss@samba.org>
Autobuild-User(master): Andreas Schneider <asn@cryptomilk.org>
Autobuild-Date(master): Thu May 17 04:03:21 CEST 2018 on sn-devel-144
Extract the common audit logging code into a library to allow it's
re-use in other logging modules.
Signed-off-by: Gary Lockyer <gary@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
This demonstrates the broken GENSEC_FEATURE_LDAP_STYLE
handling in our LDAP server.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=13427
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
chgtdcpass should add a new DC password and delete the old ones but the bug
exposed by this test causes the tool to remove only a single record from
the old entries, leaving the old passwords functional. Since the tool is
used by administrators who may have disclosed their domain join password and
want to invalidate it, this is a security concern.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13415
Signed-off-by: Aaron Haslett <aaronhaslett@catalyst.net.nz>
Reviewed-by: Andreas Schneider <asn@samba.org>
Autobuild-User(master): Andreas Schneider <asn@cryptomilk.org>
Autobuild-Date(master): Tue May 15 15:45:08 CEST 2018 on sn-devel-144
chgtdcpass should add a new DC password and delete the old ones but the bug
exposed by this test causes the tool to remove only a single record from
the old entries, leaving the old passwords functional. Since the tool is
used by administrators who may have disclosed their domain join password and
want to invalidate it, this is a security concern.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13415
Signed-off-by: Aaron Haslett <aaronhaslett@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Those wishing to build without gpgme support need simply to build --without-gpgme
This In general, we prefer that optional libraries be required by default
so that they are not accidentially missed, particularly in packages.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Gary Lockyer <gary@catalyst.net.nz>
This completes the regression fix of commit 7e091e5051.
There might be strings allocated on state, which are part of the
result.
The reason for the TALLOC_FREE(state) was to cleanup the possible
irpc_handle before leaving the function. Now we call
TALLOC_FREE(state->wb.irpc_handle) explicitly in
dcesrv_lsa_Lookup{Names,Sids}_base_done() instead.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13420
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): Sun May 13 10:27:28 CEST 2018 on sn-devel-144
Signed-off-by: Aaron Haslett <aaronhaslett@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Sat May 12 12:05:31 CEST 2018 on sn-devel-144
During the new samba-tool domain backup restore the NTDS GUID changes
as the server is taken over by the new DC record.
Signed-off-by: Aaron Haslett <aaronhaslett@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Garming Sam <garming@catalyst.net.nz>
There are two options which are undocumented.
Signed-off-by: Garming Sam <garming@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Sat May 12 04:57:29 CEST 2018 on sn-devel-144
