I think this will not work anymore, because in Joomla 1.5 an additional $salt parameter is used to encrypt the password. In the usertable the password is stored in the format:
so simple md5 hashed passwords will not work anymore...
It worked for me when I tested it. Mark Dexter 15:08, 4 October 2008 (EDT)
Trust me :-) You can put in an md5 in the database as the password, When that user tries to login Joomla will notice that the password is md5 hashed and will then UPGRADE that password to a SALTED password, saving the result back to the database - thats why it works :-) Phil Taylor
Depending on the version of the MySQL server, the function LAST_INSERT_ID( ) can produce 0 and the recovery procedure fails.
You can insert the admin2 user into the last two tables 'manually'. Run this query to find out the id of the admin2 user:
SELECT * FROM `jos_users` WHERE username = 'admin2'
Use the value of id in the next query to replace 9999:
INSERT INTO `jos_core_acl_aro` VALUES (NULL, 'users', 9999, 0, 'Administrator', 0);
Use the value of id to replace 9999 to find out aro_id:
SELECT * FROM `jos_core_acl_aro` WHERE value = 9999
Use the value of aro_id in the last query to replace 8888:
INSERT INTO `jos_core_acl_groups_aro_map` VALUES (25, , 8888);
Toivo 00:44, 10 May 2009 (UTC)
My solution: I set manually values for tables jos_core_acl_aro,jos_core_acl_groups_aro_map and jos_core_acl_aro_sections. I had an other joomla database where I could compare values and make changes to "problem" database. ProJoomla 20:15, 4 May 2010 (UTC)
I recently had a blip to jos_core_acl_aro that gave me a constant invalid key error. I followed the advice in this Wiki and still could not get back end admin access.
Ultimately, I used MySql to delete the information completely from the table. Then I had to go back into the jos_users table and manually delete each entry that was NOT the new admin2 user just created per this Wiki. (My DB only had a half dozen users, most of which were me, anyhow.)
I then performed a check, then repair on the jos_core_acl_aro table, with a final "o.k." message. After this point, I could again log into the back end using the new admin2 username and created password (secret/OU812/admin), and re-established all accounts, changed the admin password, and voila.
Curiously, I did nothing to any other table. I am NOWHERE near a Joomla expert, a PHP guru, or even knowledgeable about SQL. So I'm suspecting (as someone will assuredly clear up in the future,) that the other operations I missed were suggested for those users intent on NOT losing their existing member accounts / information.
This is not to say, of course, that I did not attempt it. I did. But the incorrect key error was plaguing me, and the extended Support time was too long to wait to find out if I was really hacked or not.
This entry is offered for review, comment, correction, or expansion- but mostly for those who are in the same position I was in: they need a very quick way to take control of their site back, and assess the damages, if any.