Repository navigation
Re-activating account is impossible when using external (LDAP) authentication (with local users/passwords enabled) #10397
Description
Description
When both external LDAP authentication and local user/password authentication are in use and a user (authenticating via LDAP) has been disabled, it is not possible to re-enable said user without setting an additional local Synapse user password. This makes it virtually impossible to re-enable a deactivated LDAP user.
Steps to reproduce
Login for the first time using external LDAP authentication. The user is then touched in the Synapse DB with an empty password_hash. The user admin api will return:
{
"name": "@user:server.com",
"password_hash": null,
"is_guest": 0,
"admin": 0,
"consent_version": null,
"consent_server_notice_sent": null,
"appservice_id": null,
"creation_ts": 1595490945,
"user_type": null,
"deactivated": 0,
"shadow_banned": null,
"displayname": "user",
"avatar_url": null,
"threepids": [],
"external_ids": []
}Deactivate the account:
curl -X PUT -H "Authorization: Bearer ${token}" -H "Content-Type: application/json" \
-d '{"deactivated":true}' \
"http://127.0.0.1:8008/_synapse/admin/v2/users/@user:server.com"
Trying to re-activate the account will fail:
curl -X PUT -H "Authorization: Bearer ${token}" -H "Content-Type: application/json" \
-d '{"deactivated":false}' \
"http://127.0.0.1:8008/_synapse/admin/v2/users/@user:server.com"
{"errcode":"M_UNKNOWN","error":"Must provide a password to re-activate an account."}
Trying to re-activate with explicitly setting the password to null fails too:
curl -X PUT -H "Authorization: Bearer ${token}" -H "Content-Type: application/json" \
-d '{"deactivated":false,"password":null}' \
"http://127.0.0.1:8008/_synapse/admin/v2/users/@user:server.com"
{"errcode":"M_UNKNOWN","error":"Invalid password"}
Not relevant for this issue, but setting the password to an empty string "" is possible and will set a password_hash (not sure when this would be desirable):
curl -X PUT -H "Authorization: Bearer ${token}" -H "Content-Type: application/json" \
-d '{"deactivated":false,"password":""}' \
"http://127.0.0.1:8008/_synapse/admin/v2/users/@user:server.com"
Possible solution
Allowing to explicitly set {"password":null} in the User Admin API while re-activating the user should solve this.
Version information
- Homeserver: Synapse
- Version: 1.38.0
- Install method: pip
- Platform: Debian 10 Buster
Activity
anoadragon453 commentedon Jul 21, 2021
Note that this is separate from #8393 (fixed by #9587) as the local password database is enabled here.
Perhaps instead of requiring a password for the call if the local DB is disabled, we instead only require it if the user is considered a local user?
The rather inconvenient workaround is to edit the database manually, by updating the
userstable to setdeactivatedanderasedto 0, then restarting the server to clear caches.marcel375 commentedon Apr 6, 2022
squahtx commentedon Apr 6, 2022
squahtx commentedon Apr 6, 2022
marcel375 commentedon Apr 6, 2022
marcel375 commentedon Apr 11, 2022
squahtx commentedon Apr 11, 2022
marcel375 commentedon Apr 12, 2022
squahtx commentedon Apr 12, 2022
(Moved a series of comments into their own issue: #12456)
dklimpel commentedon Dec 7, 2023
Related to #14686
There are similar problems with Admin API and user's passwords.