LDAP source: internal password is written after password change (without "update internal password on login")

[sumpfralle]

Describe the bug With the new option "update internal password on login" (password_login_update_internal_password) disabled, I expected, that passwords are not written to the database anymore. But the password is still written to the internal database, if a user changes his password via authentik.

To Reproduce Steps to reproduce the behavior:

1. configure an LDAP source
2. disable "update internal password on login" for this source (the default for new sources)
3. login to authentik with an LDAP account username
4. verify, that the content of the password field in the authentik_core_user table for this user is still empty
5. change the password of the user in authentik's password change dialog (new password: pw1)
6. the password field of the authentik_core_user table is non-empty (probably containing the hash of pw1)
7. change the password directly in the LDAP directory (not via authentik) to pw2
8. try to login into authentik with pw1: works (probably based on the password field stored in authentik's database)
9. try to login into authentik with pw2: works (probably based on the password stored in LDAP)

Expected behavior I expected, that the new setting "update internal password on login" is supposed to fix issue #6122 (it was closed by #8377). In this case, the password field should never be written.

Thus, the following details seem to be undesirable from my point of view:

• The password field in the authentik_core_user table should stay empty under all circumstances.
• The old password (pw1) should not be usable anymore after a password change in LDAP.

Version and Deployment (please complete the following information):

• authentik version: 2024.4.0
• Deployment: docker-compose

[rissson]

Well, that's really up to the admin to configure. If you don't want your user to be able to change their password (because they should use the LDAP one), then they should be denied to run a password change flow (by default default-password-change).

[sumpfralle]

Just for the clarification of the use case:

• passwords are changed in authentik
• password changes made via authentik are synchronized by authentik to our LDAP server

This works beautifully and is in line with the intended use-case of the LDAP feature in authentik.

The only problem is, that authentik is storing a password in its own internal database, even though the configuration setting "update internal password on login" is disabled. This was probably just an oversight and should (IMO) obviously be fixed.

[kukoarmas]

I've been unable to replicate the problem.

• I already had an LDAP source with hashed password stored in authentik database
• Updated authentik and disabled the "update internal password on login" feature in the ldap source
• Emptied the locally stored hash from the authentik database
• Logged in with to authentik
• Check database and the password field remains empty

So it seems the option is working as expected.

Maybe the problem is that the previously cached password are still used, so a workaround would be to empty them

[sumpfralle]

I've been unable to replicate the problem.

Thank you for trying to reproduce the problem!

Please take a look at the steps (5) and (6) of my procedure above: the problem is the password change via authentik. The changed password should just be synced to the LDAP server (this always worked), but it should not be stored locally in authentik's database.

[kukoarmas]

Ok, @sumpfralle is right If the goal of the "update internal password on login" is not having the user's password hash in the local database, it's not enough.

I've replicated two situations that stores the user's password hash in the local database, even with the option "update internal password on login" NOT selected:

1. When a user is initially synchronized from the LDAP source because it didn't already exist in the local database. When this happens, the password field contains a password hash. If the user already existed with an empty password, the password field is not updated
2. When a user changes it's password in authentik (has @sumpfralle mentioned). When this happens, a different kind of hash is stored (pbkdf2_sha256) in the database

So, if the goal was to not have a password hash in the authetik database, these two scenarios should be considered to not store the hash locally

[authentik-automation[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[BeryJu]

With the User password writeback option enabled, a password will only be written to LDAP when it is written to a user in authentik. I'm not sure what the best option would be to make these two steps separate without having to make a lot of assumptions in the code.

[sumpfralle]

The two involved settings of the LDAP source seem to be:

• Update internal password on login: When the user logs in to authentik using the LDAP password backend, the password is stored as a hashed value in authentik. Toggle off (default setting) if you do not want to store the hashed passwords in authentik.
• User password writeback: Enable this option if you want to write password changes that are made in authentik back to LDAP.

I have the feeling, that the name of the first setting ("Update internal password on login") is a source of confusion:

• the name indicates, that the settings control only password storage during "login"
  • this matches the current implementation (i.e. passwords are still stored during a password change)
• but the description states that this setting disables the storage of hashed passwords in the authentik database in general (login / password change / anything else)
• probably something like "cache passwords in authentik database" would be a better name for this setting (matching user expectations)

The seccond setting ("User password writeback") seems to be quite clear:

• password changes are submitted to the LDAP directory
• but the phrase "changes that are made in authentik" may still be a bit unclear here:
  • I think, users would understand this as "password changes submitted via the authentik web interface"
  • but the code seems to interpret this as "password changes, which are stored in the authentik database"

I'm not sure what the best option would be to make these two steps separate without having to make a lot of assumptions in the code.

I guess (without having looked at the details), that an improved wording of the settings would remove the need for these unsuitable assumptions.

[BeryJu]

some updated wording that I think makes it quite a bit clearer what the options mean/do

[sumpfralle]

IMO this combination of options is not suitable for the goals of authentik.

As @kukoarmas wrote above (similar to my previous words):

So, if the goal was to not have a password hash in the authetik database, these two scenarios should be considered to not store the hash locally

Thus, I would recommend the following two options:

1) Cache the users' passwords in authentik

Whenever a user logs in via authentik or changes the password via authentik, the password hash is cached in authentik's database.

2) Update LDAP on password changes

Enable this option to write password changes submitted via authentik back to LDAP.

I think, the above would be the description of a reasonable implementation.

At the moment, I still have to delete all password hashs in authentik's database periodically (a cron job), since these cached values turn stale after external password changes. At the moment there is no configurable way to solve this problem of cache invalidation in authentik.