Bug 56795 - UMC (sometimes) rejects user login after Keycloak password change due to replication time
UMC (sometimes) rejects user login after Keycloak password change due to repl...
Status: NEW
Product: UCS
Classification: Unclassified
Component: Keycloak
UCS 5.0
Other Linux
: P5 normal (vote)
: ---
Assigned To: UCS maintainers
UCS maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2023-11-03 09:27 CET by Julia Bremer
Modified: 2023-11-03 09:27 CET (History)
0 users

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Julia Bremer univentionstaff 2023-11-03 09:27:28 CET
If the password of a user is expired, the user is prompted to change their password during the Keycloak login.
The password is changed using a UMC call in a Keycloak extension. 
The password change is executed using pam-kerberos. 

If Samba4 is installed, the Kerberos service of Samba is used and the password is changed in the Samba database.
If the synchonization from Samba4 to openLDAP using the s4-connector is not extremly fast, you are rejected by the UMC afterwards because the password is still expired in the openLDAP database. 
You then get an error message and are kicked out. 
If you click on "login" directly after, you are logged in directly.

This might not only affect Samba4 domains, but also Keycloak servers which are configured against a DC backup instead of a DC master. 

This is really ugly and could upset quite a few users.
I don't see an easy/elegant solution though, besides making some kind of timeout configurable somewhere. (In the UMC? In Keycloak? I don't know).