Univention Bugzilla – Bug 53205
samba server password change must not write password to samba if new password is not replicated to OpenLDAP
Last modified: 2022-05-04 16:58:46 CEST
If the replication of the new password to the local host fails samba will not rollback, as there is no nochange option in /usr/lib/univention-server/server_password_change.d/univention-samba4 that could do this. Only if the local samba-tool password change will fail, the script would do rollback.
One possibility to make the password change more robust could be to check the ldap replication to the local host before the samba change takes place. a roll back of the openldap staff is technical easier to rollback as a samba rollback would be.
I will provide a few more details (also to come closer to Arvids How to create a good bug) ;) My suggestion in comment 2 was to move the samba localchange call in /usr/lib/univention-server/server_password_change (line 195) below the check of the replication of the new password to the local ldap (line 202). The rollback of a samba passwordchange is more tricky as the open ldap staff. I will give some real examples when this happens in customer environments: UCS@school slave will change the password and school-import starts during this time, the notifier will be stopped; within the replication to other hosts. If this will happen before the samba localchange and the initial password change check with the master (after changing the password via udm) the change will fail but there is no way back for the changed samba password. The replication breaks in the same way without school-import. Ppolicy Lockout strikes during a server password change (f.e. because dhcpd, nscd tries to ask ldap with the old password (see bug 53062 https://forge.univention.org/bugzilla/show_bug.cgi?id=53062) a rollback (nochange) will be performed but samba stays on the "new" one. This will happen with samba4 and also with samba passwordchange hookscripts. A samba fileserver on a member will become unavailable. All these examples I have seen in customer environments, but it was only last Friday that I realized the reason: No rollback of a already done samba password change.
Another alternative could be to hard set the new PW in the local ldap instead of rollback as rollback of samba is actual not possible and as Arvid mentioned not easy to implement.
I tried to make the subject precise: my understanding is, that by ensuring that the password change in OpenLDAP took place and is replicated before doing any samba specific action the most (or even all?) identified issues could be fixed.
There must be a reason for the actual order. Maybe Arvid or Julia remember? Fact is that with the actual order we have a problem when we proceed the password change in samba and after that we check if the password is replicated local; if not we rollback what will cause different password in samba an openLDAP as there is no rollback mechanism for samba. So from my point of view we can not do a rollback after changed the password in samba or we need a mechanism to rollback samba also.
I see two options: a) simply implement a rollback in univention-samba4 and hope that it's fine. This would not be a real "rollback" but rather a second password change back to the previous password. I.e. msds-KeyVersionNumber would be +2 after the rollback, but I guess that's ok. b) Put Samba to the "end" of the change queue, so that it only gets run if all previous components have confirmed that their change was fine. Maybe we could do both to reduce risk? If not then I would opt for a) and ignore my fears for the time being.
We went for opt b in comment 7 as the option a cannot be implemented. Package: univention-server Version: 15.0.4-8A~5.0.0.202204271356 Branch: ucs_5.0-0 Scope: errata5.0-1 univention-server.yaml c416651bcef9 | Bug #53205: update yaml d4081060a582 | Bug #53205: change calls order to only change samba password if everything works before univention-server (15.0.4-8) d4081060a582 | Bug #53205: change calls order to only change samba password if everything works before
Verified: * Code review * Functional test (i.e. change with stopped listener) * Advisory 4a48e730e4 | Advisory wording
<https://errata.software-univention.de/#/?erratum=5.0x300>