It seems that the hash of the actual password is not checked if the user has to reset his password during login. The password history is checked there, but it's possible to set the actual password again! If the user changes his password via the self-service, then it is not possible to use the actual password again. This leads to confusion and is an inconsistent behavior! Expected: the actual password is also checked during the "set new password" dialogue. Scenario 1: password reset during login * (School) admin changes password of (student) user "lehmann" to "password#123" and sets "user has to change password on next login" * user lehmann logs in and enters the password "password#123" * the user lehmann has to change his password and enters "password#123" again * the password is set successfully Scenario 2: password reset via self-service * init: user lehmann has the password "password#456" (hasn't been used before) * user lehmann logs in and enters the password "password#456" * user lehmann goes to "password reset self-service" * enters "password#456" * Self-Service aborts with: password has already been used The password history (if available) is checked successfully in both scenarios, whereas the comparison of the hash of the actual password (userPassword) clearly differs!
system role is master? is Samba 4 installed?
The self-service uses udm for the password reset. The UMC login uses kerberos (PAM). If samba4 is installed, the samba password policies are used. The password history length domain policy defaults to 0. So no history is checked. You can check this by using samba-tool domain passwordsettings show If you want to activate password history checking in samba, configure samba-tool domain passwordsettings set --history-length=3
This is documented here: https://docs.software-univention.de/manual/5.0/en/user-management/password-settings-windows-clients.html?highlight=password
(In reply to Florian Best from comment #1) > system role is master? > is Samba 4 installed? Yes, it's a primary WITHOUT samba installed.
Can you show me? I can't reproduce it. The self-service doesn't check the "current password" it only checks the pwhistory (while setting the password via udm). Heimdal (pam_krb5) does the same, it checks the pwhistory. Not the userPassword. Without samba, they behave the exact same in that regard. If the password to set is in the pwhistory, the password change is rejected, if not it is accepted. Are you sure that the pwhistory attribute was not changed between your attempts? In the Scenario 1, the school admin reset the users password, that password is not put into the passwordhistory. That's why the user can change it to that same value again. In Scenario 2, was the user created with password "password#456"? Then it would have become part of the passwordhistory. That means it can't be set to the same value again. Did you check the pwhistory attribute itself?
We had a look at it, the reason for the perceived behavioral differences was, that in the one case, the password was reset by the administrator in the school "student password" module, which sets overridePWHistory. Because of that, the new password could be set again. In the second case, the password was present in the pwhistory, because it was a fresh user. The password couldn't be set again then. Closing this bug as invalid