Bug 56795

Summary: UMC (sometimes) rejects user login after Keycloak password change due to replication time
Product: UCS Reporter: Julia Bremer <bremer>
Component: KeycloakAssignee: UCS maintainers <ucs-maintainers>
Status: RESOLVED DUPLICATE QA Contact: UCS maintainers <ucs-maintainers>
Severity: normal    
Priority: P5    
Version: UCS 5.0   
Target Milestone: ---   
Hardware: Other   
OS: Linux   
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:

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).
Comment 1 Julia Bremer univentionstaff 2024-05-27 14:32:44 CEST 

*** This bug has been marked as a duplicate of bug 56395 ***