Bug 41516 - sambaPwdLastSet not updated after machine password rotation
sambaPwdLastSet not updated after machine password rotation
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: UMC - Computers
UCS 3.3
Other Linux
: P5 normal (vote)
: UCS 3.3-0-errata
Assigned To: Stefan Gohmann
Arvid Requate
:
Depends on: 41367
Blocks:
  Show dependency treegraph
 
Reported: 2016-06-09 20:08 CEST by Stefan Gohmann
Modified: 2016-09-29 20:55 CEST (History)
5 users (show)

See Also:
What kind of report is it?: Development Internal
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Gohmann univentionstaff 2016-06-09 20:08:30 CEST
Backport to UCS 3.3.

+++ This bug was initially created as a clone of Bug #41367 +++

Running a Samba/NT environment with Samba version 2:4.3.7-1.827.201604141315, we experienced some strange behaviours after some time.

Running a DC Slave as Server role: ROLE_DOMAIN_PDC and memberservers as Server role: ROLE_DOMAIN_MEMBER, when the memberserver has its password rotation every 21 days, it seems to do everything as intended:

run-parts: executing /usr/lib/univention-server/server_password_change.d/univention-samba postchange
machine password stored successfully in secrets.tdb
Setting stored password for "<memberserver dn>" in secrets.tdb
setting idmap secret for '*' from /etc/machine.secret
Secret stored
Stopping Samba daemons: nmbd smbd.
Starting Samba daemons: nmbd smbd.
Stopping the Winbind daemon: winbind.
Starting the Winbind daemon: winbind.

Looking at the LDAP attributes userPassword and sambaNTPassword, they changed, but sambaPwdLastSet is set not to the time the password was changed!

What now happes is that after the Samba password expiry time in sambaDomainName, attribute sambaMaxPwdAge, the memberservers cannot connect to the PDC again, getting the following possible error messages:

Nagios CRITICAL: wbinfo failed: wbcCheckTrustCredentials(<NT DOMAIN NAME>): error code was NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND (0xc0000233):failed to call wbcCheckTrustCredentials: WBC_ERR_AUTH_ERROR:Could not check secret:checking the trust secret for domain <NT DOMAIN NAME> via RPC calls failed

When logging in to a Samba share on the memberserver using smbclient, the following error message comes up: NT_STATUS_NO_LOGON_SERVERS

Looking at the log.smbd on the PDC, the following error message comes up:
[2016/05/26 15:40:08.687318,  0] ../source3/rpc_server/srv_pipe.c:1197(api_pipe_alter_context)
  Auth step returned an error (NT_STATUS_PASSWORD_EXPIRED)

Long story short: when the server password is changed, the Samba password "last set" value for servers providing Samba shares is not updated. As soon as "sambaPwdLastSet" from the memberserver) plus "sambaMaxPwdAge" are in the past, winbind refuses to work. Prior to the update to Samba 4.3 due to the badlock-update, everything worked fine.
Comment 1 Stefan Gohmann univentionstaff 2016-06-10 07:54:42 CEST
Fixed with r70056 and r70059

YAML r70060

Waiting for UCS 4.1-2-errata test results (Bug #41367)
Comment 2 Arvid Requate univentionstaff 2016-06-14 19:12:50 CEST
* Code review: Ok
* Update via /usr/lib/univention-server/server_password_change - Ok
* Initial join of Memberserver: Ok
* Advisory: Ok


I'm surprised about the versioning: The Debian-patchlevel has been incremented by 101, but IIRC the UCS 3.3 policy was to increment the minor version to 100. I guess it's ok, but then it would have been enough to keep UCS 3.2-8 and UCS 3.3 versions identical (and just build them in the right order). Additionally the package has been built with b33-scopem which results in
 
  9.0.76-143~ucs3.3.1397.201606100742

This doesn't make much sense to me, but anyway, it works.
Comment 3 Stefan Gohmann univentionstaff 2016-06-14 19:27:02 CEST
(In reply to Arvid Requate from comment #2)
> I'm surprised about the versioning: The Debian-patchlevel has been
> incremented by 101, but IIRC the UCS 3.3 policy was to increment the minor
> version to 100. I guess it's ok, but then it would have been enough to keep
> UCS 3.2-8 and UCS 3.3 versions identical (and just build them in the right
> order). Additionally the package has been built with b33-scopem which
> results in
>  
>   9.0.76-143~ucs3.3.1397.201606100742

Yeah, sorry I didn't update the wiki. We can't increase the second version number by 100 because we would override customer extension in an erratum. So, I decided to increase the Debian patchlevel by 101.
Comment 4 Janek Walkenhorst univentionstaff 2016-06-15 12:09:14 CEST
<http://errata.software-univention.de/ucs/3.3/3.html>