Umbraco-CMS: Don't hide the initial user (also known as "SuperAdmin") from the users section

Conclusion of the discussion below:

  • Let’s make the user with id -1 be visible in the users editor.
  • If you want to use this one as a SYSTEM user for auditing purposes, you can create an additional admin and disable the -1 account.

We’re looking for a PR to address the above: make the user visible to other admin users.


Original issue description

A recent discussion led me to think about what the initial user account in Umbraco (id 0 in v7 and id -1 in v8) really means and why it is considered “special” and needs to be hidden.

It is being called “SuperAdmin” which makes it seem like it has special powers. However, this account has no real special privileges and is just like any other administrator account. Any administrator account can edit any other administrator account. I think this is a good thing:

  • when someone gets fired from the organization, their admin account can be disabled
  • when an admin forgets their password someone else could reset it (in case “forgot password” is unavailable for some reason)
  • an admin can demote another admin in case they don’t need admin access any more
  • etc.

This is no different for the first account ever created in Umbraco. In fact, by hiding that account you risk not ever knowing about it. What if they set up that account with a password like admin123456? Easily hacked.

Also, if you did actually know about that account then you could choose to disable it if it’s not being used.

So, my proposal is: given that we allow admins to edit other admins, is there an actual risk of an admin editing the initial user account (which is just another admin account)?

I can’t think of anything and, in fact, I think that the initial admin account should not even be hidden any more. Am I missing anything?

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 4
  • Comments: 22 (16 by maintainers)

Most upvoted comments

Okay, so we’ve come full circle.

The proposal, based on all the feedback (thank you!):

For existing installs, need a migration

  • Copy everything from current user -1 to a new user (database migration, probably only need to update the Id column and take the first available Id that is higher than 0)
  • Create user -1, it doesn’t exist now set the UserLogin to NULL and UserPassword to NULL
  • Should be good now, we can carry on

For new installs:

  • User types their username, password in the install screen
  • Umbraco creates user -1 setting the UserLogin to NULL and UserPassword to NULL
  • Umbraco creates the new user as requested from the install screen with a user Id higher than 0

Fix:

  • Currently, it is possible to manually go to /umbraco#/users/users/user/-1 if you can edit users. This should now no longer be possible, the SYSTEM user also needs to be hidden from the overview as it can never be used by a human.

Did I miss anything?

I’m not sure if NULL is possible?

Totally, and it never allows any password to work.

We’ve got a migration to move the default user from ID 0 to -1

I think it would be great to move the existing -1 user to the next available user Id (if there’s already 12 users created, it would get id 13). We’d lose audit history but maybe that’s not so bad as it will be consistent from then on.

It doesn’t seem viable to move all the audits over, since as Callum mentions that might be very expensive. Plus… it’s still inconsistent anyway, since not all of the -1 logs will have been caused by the -1 user 🤔

We will always need a ‘system’ or default admin user that can never be removed because this is the default user that performs actions when an explicit Id is not specified (i.e. when using the APIs directly or scheduled tasks, etc…)

Side note: We should absolutely make sure we never have a user of 0. The whole reason why the default admin is -1 is because there is a problem in v7 having them as 0 which is related to the fact that the default(int) value is 0 . So there’s some strange technical challenges when a user id is 0, hence it’s no longer the case.

I just want to say again… it’s “just” a user. It is not special. I really don’t think we need to treat it as anything special.

I am sensitive to @callumbwhyte’s suggestion that we should not use “-1” for anything apart from “we don’t know who did this, so just log against -1”. However, we’re currently stuck with that having to be an actual user.

We could, when setting up Umbraco, set up a user -1 with a NULL password (so you can never ever log in) and then create a user from the entered info in the install screen that will be user 0. We can hide -1 as we do now and that would also work fine. This also makes it more consistent that whenever something is logged against user -1 it can never be confused with an actual existing user.

Of course, this will still be a bit of a mix for people who upgrade, user -1 will still exist. So I am not sure what to do there. Suggestions? User -1 will already exist, and be a real user for which we must be able to update the password & their enabled/disabled status.

Not sure about in V8, but it certainly used to be the case that any actions performed via services in custom code (e.g. the content service) were recorded against the default / first user ID.

Once upon a time, where this user could be anyone, it created some confusion when looking at the logs - being unable to tell if an action was triggered by code or a real user in the backoffice - hiding / disabling the default / first user solved this as it made it impossible to login.

For content, node ID -1 is reserved by the system as the content root and as such we can’t edit or make any changes to that node - based on this I don’t personally think it makes sense for the “system” user to be usable / editable either.

Perhaps the “system” user should always exist and only be controlled by Umbraco itself, with an ID of -1, and all other users can be created (ID starting from 1?)… I guess that user should never be able to access the backoffice… Maybe it doesn’t even need to be in the database? (don’t know the technical constraints!)

Just my 2 cents 😊

I agree. Maybe the super admin account should have a special iconography to help understand the difference, but yes no more hidden.