Univention Bugzilla – Bug 46067
UDM flag pwdChangeNextLogin toggles on each modification but should not
Last modified: 2020-06-22 18:46:26 CEST
If pwdChangeNextLogin is set to "1" via UDM CLI but the value was already "1", the flag is reset mistakenly. This seems to be an old bug (see also Bug 8394 and 7511 for more details). root@master98:~# udm users/user modify --dn uid=anton9,cn=schueler,cn=users,ou=gsmitte,dc=nstx,dc=local --set password=univention345 --set pwdChangeNextLogin=1 Object modified: uid=anton9,cn=schueler,cn=users,ou=gsmitte,dc=nstx,dc=local root@master98:~# udm users/user list --filter uid=anton9 | egrep -i 'dn:|pwd' DN: uid=anton9,cn=schueler,cn=users,ou=gsmitte,dc=nstx,dc=local pwdChangeNextLogin: 1 root@master98:~# udm users/user modify --dn uid=anton9,cn=schueler,cn=users,ou=gsmitte,dc=nstx,dc=local --set password=univention456 --set pwdChangeNextLogin=1 Object modified: uid=anton9,cn=schueler,cn=users,ou=gsmitte,dc=nstx,dc=local root@master98:~# udm users/user list --filter uid=anton9 | egrep -i 'dn:|pwd' DN: uid=anton9,cn=schueler,cn=users,ou=gsmitte,dc=nstx,dc=local pwdChangeNextLogin: None root@master98:~# udm users/user modify --dn uid=anton9,cn=schueler,cn=users,ou=gsmitte,dc=nstx,dc=local --set password=univention567 --set pwdChangeNextLogin=1 Object modified: uid=anton9,cn=schueler,cn=users,ou=gsmitte,dc=nstx,dc=local root@master98:~# udm users/user list --filter uid=anton9 | egrep -i 'dn:|pwd' DN: uid=anton9,cn=schueler,cn=users,ou=gsmitte,dc=nstx,dc=local pwdChangeNextLogin: 1 root@master98:~# udm users/user modify --dn uid=anton9,cn=schueler,cn=users,ou=gsmitte,dc=nstx,dc=local --set password=univention678 --set pwdChangeNextLogin=1 Object modified: uid=anton9,cn=schueler,cn=users,ou=gsmitte,dc=nstx,dc=local root@master98:~# udm users/user list --filter uid=anton9 | egrep -i 'dn:|pwd' DN: uid=anton9,cn=schueler,cn=users,ou=gsmitte,dc=nstx,dc=local pwdChangeNextLogin: None root@master98:~# udm users/user modify --dn uid=anton9,cn=schueler,cn=users,ou=gsmitte,dc=nstx,dc=local --set password=univention789 --set pwdChangeNextLogin=1 Object modified: uid=anton9,cn=schueler,cn=users,ou=gsmitte,dc=nstx,dc=local root@master98:~# udm users/user list --filter uid=anton9 | egrep -i 'dn:|pwd' DN: uid=anton9,cn=schueler,cn=users,ou=gsmitte,dc=nstx,dc=local pwdChangeNextLogin: 1 root@master98:~#
From the perspective of the current logic: the password should be changed on next login, so the next passwort change will reset the value of pwdChangeNextLogin. This happens in that call. But as the newly set password should also expire on next login this is wrong.
Patch (based on fbest/45842-simplify-user-options): diff --git a/management/univention-directory-manager-modules/modules/univention/admin/handlers/users/user.py b/management/univention-directory-manager-modules/modules/univention/admin/handlers/users/user.py index a4d00ab..e965002 100644 --- a/management/univention-directory-manager-modules/modules/univention/admin/handlers/users/user.py +++ b/management/univention-directory-manager-modules/modules/univention/admin/handlers/users/user.py @@ -2027,7 +2027,7 @@ def _modlist_password_change(self, ml): » » » self._check_password_complexity(pwhistoryPolicy) » » » ml = self._modlist_samba_password(ml, pwhistoryPolicy) -» » pwd_change_next_login = self.hasChanged('pwdChangeNextLogin') and self['pwdChangeNextLogin'] == '1' +» » pwd_change_next_login = self['pwdChangeNextLogin'] == '1' » » unset_pwd_change_next_login = self.hasChanged('pwdChangeNextLogin') and self['pwdChangeNextLogin'] == '0' » » if pwd_change_next_login:
*** Bug 8394 has been marked as a duplicate of this bug. ***
*** Bug 7511 has been marked as a duplicate of this bug. ***
Patch tested, applied and merged. Package rebuilt and changelog added.
Tests: OK root@master431:~# udm users/user create --set username=test1 --set lastname=Test1 --set password=univention --set pwdChangeNextLogin=1 Object created: uid=test1,dc=deadlock43,dc=intranet root@master431:~# udm users/user list --filter uid=test1 | egrep -i 'dn:|pwd' DN: uid=test1,dc=deadlock43,dc=intranet pwdChangeNextLogin: 1 root@master431:~# udm users/user modify --dn uid=test1,dc=deadlock43,dc=intranet --set password=univention123 --set pwdChangeNextLogin=1 Object modified: uid=test1,dc=deadlock43,dc=intranet root@master431:~# udm users/user list --filter uid=test1 | egrep -i 'dn:|pwd' DN: uid=test1,dc=deadlock43,dc=intranet pwdChangeNextLogin: 1 root@master431:~# udm users/user modify --dn uid=test1,dc=deadlock43,dc=intranet --set password=univention456 --set pwdChangeNextLogin=1 Object modified: uid=test1,dc=deadlock43,dc=intranet root@master431:~# udm users/user list --filter uid=test1 | egrep -i 'dn:|pwd' DN: uid=test1,dc=deadlock43,dc=intranet pwdChangeNextLogin: 1 root@master431:~# udm users/user modify --dn uid=test1,dc=deadlock43,dc=intranet --set password=univention789 --set pwdChangeNextLogin=0 Object modified: uid=test1,dc=deadlock43,dc=intranet root@master431:~# udm users/user list --filter uid=test1 | egrep -i 'dn:|pwd' DN: uid=test1,dc=deadlock43,dc=intranet pwdChangeNextLogin: None root@master431:~# Changelog: OK Code review: OK
This patch from Comment 2 caused a regression in 60_umc/104_expired_password.py (see Bug 46126 Comment 16). I'll look into it how we can fix that.
After looking into this, I think this cannot be done with a quick oneliner fix. There are two aspects to this: 1) In the current users/user module I don't see a way to distinguish a (object['pwdChangeNextLogin'] == 1) read from the LDAP backend (via _unmap_pwd_change_next_login) from a (object['pwdChangeNextLogin'] == 1) explicitly set after the object.open() by the user (either via admincli or via UMC). We would need a way to remember that a value has actually been sent by the user, regardless of it's previous state found in the backend. 2) How would does this map to the GUI? There is a checkbox which needs to display the state of the backend data. If that is active and the admin changes the user password, how would s/he communicate the wish to *keep* pwdChangeNextLogin set? I'll revert the current patch from Comment 2, because it causes the regression that pwdChangeNextLogin stays active even when the user changes the password (e.g. via pam_krb5 and the umc_auth). That's the more frequent use case and it needs to work.
(In reply to Arvid Requate from comment #8) > After looking into this, I think this cannot be done with a quick oneliner > fix. There are two aspects to this: > > 1) In the current users/user module I don't see a way to distinguish a > (object['pwdChangeNextLogin'] == 1) read from the LDAP backend (via > _unmap_pwd_change_next_login) from a (object['pwdChangeNextLogin'] == 1) > explicitly set after the object.open() by the user (either via admincli or > via UMC). We would need a way to remember that a value has actually been > sent by the user, regardless of it's previous state found in the backend. Yes, we don't really have this functionality in UDM. There is __setitem__() which could be overwritten: test if self._open and key === 'pwdChangeNextLogin' > 2) How would does this map to the GUI? There is a checkbox which needs to > display the state of the backend data. If that is active and the admin > changes the user password, how would s/he communicate the wish to *keep* > pwdChangeNextLogin set? I think the UDM-CLI API is more important here than the GUI, as this is currently more broken. Maybe some javascript logic could help which unsets 'pwdChangeNextLogin' in the GUI if one changes the password. Then one could tick the checkbox after changing the password if it's whished to keep the state.
Created attachment 9402 [details] fix_set_pwdChangeNextLogin_again_during_password_change.patch I've created a test case 60_umc/13_set_pwdChangeNextLogin_again_during_password_change currently marked as skipped. The attached patch is along the lines of Comment 9. Seemed promising in a first quick test.