Login stuck after re-activating an account when using LDAP authentication, with local users/passwords enabled

[squahtx]

Split out from #10397 :

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

Originally posted by @marcel375 in #10397 (comment)

[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.

Originally posted by @squahtx in #10397 (comment)

[squahtx]

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

Originally posted by @squahtx in #10397 (comment)

[squahtx]

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.

Originally posted by @marcel375 in #10397 (comment)

[squahtx]

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.

Originally posted by @marcel375 in #10397 (comment)

[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).

Originally posted by @squahtx in #10397 (comment)

[squahtx]

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

Originally posted by @marcel375 in #10397 (comment)

[squahtx]

@marcel375 That seems to suggest that the login succeeded...
Perhaps the client got stuck on a subsequent operation? I'd be interested to find out what screen the user's client got stuck on.

Could you also search the logs for further requests from that IP? In particular, /sync requests and requests with a long processing time are of interest.

Does the user have multiple clients? If so, are all of them affected or just some?

[marcel375]

I just deactivated and reactivated a test account with no problems.

The other account had the problem with the login before, but since there was the open issue about reactivating, I thought this would be the cause of the problem. I think there might as well be other issues with that account since the test account had no problems after the procedure.

Sorry for the inconvenience

[squahtx]

No worries. If you ever manage to track down the other issues in a reproducible way, a bug report would be welcome.