Repository navigation
Login stuck after re-activating an account when using LDAP authentication, with local users/passwords enabled #12456
Description
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)
Activity
squahtx commentedon Apr 12, 2022
After #10598, passing
"password": nullno 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 commentedon Apr 12, 2022
@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 commentedon Apr 12, 2022
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: None2022-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 decoder2022-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 commentedon Apr 12, 2022
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 commentedon Apr 12, 2022
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:
(searching for "/_matrix/client/r0/login" will do).
Originally posted by @squahtx in #10397 (comment)
squahtx commentedon Apr 12, 2022
Here is the line from the log:
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 commentedon Apr 12, 2022
@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,
/syncrequests 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 commentedon Apr 12, 2022
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 commentedon Apr 13, 2022
No worries. If you ever manage to track down the other issues in a reproducible way, a bug report would be welcome.