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.

[marcel375]

Is there any news on this issue?
I have a similar problem at the moment. Only difference, I managed to set {"password":null} via the API without any error messages. But after that the user cannot login, the login takes forever (waited longer than an hour).

I wanted to try the workaround from the last comment, but in the database, the deactivated entry in the public.users table is already 0 for that user. I did not find a erased column in this table. A restart of the server after the API call also did not help.

Any information you can provide me would be much appreciated

Version information

Version: {"server_version":"1.56.0","python_version":"3.8.10"}
Install method: Package manager
Platform: Ubuntu 20.04, proxied with Nginx

[squahtx]

After #10598, passing "password": null no longer results in an "Invalid password" error.
Omitting the "password" field still results in a "Must provide a password to re-activate an account" error, which is weird and inconsistent.

[squahtx]

@marcel375 What part of login does the user get stuck on? Can you upload logs spanning the login attempt?

[marcel375]

Unfortunately, there is a lot going on in the log since the server is in use. The following logs are definitely from the login attempt:

2022-04-06 09:00:40,395 - synapse.rest.client.login - 278 - INFO - POST-33231 - Got login request with identifier: {'type': 'm.id.user', 'user': '@abc:abc'}, medium: None, address: None, user: None
2022-04-06 09:00:40,440 - ldap_auth_provider - 178 - INFO - sentinel - User authenticated against LDAP server: ldaps://ldapserver:636 - ssl - user: uid=abc,ou=abc,dc=my-org,dc=tld - not lazy - bound - open - <local: IP - remote: LDAP_IP> - tls not started - listening - SyncStrategy - internal decoder
2022-04-06 09:00:40,458 - synapse.handlers.auth - 974 - INFO - sentinel - Logging in user @abc:abc on device ABC...

So it seems that the login attempt is successful from the server side.

Before and after there are some warnings like this: Starting db txn 'get_users_by_id_case_insensitive' from sentinel context. But they might be from another request, since the server is in use by other people.

[marcel375]

Is there maybe another workaround to re-activate the account, e.g. changing some other database entries?

I have a user on the server who cannot login at the moment because of that issue, it would be great if I could re-enable that account.

[squahtx]

From the sounds of it, Synapse thinks the account is already re-activated. We're going to have to figure out which part of the login is stuck or failing in order to resolve the issue.

Could you search for a line after your log excerpt that contains something like:

Processed request: 30.006sec/0.002sec (0.007sec, 0.000sec) (0.002sec/0.001sec/1) 235B 200 "GET /_matrix/client/r0/login HTTP/1.0" "..." [0 dbevts]

(searching for "/_matrix/client/r0/login" will do).

[marcel375]

Here is the line from the log:

2022-04-11 08:41:10,678 - synapse.access.http.8008 - 427 - INFO - POST-505790 - IP - 8008 - {None} Processed request: 0.059sec/0.001sec (0.000sec, 0.002sec) (0.000sec/0.000sec/0)
 240B 200 "POST /_matrix/client/r0/login HTTP/1.0" "Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Element/1.10.8 Chrome/98.0.4758.74 Electron/17.0.0 Safari/
537.36" [0 dbevts]

I also checked the ID of the request (POST-505790), it matches the one from the login request before

[squahtx]

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