LDAP federated user update fails with 400 Bad Request
See original GitHub issueDescribe the bug
Having a Keycloak configured with a LDAP federation I can initially import users and modify e.g. their groups just fine. I also can run the configuration again for some time to change e.g. user groups again. At some point, I get a 400 Bad Request when running the same configurations again (with or without changes).
Keycloak then fails with:
[org.keycloak.userprofile.validator.ReadOnlyAttributeUnchangedValidator] (default task-57) Attempt to edit denied attribute ‘(?i:^\QKERBEROS_PRINCIPAL\E$|^\QLDAP_ID\E$|^\QLDAP_ENTRY_DN\E$|^\QCREATED_TIMESTAMP\E$|^\QcreateTimestamp\E$|^\QmodifyTimestamp\E$)’ of user ‘user1’
Deleting the users from KeyCloak removes the error, but it appears again after some invocations of the config.
I cannot find a clear connection to e.g. the number of invocations or the time past after the initial user import. But my current assumption is, that the error occurs after a certain time past the initial user import.
EDIT: I can verify, that the error does not happen every time after its first occurrence. With a completely unchanged failing config I was able to rerun it without failure once after some hours. Next invocation failed again then though.
To Reproduce
- Create Keycloak with LDAP federation in READ_ONLY mode
- Use yaml configuration to import a federated user and assign a group to it
realm: test users: - username: user1 federationLink: internal-ldap groups: - group1 - Change the group assignment and expect it to succeed
realm: test users: - username: user1 federationLink: internal-ldap groups: - group2 - After some time running the configurations from above again fails with the mentioned error
- Delete
user1in Keycloak, repeat from step 2. and observe the configuration to succeed again for some time
Expected behavior To be able to repeat configurations for LDAP federated users without the try to modify immutable metadata (according to the Keycloak error message).
Environment (please complete the following information):
- Keycloak Version: 14.0.0 (Kubernetes Keycloak Community Operator)
- keycloak-config-cli Version: 4.1.0
- Java Version: 11.0.11
Issue Analytics
- State:
- Created 2 years ago
- Comments:7 (4 by maintainers)
Top Related StackOverflow Question
@jkroepke Thanks, will try it out. For my use cases it would be currently ok to have such a specific flag.
But I just wanted to confirm, that setting the
modifyTimestampmapper toread.always.from.ldap=falseseems to help with this issue (at least during the last 2 hours I could not reproduce the error). Not sure if that is undesirable for the most part to deviate from the defaulttruesetting.Might be helpful if that confirms to be true in the long run for others having to deal with custom attributes.
If you are using master or latest stable release, I would expect that. Since the user is created before the federationStorage is configured which is limited? supported. In the next release, the federationStorage is configured first, then the handling of user secondly.
I would expect this issue too, if plain curl is used to update the user including the attributes in the update request).
Anyway, to resolve this specific case, I introduce a flag
import.skip-attributes-for-federated-user#497 that forcefully set attributes=null before importing users to Keycloak. If set, user attributes are not longer manageable through keycloak-config-cli.