Re-activating account is impossible when using external (LDAP) authentication (with local users/passwords enabled)

[rda0]

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

[anoadragon453]

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 users table to set deactivated and erased to 0, then restarting the server to clear caches.

[squahtx]

(Moved a series of comments into their own issue: #12456)

[dklimpel]

Related to #14686

There are similar problems with Admin API and user's passwords.