starred/modoboa-modoboa

Fork 0

mirror of https://github.com/modoboa/modoboa.git synced 2026-04-26 01:16:01 +03:00

[GH-ISSUE #2372] LDAP: Error in creating/updating userPassword #1583

New issue

Closed

opened 2026-02-27 11:17:56 +03:00 by kerem · 5 comments

kerem commented

2026-02-27 11:17:56 +03:00

Owner

Originally created by @alexcustos on GitHub (Oct 8, 2021).
Original GitHub issue: https://github.com/modoboa/modoboa/issues/2372

Impacted versions

OS Type: Ubuntu
OS Version: 20.04
Database Type: PostgreSQL
Database version: 12
Modoboa: 1.17.0
installer used: Yes
Webserver: Nginx

Steps to reproduce

# https://github.com/modoboa/modoboa/blob/master/modoboa/ldapsync/lib.py
if user.password:
        password = get_user_password(user, not user.is_active)
        ldif.append((ldap.MOD_REPLACE, "userPassword", password))

Current behavior

This is not how the password is supposed to be created/updated in LDAP. This code extracts the SHA512-CRYPT string and sends it to LDAP. I debugged it for a while, and force_bytes("plain_text_password") instead of the password variable does the job.

Expected behavior

I expect a proper password to be sent to LDAP to allow other clients to use it as well.

Originally created by @alexcustos on GitHub (Oct 8, 2021). Original GitHub issue: https://github.com/modoboa/modoboa/issues/2372 # Impacted versions * OS Type: Ubuntu * OS Version: 20.04 * Database Type: PostgreSQL * Database version: 12 * Modoboa: 1.17.0 * installer used: Yes * Webserver: Nginx # Steps to reproduce ``` # https://github.com/modoboa/modoboa/blob/master/modoboa/ldapsync/lib.py if user.password: password = get_user_password(user, not user.is_active) ldif.append((ldap.MOD_REPLACE, "userPassword", password)) ``` # Current behavior This is not how the password is supposed to be created/updated in LDAP. This code extracts the SHA512-CRYPT string and sends it to LDAP. I debugged it for a while, and `force_bytes("plain_text_password")` instead of the `password` variable does the job. # Expected behavior I expect a proper password to be sent to LDAP to allow other clients to use it as well.

kerem

2026-02-27 11:17:56 +03:00

closed this issue
added the
stale
label

kerem commented

2026-02-27 11:17:56 +03:00

Author

Owner

@tonioo commented on GitHub (Oct 14, 2021):

Plain text password is not available in the database and OpenLDAP (at least) is supposed to understand the way password are stored in modoboa because we use the same format...

@tonioo commented on GitHub (Oct 14, 2021): Plain text password is not available in the database and OpenLDAP (at least) is supposed to understand the way password are stored in modoboa because we use the same format...

kerem commented

2026-02-27 11:17:56 +03:00

Author

Owner

@alexcustos commented on GitHub (Oct 14, 2021):

Plain text password is not available in the database

Not far from the LDAP sync handler, there's a raw_value variable (core/models.py). It looks like a raw password that can be passed down to the handler. I guess it's how it's supposed to work. Otherwise, LDAP synchronization doesn't make any sense. Modoboa can authenticate against Plain and SSHA hashed passwords in LDAP but saves back gibberish.

@alexcustos commented on GitHub (Oct 14, 2021): > Plain text password is not available in the database Not far from the LDAP sync handler, there's a `raw_value` variable (`core/models.py`). It looks like a raw password that can be passed down to the handler. I guess it's how it's supposed to work. Otherwise, LDAP synchronization doesn't make any sense. Modoboa can authenticate against Plain and SSHA hashed passwords in LDAP but saves back gibberish.

kerem commented

2026-02-27 11:17:56 +03:00

Author

Owner

@tonioo commented on GitHub (Oct 19, 2021):

The raw value you're talking about is only available when you set a new password. When do you any other kind of modification, then we don't have it. Could it be possible that your LDAP tries to hash the password sent by modoboa once again?

@tonioo commented on GitHub (Oct 19, 2021): The raw value you're talking about is only available when you set a new password. When do you any other kind of modification, then we don't have it. Could it be possible that your LDAP tries to hash the password sent by modoboa once again?

kerem commented

2026-02-27 11:17:56 +03:00

Author

Owner

@alexcustos commented on GitHub (Oct 19, 2021):

The raw value you're talking about is only available when you set a new password.

But what needs to update passwords otherwise? The use case is simple. I want Modoboa to maintain LDAP users that I can use to auth to Nextcloud, for example. In other words, when I create a new user or update its password, I expect Modoboa to sync the provided passwords with LDAP.

Could it be possible that your LDAP tries to hash the password sent by modoboa once again?

Sure, LDAP hashes passwords with SSHA or writes them as Plain text, depending on the settings, but that's not the problem. Why would anyone want to teach external services to authenticate with Modoboa hash instead of the password itself?

@alexcustos commented on GitHub (Oct 19, 2021): > The raw value you're talking about is only available when you set a new password. But what needs to update passwords otherwise? The use case is simple. I want Modoboa to maintain LDAP users that I can use to auth to Nextcloud, for example. In other words, when I create a new user or update its password, I expect Modoboa to sync the provided passwords with LDAP. > Could it be possible that your LDAP tries to hash the password sent by modoboa once again? Sure, LDAP hashes passwords with SSHA or writes them as Plain text, depending on the settings, but that's not the problem. Why would anyone want to teach external services to authenticate with Modoboa hash instead of the password itself?

kerem commented

2026-02-27 11:17:56 +03:00

Author

Owner

@stale[bot] commented on GitHub (Dec 18, 2021):

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.

@stale[bot] commented on GitHub (Dec 18, 2021): 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.