[GH-ISSUE #204] Prevent the initial admin user from being deleted #124

Closed
opened 2026-03-02 02:13:45 +03:00 by kerem · 4 comments
Owner

Originally created by @luminous706 on GitHub (Dec 13, 2020).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/204

It seems that anyone can add/delete any user, so if I share access to Tactical RMM to a colleague, he can remove my access then I would be locked out.

It would be great if the first user created from the setup script was the official admin user and was greyed out, unable to be removed. Similar to the root user on Linux. If I give access to somebody, I can be sure that I will never be locked out, as I'm the primary maintainer of the tool.

Is there a way to achieve that right now?

Originally created by @luminous706 on GitHub (Dec 13, 2020). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/204 It seems that anyone can add/delete any user, so if I share access to Tactical RMM to a colleague, he can remove my access then I would be locked out. It would be great if the first user created from the setup script was the official admin user and was greyed out, unable to be removed. Similar to the root user on Linux. If I give access to somebody, I can be sure that I will never be locked out, as I'm the primary maintainer of the tool. Is there a way to achieve that right now?
kerem 2026-03-02 02:13:45 +03:00
Author
Owner

@wh1te909 commented on GitHub (Dec 14, 2020):

good request, we can add this in the next major release
for now you can test it out by just changing the code, try this out

edit /rmm/api/tacticalrmm/accounts/views.py and look for the class GetUpdateDeleteUser(APIView): class

in the delete method, change the code to the following, and then sudo systemctl restart rmm and then login as a secondary user and try to delete yourself

def delete(self, request, pk):
        root_user = User.objects.first()
        user = get_object_or_404(User, pk=pk)
        if user == root_user:
            return notify_error("The initial user cannot be deleted from the UI")

        get_object_or_404(User, pk=pk).delete()

        return Response("ok")
<!-- gh-comment-id:744107370 --> @wh1te909 commented on GitHub (Dec 14, 2020): good request, we can add this in the next major release for now you can test it out by just changing the code, try this out edit `/rmm/api/tacticalrmm/accounts/views.py` and look for the `class GetUpdateDeleteUser(APIView):` class in the `delete` method, change the code to the following, and then `sudo systemctl restart rmm` and then login as a secondary user and try to delete yourself ``` def delete(self, request, pk): root_user = User.objects.first() user = get_object_or_404(User, pk=pk) if user == root_user: return notify_error("The initial user cannot be deleted from the UI") get_object_or_404(User, pk=pk).delete() return Response("ok") ```
Author
Owner

@luminous706 commented on GitHub (Dec 14, 2020):

Thanks for the quick response!

The code did not work but gave me a way to modify it enough to make me happy:

def delete(self, request, pk):
        user = get_object_or_404(User, pk=pk)

        if user.username == "myAdminUser":
            return notify_error("The initial user cannot be deleted from the UI")

        get_object_or_404(User, pk=pk).delete()

        return Response("ok")

For a more future-proof implementation, it should be whatever first user created from the setup script.

But since someone might create a silly initial name or one with a typo, maybe an even more stable implementation would be to create a user automatically, call it "rmmadmin", "tactical", or something else, and just prompt for a password from the user. That "rmmadmin" or "tactical" user can't be removed or disabled from the GUI, unless we have back-end access.

This could be a good way to introduce some permission levels while we wait for the full-featured release with users and groups (1 user that cannot be deleted, a super-user, to manage the other users if anything goes wrong).

Btw, can I ask if you have a Patreon or a way to support this project? My company is really impressed.

<!-- gh-comment-id:744143207 --> @luminous706 commented on GitHub (Dec 14, 2020): Thanks for the quick response! The code did not work but gave me a way to modify it enough to make me happy: ``` def delete(self, request, pk): user = get_object_or_404(User, pk=pk) if user.username == "myAdminUser": return notify_error("The initial user cannot be deleted from the UI") get_object_or_404(User, pk=pk).delete() return Response("ok") ``` For a more future-proof implementation, it should be whatever first user created from the setup script. But since someone might create a silly initial name or one with a typo, maybe an even more stable implementation would be to create a user automatically, call it "rmmadmin", "tactical", or something else, and just prompt for a password from the user. That "rmmadmin" or "tactical" user can't be removed or disabled from the GUI, unless we have back-end access. This could be a good way to introduce some permission levels while we wait for the full-featured release with users and groups (1 user that cannot be deleted, a super-user, to manage the other users if anything goes wrong). Btw, can I ask if you have a Patreon or a way to support this project? My company is really impressed.
Author
Owner

@wh1te909 commented on GitHub (Dec 14, 2020):

Did you delete the initial user from django admin or some other way? Cuz User.objects.first() will always get the oldest entry in the database which unless you have deleted it will be the user created during install.

But anyway what i'll do is add an optional setting in /rmm/api/tacticalrmm/tacticalrmm/local_settings.py called ROOT_USER or something. So you would have to add ROOT_USER = "myAdminUser" at the bottom of that file. Then the code will check to see if that variable is set in that file, and if so the functions will not delete or modify anything with that username. This file is the only file that won't be overwritten during upgrades, any other python code you change will be.

No Patreon but have added a sponsor button on the projects page :)

<!-- gh-comment-id:744628286 --> @wh1te909 commented on GitHub (Dec 14, 2020): Did you delete the initial user from django admin or some other way? Cuz `User.objects.first()` will always get the oldest entry in the database which unless you have deleted it will be the user created during install. But anyway what i'll do is add an optional setting in `/rmm/api/tacticalrmm/tacticalrmm/local_settings.py` called `ROOT_USER` or something. So you would have to add `ROOT_USER = "myAdminUser"` at the bottom of that file. Then the code will check to see if that variable is set in that file, and if so the functions will not delete or modify anything with that username. This file is the only file that won't be overwritten during upgrades, any other python code you change will be. No Patreon but have added a sponsor button on the projects page :)
Author
Owner

@wh1te909 commented on GitHub (Dec 16, 2020):

Added in release v0.2.17
Edit /rmm/api/tacticalrmm/tacticalrmm/local_settings.py
and add the following line to the bottom of the file, replace username with your own
ROOT_USER = "tactical"
then sudo systemctl restart rmm

<!-- gh-comment-id:745691623 --> @wh1te909 commented on GitHub (Dec 16, 2020): Added in release v0.2.17 Edit `/rmm/api/tacticalrmm/tacticalrmm/local_settings.py` and add the following line to the bottom of the file, replace username with your own `ROOT_USER = "tactical"` then `sudo systemctl restart rmm`
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/tacticalrmm#124
No description provided.