Automatic password_change of machine.secret fails on primary node

Since a year ago we have massive problems with the automatic change of machine.secret on primary node. This did not change with upgrade to version 5.0.3 besides the better logging.

We followed Q&A: How can I change the machine password from my ucs master? but that did not help.

/etc/cron.d/univention-server-master starts /usr/lib/univention-server/server_password_change.

This creates temporary files for the old password (which is linked to /etc/machine.secret) and the new password. It then generates a new password with genpw -1 -scn 20, chops of the newline and puts it in the temporary file for the new password. The script then sets this new password via function change_password. This gives no error, actually, we see in the log “/var/log/univention/server_password_change.log”:

[2023-03-16 17:06:28.808968675] Performing LDAP modification, set new password ..
[2023-03-16 17:06:28.809294]  DEBUG at /usr/lib/univention-server/server_password_change:104:change_password: /usr/sbin/univention-directory-manager "computers/$server_role" modify --binddn "
$ldap_hostdn" --bindpwdfile "$1" --dn "$ldap_hostdn" --set password="$(<"$2")" 1>&3 2>&3
Object modified: cn=pdc,cn=dc,cn=computers,dc=intern,dc=izt,dc=de
[2023-03-16 17:06:29.055393]  DEBUG at /usr/lib/univention-server/server_password_change:109:change_password: echowithtimestamp ".. done" 1>&3
[2023-03-16 17:06:29.055701]  DEBUG at /usr/share/univention-lib/base.sh:192:echowithtimestamp: echowithtimestamp ".. done" 1>&3
[2023-03-16 17:06:29.055871]  DEBUG at /usr/share/univention-lib/base.sh:193:echowithtimestamp: echo "[$(date '+%F %T.%N')] $@"
[2023-03-16 17:06:29.056809]  DEBUG at /usr/share/univention-lib/base.sh:193:echowithtimestamp: date '+%F %T.%N'
[2023-03-16 17:06:29.057843982] .. done

But then another function ldap_try tries 60 times to connect to ldap with the new password, this does not succeed and therefore the script tries to roll back all changes. Actually this does not work either and the ldap connection is in a dysfunctional state, gives “invalid credentials (49)”.

Manually running

udm computers/domaincontroller_master modify --dn “$(ucr get ldap/hostdn)” --set password="$(cat /etc/machine.secret)"

fixes everything as shown with successful command:

univention-ldapsearch -D cn=pdc,cn=dc,cn=computers,dc=intern,dc=izt,dc=de -w “$(cat /etc/machine.secret)” -s base

We have no idea why the cron script fails.

Could someone provide us with ideas how to debug/fix this?

Seems to be the same issue:

Mastodon