LDAP federated user update fails with 400 Bad Request

See original GitHub issue

Describe 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

  1. Create Keycloak with LDAP federation in READ_ONLY mode
  2. Use yaml configuration to import a federated user and assign a group to it
    realm: test
    users:
        - username: user1
          federationLink: internal-ldap
          groups:
             - group1
    
  3. Change the group assignment and expect it to succeed
     realm: test
     users:
        - username: user1
          federationLink: internal-ldap
          groups:
             - group2
    
  4. After some time running the configurations from above again fails with the mentioned error
  5. Delete user1 in 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:closed
  • Created 2 years ago
  • Comments:7 (4 by maintainers)

github_iconTop GitHub Comments

1reaction
mpreucommented, Aug 6, 2021

@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 modifyTimestamp mapper to read.always.from.ldap=false seems 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 default true setting.

Might be helpful if that confirms to be true in the long run for others having to deal with custom attributes.

0reactions
jkroepkecommented, Aug 6, 2021

will fail at some point as well.

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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

ISM KM - HTTP 400 Bad request for URL with Active Directory ...
But pageContent parameter showing HTTP error 400 Bad request. User validation is performed by AD users and server Active Directory Federation Service.
Read more >
"400; Bad Request -- 0: Access denied" (4290696)
In this example a certificate has been issued with a CRL Distribution Point (CDP) extension pointing to an LDAP end point.
Read more >
HTTP 400 - Bad Request (Request Header too long)
A 400 error is seen by the end user when trying to access a SecureAuth realm that has Windows Authentication enabled. Not all...
Read more >
400: Bad request - The request or response is invalid - IBM
Problem. This technote discusses an issue that occurs when you try to login after you have successfully configured LDAP on ICP 3.1.2, and...
Read more >
Bug: AD-LDAP Connector 400 bad request - Auth0 Community
The Kerberos token that was being generated for my user was too large and causing the headers to exceed the 8kb limit that...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found