Uploaded image for project: 'Keycloak'
  1. Keycloak
  2. KEYCLOAK-12581

AD users' passwords cannot be administratively changed

    Details

    • Steps to Reproduce:
      Hide

      Set up a SAMBA AD DC using "samba-tool domain provision". Replace the default snakeoil certificate with the one from Let's Encrypt, to avoid trust troubles. Set up Keycloak by running the official docker container. Create an administrative user to be used by Keycloak. Create a dummy test user using samba-tool.

      In the master realm, set up Keycloak to use LDAP federation, pretend that SAMBA is writable Active Directory, connect via ldaps://, allow Keycloak to import users and sync registrations, use sAMAccountName as a username LDAP attribute. Sync all users. If you have set up group mapper, sync grups, too.

      Then go to Users, click the test user, enable, mark email as verified, remove the "update password" task, save. Go to the Credentials tab. Use the "Reset password" functionality - that is, type the same password twice, make it non-temporary, and actually reset the password.

      Expected result (and the actual result with 7.0.1): SAMBA logs the password change, the user is able to log in using the new password.

      Actual result with 8.0.1: Keycloak shows that the user now has a "password" type of credential that uses pbkdf2. SAMBA logs no attempts to change that user's password, the user is not able to log in.

      Show
      Set up a SAMBA AD DC using "samba-tool domain provision". Replace the default snakeoil certificate with the one from Let's Encrypt, to avoid trust troubles. Set up Keycloak by running the official docker container. Create an administrative user to be used by Keycloak. Create a dummy test user using samba-tool. In the master realm, set up Keycloak to use LDAP federation, pretend that SAMBA is writable Active Directory, connect via ldaps://, allow Keycloak to import users and sync registrations, use sAMAccountName as a username LDAP attribute. Sync all users. If you have set up group mapper, sync grups, too. Then go to Users, click the test user, enable, mark email as verified, remove the "update password" task, save. Go to the Credentials tab. Use the "Reset password" functionality - that is, type the same password twice, make it non-temporary, and actually reset the password. Expected result (and the actual result with 7.0.1): SAMBA logs the password change, the user is able to log in using the new password. Actual result with 8.0.1: Keycloak shows that the user now has a "password" type of credential that uses pbkdf2. SAMBA logs no attempts to change that user's password, the user is not able to log in.
    • Docs QE Status:
      NEW
    • QE Status:
      NEW

      Description

      This is a regression since version 7.0.1.

      With release 7.0.1, I was able to log in as Keycloak admin in the Master realm, and then change any user's password, including passwords for AD users. OK, I tested with SAMBA 4.9.x (whatever is included in Debian Buster), not the real AD, just in case if it matters. SAMBA, when running with log level = 5, logs the password change.

      In version 8.0.1, instead of forwarding the password update to SAMBA, Keycloak just creates a new credential in the database. There is nothing about unicodePwd update in SAMBA logs.

      It may be a related issue that the "user enabled" attribute does not stick when saved, and I cannot remove the "update password" task.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  Unassigned
                  Reporter:
                  patrakov-1 Alexander Patrakov
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  2 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: