Support

The fact that we are having this conversation on a site where Admin Tools is updated before releasing the update to the rest of the world, the fact that nobody else has reported anything similar, and the fact that the changes made cannot block you tell me that it's not a bug in the software. Something else is going on.

For starters, there is something you said that struck me as odd: " I had to disable via FTP and unblock my account in the MySQL database". This sounds like your user account was disabled, not your IP addressed blocked. There are two features which can do that. Neither has been touched in the last two and a half years. One of them is triggered by the number of failed logins, the other is time-based, meaning that both could be incidentally triggered after the update, without the update having anything to do with the trigger. Remember, correlation does not equal causation.

After gaining access to your site's backend go into the Configure WAF page, Hardening Options tab, find "Deactivate users on failed login", find "Number of failed logins" under it and set it to 0. If that solved your problem, the root cause is that you have too many failed logins on your user account which were triggering this feature. Clearly, you don't want this feature, so keep it disabled.

The other feature is time based and does have an exception, but maybe it was not set up correctly. Go into the Configure WAF page, Hardening Options tab, find "Prevent forgotten backend users from logging in" and set it to No. If this worked, you can set it back to Yes and also remember to add your Super User account(s) in the "Protected users" option below it.

This sounds like your user account was disabled, not your IP addressed blocked. There are two features which can do that. Neither has been touched in the last two and a half years. One of them is triggered by the number of failed logins, the other is time-based, meaning that both could be incidentally triggered after the update, without the update having anything to do with the trigger. Remember, correlation does not equal causation.

After gaining access to your site's backend go into the Configure WAF page, Hardening Options tab, find "Deactivate users on failed login", find "Number of failed logins" under it and set it to 0. If that solved your problem, the root cause is that you have too many failed logins on your user account which were triggering this feature. Clearly, you don't want this feature, so keep it disabled.

The other feature is time based and does have an exception, but maybe it was not set up correctly. Go into the Configure WAF page, Hardening Options tab, find "Prevent forgotten backend users from logging in" and set it to No. If this worked, you can set it back to Yes and also remember to add your Super User account(s) in the "Protected users" option below it.

Here is the thing. You are telling me that you are positive the user account is getting blocked (its block field is set to 1), and that it only happened after the last update. This made me look for features which a. block user accounts; b. are date based; and c. are not too obvious.

Since you already checked them, let's go to the other two features which can block a user account.

There is the Temporary Super Users feature. If your user account is marked as a temporary super user and you've reached its expiration date, Admin Tools will automatically set it to blocked. Go to Admin Tools, Temporary Super Users and make sure this is not the case. I had excluded this before because I both thought it's too obvious, and I assumed you are the site's only Super User. Based on your last reply, at least one of these assumptions is wrong.

The fourth and final feature which can possibly block a user account is "Monitor Super User accounts". Go to Configure WAF, Hardening Options, and disable "Monitor Super User accounts". If that works, you can re-enable it afterwards. When you disable, save, re-enable, and save again you reset this feature. I excluded this feature because it has not been changed since October 25th, 2021 and you told me you have a problem only since the last update. It is, however, possible that its file was previously missing for whatever reason and the update simply added it back, therefore you are now seeing a problem caused by a setting you had changed a long time ago.

That's it. There is absolutely nothing else in Admin Tools which can block a user account. Everything else blocks the request and (eventually) might block your IP address.

Which brings me to a final check. I know that you said the user account is disabled. But is it at all possible that your IP is blocked as well? Have you checked that? If not, please do.

Other things which can and will block your user account are, of course, core Joomla! features. If you are using Joomla's privacy component and you don't accept the ToS your account will be blocked. If you ask for a password reset your account becomes deactivated. Have you checked if those things, unrelated to Joomla!, happen?

Finally, the deprecation notice you mentioned is exactly that. It's not an error. It also goes away when you save the Admin Tools configuration.

This last version has definitely not touched the Monitor Super User accounts feature. As I told you, last time we changed it - excluding the copyright date update in the comment at the top of the file - was October 2021. This is not me trying to remember, this is me looking at the Git log of the file implementing this feature.

What we do know is that if anything messes with the Super User accounts outside of Joomla's backend Users component, or the user groups privileges change, the list used internally by this Admin Tools feature is no longer in sync with the state of who is a Super User and accounts can and will get blocked. This is what this feature is supposed to do: if someone messes with the Super User designation, it protect your site by instituting a lock-out, therefore an attacker who tried to escalate their privileges will leave empty-handed.

When you disable this feature the internal list is removed. When you re-enable it, it's re-created. This is also intentional, so that you can reset the state of this feature if any changes made to your site were intentional e.g. someone became a Super User while the plugin was disabled, you had a CLI script create Super Users, or whatever else. This has been the case since April 2017, when this feature was added to Admin Tools (again, I am looking at the Git log which links to our GitHub issue tracker which has the notes of the original implementation; I am not trying to magically remember what happened 7 years ago, my memory is nowhere near that good).

I am a bit confused. You said that disabling the Monitor Super User Accounts solved the problem for you. Did it, or did it not...?

The Monitor Super User Accounts feature only affects Super Users, as the name implies. It has nothing to do with Administrator or below.

Moreover, since their accounts are NOT blocked you can easily deduce that any of the features we discussed here – all being features which block a user's account – are NOT in play.

Your users are blocked by something else. Ask them for their IP addresses when they are blocked and check the Blocked Requests Log for entries with these IP addresses around the time they are blocked (remember, times may appear in the UTC timezone). This will tell you why their IP address is blocked. I could make a wild guess (administrator secret URL parameter), but I'd like you to check the log so we can be certain.

You're welcome!