A user has blocked himself from login - now the blocking time 10min is more than 30min back and the user still gets the notification “Login has been temporarily blocked for this User”
No idea why the rocket.chat server did not unblock the user automatically after 10 minutes, and where is the admin option to manually unblock the user ? Did not see anything suitable in the administration section…
There is no 2FA involved.
Server Setup Information
Version of Rocket.Chat Server: 3.9.3
Operating System: Linux
Deployment Method: tar
Number of Running Instances: 1
DB Replicaset Oplog: active
NodeJS Version: v12.18.4
MongoDB Version: 4.0.21
Proxy: nginx
Firewalls involved: yes
Any additional Information
journalctl -u rocketchat.service
Failed login detected - Username[ronald] ClientAddress[192.168.130.1] ForwardedFor[192.168.130.1] XRealIp[192.168.130.1] UserAgent[Mozilla/5.0 (X11; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0]
Dez 20 12:43:39 server rocketchat[193011]: Exception while invoking method login Error: Login has been temporarily blocked For User [error-login-blocked-for-user]
Dez 20 12:43:39 server rocketchat[193011]: at app/authentication/server/startup/index.js:307:9
We have exact same problem, but with email 2FA enabled and believe it is a glitch in Rocket Chat?
The only way I could fix this was to go to Administrator → Users, select the user account, then click on reset 2FA, disable them and then re-enable them; and finally, untoggle the button to unverify the users email address. We also tried rebooting the Rocket Chat server.
The user was only able to login again once the email address wasn’t “verified”.
Definitely some unexpected behaviour happening behind the scenes…
The exact thing happened here. No 2FA, users taken from Active Directory, when the AD GPO forces users to password change, it seems RC doesn’t refresh on most of my users (but others do) and some of them ends blocking their RC account.
Administrators should be able to unblock users manually and without doing any trick nor asking any intervention on the user-side.
Sorry, my bad… server version is 3.12.3 and users are synced from an Active Directory, if that matters at all.
Users are self-unlocked after a while, but that mechanism doesn’t seems to honour the time specified on settings (5 minutes) and the few users have lock their account would be able to login back after 15~20’ (sorry for being so imprecise, but they notified me after that time, but I warned them to try to login back after the sixth minute and they weren’t able to log in)
OK thanks. When debugging issues details really do matter. Even little ones!
As per this from our bug reporting template the very first thing to do when trying to fix things is get your system up to date, or at least test on the latest version. Bugs get fixed quite rapidly and your version is a few months out of date. There are a lot of new features too.
Experience has taught me that it is quite counterproductive to have the latest version of RocketChat in production. We suffered bug after bug until we got to version 3.12.3 which is pretty stable, so I’m not going to upgrade until after extensively testing the latest version or reading the issues on github before upgrading. My bosses would not forgive me another catastrophic bug like the ones in 3.12.1 and 3.12.2.
Bugs are not fixed as fast as you say, there are certain CSS issues reported months ago, or suggestions already approved by the developers years ago that are still in the pipeline.
By this I don’t mean I won’t upgrade, just that I’ve jumped off the latest version bandwagon. I have to set up a test server and test with the latest version, to see if the same thing happens there and report back.
By Rocket, user is unlocked on the AD, of course. Failing to log in into RC doesn’t lock AD user on the domain.
The point is that you aren’t even on the latest point release - have you checked? I would…
In any event 3.12.x is EOL.
I know that isn’t what you want to hear, but the point is if you have found a bug in your version, it won’t get fixed and backported.
You don’t have to actually upgrade. Just run a test server. I have one that is a main server, and the second that runs latest to see what issues there might be before I upgrade the main install.
So, if there really is an issue it will only be looked at if it is on latest or a development version.
I think in time the development cycle may slow a bit, but not yet.
BUG! I have now tried around with a colleague and we have found that the failed login counter is not reset!!! There is a bug in the code! PLEASE FIX URGENTLY!
