mirror of
https://github.com/modoboa/modoboa.git
synced 2026-04-27 18:05:58 +03:00
[GH-ISSUE #2569] LDAP: password sync is broken #1640
Labels
No labels
bug
bug
dependencies
design
documentation
duplicate
enhancement
enhancement
enhancement
feedback-needed
help-needed
help-needed
installer
invalid
looking-for-sponsors
modoboa-contacts
new-ui
new-ui
pr
pull-request
pyconfr
python
question
security
stale
webmail
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/modoboa-modoboa#1640
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @elgarfo on GitHub (Jul 21, 2022).
Original GitHub issue: https://github.com/modoboa/modoboa/issues/2569
Impacted versions
Steps to reproduce
(i can certainly get more info on this, but i was only tasked with fixing the issue and have not yet much fiddled with slapd config)
the important point is: slapd must automatically encrypt new userPasswords if it thinks the hash type is unknown
Current behavior
there are two issues we were able to identify:
1. modoboa does not send password hashing scheme to ldap-server
TL;DR: modoboa sends
$6$rounds=70000$...to ldap server instead of{SHA512-CRYPT}$6$rounds=70000$...we were able to capture this with tcpdump. when modoboa sends password to ldap
github.com/modoboa/modoboa@c263794784/modoboa/ldapsync/lib.py (L119)we always found it only sends the actual hash starting with$6$rounds=70000$...2. ldap does only understand "{CRYPT}"
TL;DR: modoboa sends
{SHA512-CRYPT}$6$rounds=70000$...to ldap server instead of{CRYPT}$6$rounds=70000$...the second issue is with slapd only supporting {CRYPT} as a scheme. it can understand, operate and generate multiple different hash types (like
$1$,$5$, and$6$) but this is controlled only by the actual hash, not the scheme prefix.these do not work: {SHA256-CRYPT} {SHA512-CRYPT} {BLF-CRYPT}
but their hashes work if stored in userPassword field in LDAP with {CRYPT} as prefix.
Expected behavior
included in "Current behavior" section
Possible fixes:
1. modoboa does not send password hashing scheme to ldap-server
the update_ldap_account function uses get_user_password from that same file
github.com/modoboa/modoboa@c263794784/modoboa/ldapsync/lib.py (L50). we identified an issue in linegithub.com/modoboa/modoboa@c263794784/modoboa/ldapsync/lib.py (L56)which prevents the scheme from being sent if the accounts is not disabled.i fixed it by adding parentheses around the disabled check (see:
github.com/modoboa/modoboa@53dd6c7502)afterwards tcpdump showed the correct full hash with scheme prepended (i.e.
{SHA512-CRYPT}$6$rounds=70000$...)2. ldap does only understand "{CRYPT}"
to fix this issue, i added
"LDAP_DROP_SCHEME_PREFIX""LDAP_DROP_CRYPT_PREFIX" to settings.py and a check in get_user_password which sets scheme to "{CRYPT" when this option is set. (see:github.com/modoboa/modoboa@7432877c34)we verified it working with tcpdump which now showed correct updates to userPassword with full hash like
{CRYPT}$6$rounds=70000$...sadly i am not very good with python and was unable to find where to "declare" that new option for the generated settings.py so this needs to be added by s/o else.
@stale[bot] commented on GitHub (Sep 20, 2022):
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.
@borisdigital commented on GitHub (Sep 26, 2022):
Hm, this seems to workaround/fix our modoboa<>ldap problems. Is nobody else having problems with this? Is anybody at least using modboa w/ ldap in production?
@borisdigital commented on GitHub (Oct 5, 2022):
Ok, i suppose, it should be "LDAP_DROP_CRYPT_PREFIX" in settings.py.
@elgarfo commented on GitHub (Oct 5, 2022):
thanks for pointing that one out. i fixed it in the opening post.
@stale[bot] commented on GitHub (Dec 12, 2022):
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.
@elgarfo commented on GitHub (Dec 13, 2022):
@tonioo you marked this issue with "feedback-needed". what additional feedback do you need to process this further? or is there something else i can do to move this forward?
@stale[bot] commented on GitHub (Feb 11, 2023):
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.