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

[nul800sebastiaan]

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?

[fraabye]

I would say make it visible for complete transparency. As you mention an unknown account with a weak password may lead to a compromised installation. Perhaps look into conditional access control for the SuperAdmin or perhaps leave it disabled if possible?

[gfchaves]

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

[callumbwhyte]

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 😊

[nathanwoulfe]

Maybe visible but not modifiable outside of password changes - I agree it should be visible for transparency, but wouldn't want to be able to remove access to a section and have code break due to insufficient permissions.

Would be easy enough to differentiate the SuperAdmin in the UI, and even include context to explain why the user exists.

[nul800sebastiaan]

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.

[Shazwazza]

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.

[callumbwhyte]

Seems sensible!

I like the suggestion of the "system" user having a NULL password (or set the password to be a random generated Guid as I'm not sure if NULL is possible?)

Perhaps we can get around the issue of upgrading users with a migration... If a user exists with ID -1 and the password isn't NULL, change the user ID, and insert a new "system" user at -1? Could be a pretty heavy operation if there's a lot of content though as document owners, umbracoLog table, contentCacheNu table would need updating...?

[stevemegson]

We've got a migration to move the default user from ID 0 to -1, so that could presumably be modified to move any existing user from ID -1 or 0 to the next available ID, making them a "normal" admin. That would leave -1 available to create the "system" user that we'd create for a new install.

We'd probably be left with some of the real user's past actions attributed to "system", but I think that's no worse than the existing confusion of having system actions attributed to the real user.

[nul800sebastiaan]

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 🤔

[callumbwhyte]

Ahh completely overlooked that we wouldn't be able to differentiate between system -1 and real user -1 in a migration...

Perhaps, as you say, it's just something we have to live with... Without in depth knowledge of the V7 => V8 migrations I'd hazard a guess that this wasn't considered for changing default user ID 0 to -1 either 😆so it would be fine. Or if it was considered then we already have some code to do it...

Seems like a pretty good solution to me! 🎉

[gfchaves]

After reading more suggestions, I do agree that the name should change for a more contextual understanding, something like SYSTEM_ADM_ACCOUNT. Like Shazwazza remarked, it's the default that everything at last should be assigned, also for GDPR compliance, like data deletion and so on.

The Null password, sounds a good option, but also we could create a flag to indicate that is a system account and it can't be used to perform sign-ins. maybe in the future the umbraco users need to create system accounts for external APIs integrations or custom implementations.

Although i still think that all accounts should be visible, but of course we can display them according their "profile" type.

[nul800sebastiaan]

we could create a flag to indicate that is a system account

User Id -1 == system account. 😊

We could probably also make the username NULL so it doesn't even look like something you can use to log in as (when you dig into the database).

[gfchaves]

User Id -1 == system account. 😊

sorry Seb, i don't agree that -1 should be the flag for a system account. I believe that something minus x indicates something that we can't or know how to handle.

[abjerner]

@gfchaves Umbraco already uses negative IDs for the recycle bin and build-in data types, so I don't believe it will be that different.

Besides creating the migration, it may also be the solution that requires the least amount of changes in the codebase, as methods in the various services already use -1 if nothing else is specified (AFAIK).

[nul800sebastiaan]

You may not agree, but that's how it already is: https://github.com/umbraco/Umbraco-CMS/blob/v8/dev/src/Umbraco.Core/Constants-Security.cs#L15

Let's be pragmatic and not get stuck in semantics please.

[gfchaves]

@gfchaves Umbraco already uses negative IDs for the recycle bin and build-in data types, so I don't believe it will be that different.

That's ok, i think that we can live with the negative ids, for the current process.

Regarding the pragmatism, and sticking to the original question of the issue, in my opinion I think that Super Admin shouldn't be hidden.

[nul800sebastiaan]

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?

[abjerner]

@nul800sebastiaan looks good 👍

Also remember to emphasize in the release notes that this is a breaking change should you have some custom code that checks the user ID. It's probably also a breaking change if a user now may have empty/null for both email address and username (which are the same now by default, right?).

Perhaps we should also look at the GUID. Right now the the user with ID -1 also seems to get the GUID ffffffff-0000-0000-0000-000000000000. So should this GUID follow the user in the migration, or should the existing user with -1 get a new GUID, and the system user then gets ffffffff-0000-0000-0000-000000000000? Since it's not a "real" GUID, I think it should be used for the system user.

Various actions may still be attributed to the system user if no actual user is specified, so the user may therefore also appear in the UI. How should this be visualized? Would "System" as the display name suffice? Should the system user have an avatar (default avatar would just be something like a grey circle with an "S" for System)? The avatar might help visualizing that the user is not a "real" user.

Example: For a client project where we automatically import content, those actions are attributed to a custom user with this avatar:

[callumbwhyte]

@abjerner If my understanding is correct, we're saying this "system" user will not be able to be authenticate and so won't be able to login or even be visible in the backoffice. As such, the avatar won't ever be seen.

[Shazwazza]

There's a few other things to consider

Create user -1, it doesn't exist now

... we cannot delete this because of referential integrity. so when we copy the values to a new user, the new user is created but this original user just remains and we can modify it.

With the proposed changes, this may break the ability to reset a locked out system, which is the only official supported way to get back into the CMS if you have totally lost all access, see tweet: https://twitter.com/Shazwazza/status/1141594930550206464 . Well actually this may not break this functionality, but it will mean that the system user will now have a password and a way to login.

Then, there are real checks in the codebase currently for user "-1", these checks need to be reviewed to see why they exist, if they are still needed and what the repercussions are. There's methods that are called IsSuper, there's checks in AdminTokenAuthorizeAttribute - which may not even be used for anything anymore and checks in the DashboardSecurity for this user... maybe more. Then we need to make sure this change doesn't affect anything with Deploy, Courier or Forms.

[nul800sebastiaan]

Oh man.. so yes.. I've missed a lot. ☹

Things always sound so easy, and then reality comes checking in. Really good points that people might already be relying on this user, and it will be hard to potentially move over permissions (and permissions for Deploy, Courier, Forms, etc.).

Then.. new proposal, which was the original proposal, with some learnings applied:

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.
You could probably even hook into events do that you can't re-enable the user (not sure if there's events for this, should be).