Hi
Here’s the problem.
We have connected a Windows AD as a source for Keycloak in ReadOnly mode.
Due to a migration from openLDAP to Windows AD, the password fields of all existing users in LDAP are now stored as SSHA hash in the userPassword field (like it was before in the openLDAP). I can also see this field when communicating directly via LDAP protocol (for example with the Apache Directory Studio).
But Windows itself manages the passwords separately. I don’t see this field in LDAP for the time being. Also if I try to authenticate via Keycloak - the Password in userPassword is ignored - instead keycloak accept only the password set via Windows AD.
This means that we now have to ask all our users to setup a new password when we activate the login via Keycloak.
Is there a way to not let Keycloak use the Windows AD password field for password verification? But instead use the userPassword LDAP field with the SSHA hash? In other words - any type of password mapper or a configuration change in keycloak to define which is the password field.
Assuming that you connected you AD via the LDAP mapper to Keycloak…
AFAIK this can only be achieved by implementing a customized version of the user storage SPI, most likely to “just” extend the built-in LDAP provider and to customize the password logic to your needs.
Thank you very much for the answer.
What is necessary for this? Is there any documentation? We have some development capacity - maybe that really makes sense for us?
Do I need to think of this as some kind of add-on?
Keycloak is based on the SPI architecture approach. You can basically implement nearly everything in Keycloak with an SPI as a customized extension. This way, the core keeps untouched (and secure) and you don’t need to compile/build your own KC distribution, but can just extend the defaults.