when I modifed password，
WARN [org.keycloak.events] (default task-44) type=UPDATE_PASSWORD_ERROR, realmId=master, clientId=security-admin-console, userId=ce4b5650-90b3-4946-be86-67ee4b17bfc9, ipAddress=XX.XX.XX.XX, error=password_rejected, reason=‘Could not modify attribute for DN [CN=XXX,OU=XXX,OU=People,OU=Users,OU=XXX,DC=XXX,DC=com]’, auth_method=openid-connect, custom_required_action=UPDATE_PASSWORD, response_type=code
I have the same problem. Did you solve this in the meantime?
My Keycloak has a working LDAPS connection to my DC but still I can’t change passwords:
Could not modify attribute for DN [CN=TEST TESTER,OU=Benutzer,DC=domain,DC=local]
Finally found my fault.
The Bind DN user used for changing passwords didn’t have enough rights for changing the passwords…
Hey can you provide more details as what permission this the Bind DN user needed?
please have a look here: https://petri.com/delegate-permission-reset-ad-user-account-passwords
This is for Active Directory, but any other LDAP should be similar.
You have to grant special rights to the user.
I’m trying to reset my password with keycloak’s edit mode set to writable and receiving an error that says “Could not modify attribute for DN,” so I tried the method you provided, but it didn’t work for me.
Please make a suggestion for a workaround.
Did you check the permissions of the ad user used for changing the passwords? It works, if you use the instrutions from https://petri.com/delegate-permission-reset-ad-user-account-passwords
Thanks for your quick response !!!
I followed the directions, but it didn’t work in my case. Please validate, I am attaching a screenshot of permission to change passwords.
did you use the assistant to grant the permissions as stated in linked website?
On my system there are some more permissions enabled for the user, e.g. “Read all properties”.
And I used an extra service user, not the normal Admin account.
Yes, I followed the steps in the link to grant the permission; the only thing that was missing was enabling the permission “Read all properties” for the user, which I enabled, but it still didn’t work.
In my case, I used a standard admin account, as it’s a bind user for my keycloak server.
Please suggest a solution to the above error if at all possible.
I don’t really have a solution for you!
Try with a different user (as you’re currently trying with an admin user) and give him rights as suggested on the linked website.
If that still doesn’t work I don’t have any other advice…
Hi! Grant this permissions under the users OU for Keycloak’s service account which is applies to Descendant User Objects:
- Reset Password
- Write public information
- Write Logon Name (pre-Windows 2000)
- Write pwdLastSet
- Write userAccountControl
It is recommended grant access to the security group which is contains service account.
So far I’ve:
- created an OU in AD for test users with some users
- created a service AD account for using in Keycloak
- created an AD security group with 5 mentioned permissions on users of test OU
- executed steps as per permission delegation guide
- added service account to this group and to dom adm
- created user federation in Keycloak and synced AD users
Still having the same issue as TS did, “error=password_rejected, reason=‘Could not modify attribute for DN”.
Same time I successfully manage other attributes of test users with Keycloak and successfully change test OU users passwords with ADUC running from service account for Keycloak.
Is there any log to gain insight from on this situation, or maybe some advise on permissions and settings?
@bagamax I don’t know if you still need help but I struggled the same as you when trying so make PW change work. In my case (using keycloak 20.0.2) the issue was that using LDAP (389) unencrypted did not work. So we switched over to LDAPS (636) and it works like a charm.
I did not deep dive the code for LDAP integration but when enabling debug log we saw something along the lines:
[LDAP: error code 53 - 0000001F: SvcErr: DSID-031A126C, problem 5003 (WILL_NOT_PERFORM)
When researching this issue, every article came to the conclusion it can only be 2 things:
- not using LDAPS
- password policy on domain controller not met
Since I met our password policy, I tried the LDAPS approach and it works.