Support

Admin Tools

#10218 Secure Super Administrator ID question under v2.22.a2

Posted in ‘Admin Tools for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
n/a
PHP version
n/a
Admin Tools version
n/a

Latest post by nicholas on Wednesday, 11 January 2012 02:22 CST

Monday, 09 January 2012 01:48 CST

N8BP
Mandatory information about my setup:

Have I read the related troubleshooter articles above before posting (which pages?)? Yes
Have I searched the forum before posting? Yes
Have I read the documentation before posting (which pages?)? Yes
Joomla! version: 1.5.22
PHP version: 5.2.10
MySQL version: 5.0.4
Host: Self Hosted (Win2K3 IIS6)
Admin Tools version: 2.22.a2


Description of my issue:

I Changed super administrator ID #, the original #62 (with the new name) is disabled and the new one (original name) is enabled;
(as expected)

When I log in to the back end, the username displayed under logged in users (Back end Control Panel)is the new name, but this name is using the old ID# and shows as disabled in user manager.

Is this operating as expected? The manual indicates that when the ID is changed, your logon info would be the same but hte used-id used would no longer be 62.

Stephen

Monday, 09 January 2012 03:07 CST

nicholas
Hello Stephen,

The functionality of this feature (and, actually, the code of this feature) has not changed since version 1.0. Here's how it works.

Let's say you have user "foobar" with ID 42. After running this feature you will have something like this:
- User "foobar" with ID 23 (any number below 42), enabled
- User "abcd_foobar" with ID 42 (where abcd is a random four letter string), blocked

A Joomla! user is identified by its numeric ID and NOT the username. Therefore, the new user has a different numeric ID and the old username, the old user has the old numeric ID and a new ("mangled") username. See? Easy :)

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Monday, 09 January 2012 10:23 CST

N8BP
I just thought the system would use the new ID # instead of 62 to log in. (I didn't expect to see 62 identified as the active user)

Monday, 09 January 2012 13:02 CST

nicholas
Stephen,

No, it's exactly what you expected! You are logging in with the NEW USER ID (which has the OLD username). User #62 has a new username, new email and new password, effectively making it impossible to log in using that user.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Monday, 09 January 2012 15:33 CST

N8BP
Im sorry, I may not be relaying my observation accurately. When I log in, I see user #62 as being the one logged in, not the new ID number. when I hover over the link to the user name the browser URL (at the bottom of the browser) confirms that the ID # that I would be editing (if i clicked on it) is 62.

So I am asking if the methodology is allowing the new ID to log in, and then transfering control to the old ID? ...or is there something not working? I would have expected to not see id #62 as logged in ever again.

Monday, 09 January 2012 15:36 CST

nicholas
Stephen,

take a look at the username. Read my previous posts, take a look at the username and ask yourself: are you logging in with the new or the OLD user? Read the documentation again. Did I ever mention, even once, that you should find the user with the mangled username, change its password and use it to log in? Or maybe I said that you should do the exact opposite? See where I'm getting at? You did exactly the opposite of what the documentation told you to do ;)

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Monday, 09 January 2012 15:59 CST

N8BP
No I didnt use the new name to log in. I have not tried to login using the new name.

I am logging on with the same username and password I have always used. User ID #62 shows as disabled in the user manager with the new name (and presumeably with the scrambled password) and the new user Id (which is in the 30 range)

The process as outlined in the documenation is pretty simple, the issue is as you can see Joomla appears to still be using ID# 62.

Monday, 09 January 2012 16:02 CST

nicholas
Maybe the screenshot was cropped a little misleading. I thought that what I saw in the screenshot was the only logged in user. In this case, this is an old login to your site. You can either wait for the session to expire or boot out that stale login.

Put clearly: before using the admin id change feature, you should be logged out from all browsers you use to log in to your site except the one you will use to run the feature. Otherwise, the old logins will cling there until the session expiration. This is how Joomla! login sessions work, not a bug.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Monday, 09 January 2012 16:23 CST

N8BP
The screen shot was taken just as I was posting the message. I am/was the only one logged in.

It cant be the session cache since the admin change was made on Saturday, and I have since (and prior to mey screen shot) purged the sessions through ATPRO. In addition, the only browser open at the time was on the server itself (with no other logins showing active).

If I go to the user manager and show all users, i seethat #62 is the only logged in user. (even though it shows as disabled). I even checked off that user and click the big logout button (to logout users), and I was kicked out of the backend.

Is there a log that can be looked at?
I'd be happy to provide you access via PM.

Monday, 09 January 2012 16:25 CST

nicholas
Just to be perfectly sure we're on the same page: which username are you using to log in to your site's back-end?

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Monday, 09 January 2012 16:30 CST

N8BP
I am using webmaster to login. UJIT_Webmaster is the name ATPRO generated.

Monday, 09 January 2012 16:40 CST

nicholas
Gotcha! I was right all along. You're doing exactly the opposite than what the documentation states. Please read again my posts above.

Recap:
- Old user account: ID 62, username UJIT_Webmaster. You must NOT use this account. Didn't you notice that the email and password was changed and that the docs tell you to block this account?
- New user account: ID between 1 and 41, username Webmaster. This is the account you have to use.

I will say this again: a Joomla! user account is identified by its numeric user ID, not its username. What you think is a new user account is, in fact, the OLD user account (ID=62). The main premise of AT's admin ID change feature is that you continue to use the same username/password as you did before, but your numeric ID is magically changed. We're performing a magic trick ;)

Please re-read the documentation. The docs are improved since 2.2.a1 to make it crystal clear of how this feature works. Despite what they say, some magicians' secrets are best left documented :D

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Monday, 09 January 2012 16:55 CST

N8BP
Again ... Read my post directly above yours.

I am logging in with webmaster (the same name I have been using since joomla was installed in March)

webmaster is listed as a used id in the 30's (not posting the exact # for security reasons) I am following the directions as they are written.

I have not logged into ujit_webmaster, I dont know the password to it since (I assume) it is scrambled. In addition, the user shows disabled in the user manager.

I am the only person with access to the administrator url (especially now since the implimentation of the url password from ATPRO)

(I'd post a full screen shot, but for security purposes, I'd rather Private Message full screens of anything you might want to look at, or I can provide an LMI session etc ...


Tuesday, 10 January 2012 02:45 CST

nicholas
What you describe is impossible. You are implying that you are logging in as "webmaster" but Joomla! logs in the "ujit_webmaster" user. This can't happen.

Here's what to do:
- Make sure that ALL of your browsers DO NOT have a Joomla! session cookie. The easiest way to do that is to clear the cookies of all of your browsers, on all of the computers you are using.
- Make sure you are currently logged in as "webmaster", not "ujit_webmaster"
- Go to phpMyAdmin and manually truncate your jos_session table. Please note that Admin Tools can only purge this table, which means that only expired session records will be deleted. If, for any reason, the old user's session is not expired (it doesn't, otherwise you wouldn't see it there) it will NOT be deleted, unlike what you assumed.
- As per the documentation, demote the "ujit_webmaster" to Registered level. Then edit the user again and block it.
- Log out of your site and back in.

If you still see the old user logged in, try following these instructions more carefully.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Tuesday, 10 January 2012 14:29 CST

N8BP
Now we're getting somewhere :-)

I'm not implying; it is actually happening. I have already checked the session table and there are only guests in the list, I will truncate it and see if there is any impact.

I didnt demote the original SUA as the note in the documentation seemed to indicate the issue was with 1.6 and above. (I'll go ahead and do that as well after clearing the session cache)

Tuesday, 10 January 2012 14:35 CST

N8BP
Truncated the session table and the webmaster account still logs in as #62.

I am looking at the table right now with webmaster logged in that is shows used Id #62, along with UJIT_Webmaster as the username.

I dont see how demoting the SUA will change this particular behaviour, and I am pretty sure based on the results of the query, I woudl get locked out if I did; so I am going to undo the SUA change process as per the documnetation and then try it again.

I will update you with the results.

Stephen

Tuesday, 10 January 2012 15:18 CST

N8BP
I followed the process to remove the changes. During this process I thought of two possible causes:

1. The 'Disable editing backend users' properties' was enabled when the Super Administraor ID process was invoked.

2. This site has Jfusion in place, whereas the PHPBB3 install is set to master.


A related item: Every time I logout of the backend, a security exception is recorded. (Keep in mind that we are back to the default ID of 62).

I havent tried to re-do the ID change yet, let me know if there are any particular tests you would like me to do to confirm if Jfusion is involved in eitehr the new ID issue, or the security exceptions.

Stephen

Tuesday, 10 January 2012 15:25 CST

nicholas
Stephen,

Neither Joomla! nor Admin Tools include any code which would do something as stupid as to type in username A and logging you in as username B. However, I can not guarantee that third party developers are not doing stupid things like that. I have not tried Jfusion, so I can't say if it's something they have documented, something they have not thought of or completely unrelated to the whole issue. All I can tell you is that this is not a bug in Admin Tools (try it on a stock Joomla! installation), it's not something standard Joomla! does, it is the product of either a third party plugin or a core modification, therefore I can not provide assistance for other developers' code. If you suspect Jfusion is causing that, please ask its developers.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Tuesday, 10 January 2012 15:46 CST

N8BP
Well, actually my point was that I would have been happy to assist in alpha/beta testing your code going forward, and improving the documentation to where the user base would be aware of interaction issues. Obvoisly something in software is impacting the functionality, and I believe it is Jfusion.

I have not pointed any fingers, but waited for imperical testing to reveal a reasonable path to what the issue may be. I am a professional and deal only in the mechanics of an issue no matter where they lead.

In fact, an additonal clue was uncovered when i was allowed to log in using the SUA account in the front end while the WAF was still configured to prevent it. You see, Jfusion is used to integrate the user databases of multiple platforms, the login module is not Joomla's but Jfusion's. The integration may infact be referencing the original UID in the joomla user table when logging the SUA in. I also suspect that the Joomla disable user function is relying on the joomla login module to deny access.

The solution for the changing of the SUA ID is probably just the manual adjustment of the jfusion master database. In addition, the Jfusion folks (once I confirm the interaction) will need to look at whether they are looking at the enabled/disabled status of a user as part of the sync process.

In some cases you responses have been defensive and dismissive (even contridicting previously established facts. I had offered remote access, direct access, and anything additional you may have required to sort this.

I will still return a confirmation to you once I complete my testing to determine exactly where the root cause is. If I am correct, you will most likely want to include a note in the manual advising the user based to watch out for interactions with Jfusions and other database integrators.

Stephen Reinen, N8BP (President, URSA)

Tuesday, 10 January 2012 23:23 CST

N8BP
Resolution:

Due to the interaction between the JFusion component and Joomla!, (wherein this case Joomla! is set to be configured as a slave to a master PHPBB3 database) Once the Admin Tools Super Administrator ID process has completed, login events will still be applied to the original ID# until a manual sync from the slave to the master is done.

[Note: This occurs because JFusion maintains a conversion table of user IDs and is replacing the user ID from the Master platform with the user ID populated from the slave platform (in this case Joomla!) when that user was originally synced into the master database.]

To correct the behaviour:
To prevent a loss of data continuity, a sync from the master to the slave should be completed first, then sync the slave to the master usign the new user sync tool.

Once this is completed, aditional steps of editing the original Super Administrator's record in Joomla!'s user manager will be required to re-block the user. To accomplish this, the old super administrator will need to be demoted to a registered user and the change saved. Then edit the same user again to block the user.

When using JFusion in this manner (where Joomla! is not the master database), it also should be noted that the feature of blocking the super Administrator from logging into the front end will not function as expected if the JFusion user_login plugin is in place.

Also note that if using Admin Tools secret URL functionality along with JFusion; when logging out of the Joomla! backend, a Security exception will be generated by Admin Tools because JFusion will re-direct the browser to the default /administrator URL instead of the secret URL or the front end URL.

Stephen, N8BP

Wednesday, 11 January 2012 00:59 CST

nicholas
Hi Stephen,

Ah, that makes sense now, albeit the way JFusion works is wrong. Ideally, they should have two plugins:
- A user plugin which looks out for the existence of a Joomla! user record with the provided username. If it doesn't exist, it should query the master (phpBB3) database for information and create a new Joomla! user.
- An authentication plugin which, if the regular Joomla! login has failed, would verify the supplied password against the master database.
Had they done that, they wouldn't have to do the sync and by no means should they override the Joomla! user login with their own, completely custom solution!

To me, it seems that the JFusion folks don't really understand how Joomla! works and they have created a monster of a solution :( Essentially, they are modifying the way an important part of Joomla! (user login) works by completely overriding it, causing properly written software (like Admin Tools) –which use nothing but the Joomla! API– to no longer work as designed. This is pretty much the same thing as core hacking, but without violating the Joomla! Extensions Directory rules. Ugh!

Well, thank you for the write-up, I am adding it to the documentation. I will also have JFusion in mind when somebody else reports a login issue.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Wednesday, 11 January 2012 02:18 CST

N8BP
Most welcome!

A website developer in our group (strongly) suggested setting JFusion up with PHPBB3 as the master; the reasoning he had was that PHPBB3 (vs Joomla! 1.5) had more flexibility in security levels. (Personally, I don't see it).

JFusion does appear to be the best available for what it does, I just think that it makes better sense configuring Joomla! as the master.

Please be sure to note(in the documentation) that the items I described will only be an issue if Joomla! is not the master database.

You really do have a great set of tools here, and I will be sure to recommend Admin Tools to everyone.

Stephen, N8BP

Wednesday, 11 January 2012 02:22 CST

nicholas
Hello Stephen,

I agree, it makes much more sense to have Joomla! as the master database, but I still think that JFusion is a necessary evil. It's dramatically modifying how Joomla! works. As Gordon Ramsey would put it, it's the "best of the worst".

phpBB3 and security have divorced many years ago. I don't understand why anyone on his right mind would trust the stone-age phpBB3 system for security, but I digress :)

I have now added a documentation note that this only applies when phpBB3 is the master.

Thank you for your kind words!

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!