Support

The value of cparams is perfectly valid and decodes correctly. It's not cut off, it's not corrupt, it does not contain illegal values. The quickstart flag is set to 1 which tells Admin Tools not to show that message.

At this point I can tell you that this problem does not come from the database data and does not come from our software. The only logical explanation is that our software is not being provided the data stored in the database, hence the reported issue. We do go through the Joomla database to retrieve this information but it's possible for third party extensions (and site integrators) to override it with their custom driver implementation.

Regarding your question, yes, Admin Tools, Akeeba Backup and LOGman work just fine with each other. The former two are both ours and we make a point of making sure that our software works together (otherwise what the heck are we doing anyway). We explicitly added support for LOGman (and other Koowa-based software) in the one feature in Admin Tools that could get in the way since early 2015. Before that LOGman would simply not work unless you made a change in Admin Tools. Nothing of what you say you have installed can cause the problem you are experiencing.

Barring an issue at the database server level which randomly causes queries to return corrupt or no data there's no explanation of your issue. It is very clear to me now that your problem has nothing to do with our software, what you do with it or what kind of data is in the database. It is a problem at either the site or the server level. Since it's happening at multiple sites I am more inclined to think that there is a systematic problem at the server level. Unfortunately I cannot help you pinpoint it since, well, I didn't set up your servers.

On one of the websites, the issue accrued over the weekend and there weren't any backend interactions there

When that happened did the #_admintools_storage table have a cparams with a value that included "quickstart":1 in it? This is how Admin Tools knows if it's been configured or not. If that's still 1 and you get a warning then the problem is on the database or database driver side of things. If that value does not appear at all or is 0 then the problem is that something screws up your database contents.

Could you please provide more info regarding this one?

Falang, for example, ships its own database driver to handle translated content.

Please go to Admin Tools, Web Application Firewall, Configure WAF and set Enable IP workarounds to Yes (instead of Auto). Does that solve your problem (you have to give it a week).

Also, I was wondering about something else. Do you have anything related to Admin Tools scheduled over the weekend, e.g. the PHP file change scanner?

Moreover, do you have any kind of backup / restoration going on automatically over the weekend?

What I think is most likely to have happened is the following. Something third party removed the the cparams row from the database. At this point the automatic IP workarounds code in the system plugin kicks in and determines the IP workarounds must be enabled. It sets ipworkarounds to 1 and saves the (otherwise empty) configuration back to the database. The only thing that worries me is that it happened over the weekend which seems to be a pattern in your sites. I assume that you are running automations over the weekend so I'm trying to figure out if there's an errant automation at play here. Or if my assumption of what most likely happened is at odds with some other piece of information.

BTW, seeing the cparams you sent me in your last reply means that your original post in this ticket was wrong and you can ignore my first reply. Clearly, Admin Tools complains that it's not configured because it is IN FACT not configured. It's not a database driver issue. We just have to figure out why the data in the database changed without you doing something obvious as far as we know.

OK, you have ruled out all possibilities for a weird bug nobody else has reported and we can't reproduce. This leaves us with one possibility only: something is emptying the #__admintools_storage table or at least the cparams value. Unfortunately that's as far as I can possibly go into helping you. This is not something that comes from us and it's not something you can keep a log of. If I understand correctly this happens only to sites on a specific server which makes me think that it's something server specific. I just can't guess what would that be :(

Well, your tests confirm what I told you (I actually did the same test). The only way what you reported can occur is if something or someone explicitly empties or deletes either the cparams database row or the entire table. I can only tell you that it's not us.

When this happens is the security of the site damaged and how much?

The answer is yes and very much so.

The cparams row contains the entire Admin Tools configuration. When it's deleted you go back to the unconfigured state, as if you just installed Admin Tools. By default, the protection features enabled are minimal on purpose.

Could this be a malicious attack on the site?

In theory? Yes. If your site is already compromised by an at least semi-sophisticated attacker they could be routinely emptying the configuration of security extensions. However, there are several reasons I would suspect incompetence over malice.

First of all, emptying the configuration is pointless. As I said, a modicum of defenses is still enabled even when the configuration is nuked. Moreover, it doesn't address a .htaccess file potentially generated by the .htaccess Maker. From an attacker's perspective this state does NOT give them uninhibited access to your site and alerts you to their presence. It's the equivalent of cutting off power to an alarmed building, meaning that the doors remain locked and the alarm system starts blaring its horn. Not quite the subtle approach an attacker wants.

Moreover, you said that it happens to all of your sites on a specific host even if there are no third party extensions in common. Most hosts would forbid one site reading another site's files which is the minimum requirement for being able to retrieve their database connection details so you can pull off that kind of misguided and useless attack.

On the same tune, when I see database contents disappearing randomly from the database my suspicions are more focused on what could possibly write to the database. Typically this is host software which may be running a misguided "security check", screwing up your site. Or it could be an automated partial database restoration. Or it could be an extension doing an automated import which unfortunately screws up your database. I honestly don't know. I would back up one of the sites and restore it on a development server on a different host and see if this issue can be reproduced. If the alternate host version doesn't break I will rule out a third party extension and start thinking that it's either a site administrator doing something funky or a hosting issue.