[GH-ISSUE #1679] Security Policy of disabling inactive accounts or ones that have not enrolled 2FA yet automatically. + MeshCentral user isolation intergation. #2994

New issue

Open

opened 2026-03-14 06:10:43 +03:00 by kerem · 0 comments

kerem commented

2026-03-14 06:10:43 +03:00

Owner

Originally created by @n3ptune-cpu on GitHub (Nov 14, 2023).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1679

The reason for this request

Recently, a friend of mine who had access to my RMM, noticed something quite odd. They noticed that a user account had been created out of the blue without their notice. We looked into logs and had discovered that a user account had not yet setup 2FA or logged in a while had recently logged in and executed a few scripts onto the system. It appears that someone had managed to find the password of that account and had basically logged in and set up 2FA for themselves only to find machines to exploit on. We think that the account had been brute forced, which could be how they had managed to access the unused account, knowing that there is no attempt limit.

Describe the solution you'd like

A solution that could be done to issue this issue is to have accounts expiring and be disabled until they log in again. This could be after a set amount of period, the account gets disabled due to no recent logins and thus once logging in, requires a password change to access the RMM. Another thing that can be done is that if the user has an account created but has not logged in and setup 2FA for a while, the account gets disabled until the user requests for it to be enabled again and so they can once again set 2FA up for their account. As well as this, feature that could temporarily lock out an account if there are too many incorrect attempts, to prevent brute forcing.

Describe alternatives you've considered

All though proper permissions and consideration on the security of the RMM has to be focused on by the user, I also feel like there should be a feature of having MeshCentral accounts isolated with in the RMM to further enhance the permission system. This is because an account with MeshCentral access enabled can easily access all the systems as it uses the same account for everything that is in the Tactical RMM group. This defeats the purpose of permissioning agents and clients as it is very easy to access them all from Mesh. The only way to prevent this is to disable access to MeshCentral and create accounts solely to use Mesh alone.

Additional context

Context for what has been described above:

The commands being ran by an external user who is not supposed to have access.

The random account appearing on the login screen which was created from RMM as seen above.

The account that has not logged in after a while.

Separate accounts and groups are created on Mesh to allow isolation but no integration with RMM.

Originally created by @n3ptune-cpu on GitHub (Nov 14, 2023). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1679 ### ***The reason for this request*** Recently, a friend of mine who had access to my RMM, noticed something quite odd. They noticed that a user account had been created out of the blue without their notice. We looked into logs and had discovered that a user account had not yet setup 2FA or logged in a while had *recently* logged in and executed a few scripts onto the system. It appears that someone had managed to find the password of that account and had basically logged in and set up 2FA for themselves only to find machines to exploit on. We think that the account had been brute forced, which could be how they had managed to access the unused account, knowing that there is no attempt limit. ### **Describe the solution you'd like** A solution that could be done to issue this issue is to have accounts expiring and be disabled until they log in again. This could be after a set amount of period, the account gets disabled due to no recent logins and thus once logging in, requires a password change to access the RMM. Another thing that can be done is that if the user has an account created but has not logged in and setup 2FA for a while, the account gets disabled until the user requests for it to be enabled again and so they can once again set 2FA up for their account. As well as this, feature that could temporarily lock out an account if there are too many incorrect attempts, to prevent brute forcing. ### **Describe alternatives you've considered** All though proper permissions and consideration on the security of the RMM has to be focused on by the user, I also feel like there should be a feature of having MeshCentral accounts isolated with in the RMM to further enhance the permission system. This is because an account with MeshCentral access enabled can easily access all the systems as it uses the same account for everything that is in the Tactical RMM group. This defeats the purpose of permissioning agents and clients as it is very easy to access them all from Mesh. The only way to prevent this is to disable access to MeshCentral and create accounts solely to use Mesh alone. ### **Additional context** Context for what has been described above: ![image](https://github.com/amidaware/tacticalrmm/assets/52294084/74865366-d82f-4b92-a1d1-a2488bf37c16) The commands being ran by an external user who is not supposed to have access. ![image](https://github.com/amidaware/tacticalrmm/assets/52294084/374e28de-acea-452b-92a5-2424cfcbcfa4) The random account appearing on the login screen which was created from RMM as seen above. ![image](https://github.com/amidaware/tacticalrmm/assets/52294084/c397f633-aa56-49f2-9e1e-ffafe7731654) The account that has not logged in after a while. ![image](https://github.com/amidaware/tacticalrmm/assets/52294084/aa650660-d580-4add-a43f-1846b903e2d7) Separate accounts and groups are created on Mesh to allow isolation but no integration with RMM.