Expired password change via ucs-sso is not working

UCS - Univention Corporate Server
,
1

Hi, we are using UCS 5.0.7. Our setup is:
we have master controller on the office hardware, and backup controller in AWS, and VPN line in between.

We have also two UCS servers that are purposely deployed as UCS SSO servers, i.e. ucs-sso.example.com

only these two ucs-sso servers available on public internet. For this reason, ucs-sso servers also have minimal setup: they are setup as Backup Directory Node with these apps: privacyIDEA SAML

for security reasons I did not install AD compatible domain controller on these machines,
because they are exposed to internet.

The problem is:

  • user’s password expires, and
  • user tries to login via ucs-sso, ucs-sso asks the user to change a password.
  • User changes password, UCS says that password is changed
  • User tries to login, new password is not working

password change fails.

Me and my team tried everything to fix it but but could not figure out the problem.

Any advice please?

2

I have done more debugging and here are more details.

If password expires on its own, from the password expiry policy, then it is not possible to change the password via SSO.

However, if I set in UCS “User must change password on next logon” then password change works without any problem.

Does this help understand the possible issue better?

Current UCS update level: version is 5.0-8 errata1073.

3

Hello,

we are facing exactly the same problem.

  • Environment:
    • UCS version 5.2-1 with errata level 38 .
    • Using ucs-sso as the login endpoint. When a password expires, the user is redirected to the password change form. The form reports “Password successfully changed”, but in reality the password is not updated — the new password does not work.

  • Behavior details:
    • This happens when the password expires naturally (due to policy).
    • There are no clear error messages in the logs when attempting the change.
    • If the flag “User must change password on next logon” is set, then the password change works correctly and the new password is immediately usable.

  • Our impression:
    • The password change flow triggered via SSO seems to succeed on the frontend, but the update is not synchronized to the backend (LDAP/Kerberos).
    • This might be related to differences in the SSO password change logic compared to UMC or CLI tools.

It would be great to know if you already found the root cause of this issue, or if there is any known workaround (patch, configuration change, etc.).

We are happy to provide logs and more configuration details if needed.