[GH-ISSUE #980] feature request: sych mesh device groups with trmm permissions

kerem commented

2026-03-02 02:17:32 +03:00

Owner

Originally created by @fts-tmassey on GitHub (Feb 18, 2022).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/980

Is your feature request related to a problem? Please describe.
Any person who has access to a browser that has even once controlled any PC via TRMM, or has a copy of a URL used to control any such PC, they can now control ALL PC's accessible to anyone within TRMM forever, simply by using that URL!

Describe the solution you'd like
A way to secure MC sessions to not allow unlimited access to 100% of MC PC's from anyone with a URL. In addition, limit what PC's users can control, so that it accurately reflects TRMM permissions, and that does not put static Full Admin credentials embedded in unprotected clear-text directly into the URL.

In the immediate-term: an option to tell TRMM to not use the login parameter and let the user log into MC directly through the iframe.

In the near-term: separate MC agents per client.

In the long-term: some sort of SSO or proper Mesh integration that does NOT push static, high-access credentials into the URL.

Describe alternatives you've considered
From my incomplete understanding, the issue revolves around the fact that TRMM uses a single, static set of login credentials to log all TRMM users into MC, and does so by pushing such credentials directly into the URL. This brings up two families of security issues:

The credentials are static and embedded in the URL. If someone were to copy and paste that URL, then literally anyone would be able to connect to that PC, whether they are a TRMM or MC user or not. If they can access the MC server, they can control the PC. And they can get that URL numerous ways, including simply searching the browser cache.
There is only a single set of MC credentials used within TRMM. That means that any PC's that need to be controlled by any TRMM user need to be accessible to that specific MC user. That also means that anyone who can get TRMM to generate a MC URL will be able to use that to gain access to any PC that is available within TRMM -- forever.

There are a few limitations that make solving this as an end-user impossible:

= Given that the credentials used by TRMM are static and clearly available right from the URL, the only credentials that can be put into TRMM can be ones that you would not mind anyone in the world using -- because if a URL slips out, whoever has that URL has the ability to log in as that user with zero barriers. This would include a terminated employee who simply keeps a copy of the URL. That means that the level of access that TRMM can safely use is effectively zero -- there is no mechanism to keep that connection safe and controlled.

= Even if the credentials are secured between TRMM and MC, and a simple clear-text cut and paste does not allow the credentials to be grabbed, we still need a way to select what PC's can and cannot be controlled. As long as the connection to MC allows the user browse the full dashboard, they will be able to connect to any of the PC's. Therefore, we need a way to be able to narrow the connection between TRMM and MC, based on the permissions available to the current TRMM user.

From my limited experience, I can think of a few ways that this could be addressed:

Do not have a single, static set of credentials between TRMM and MC. In fact, the easiest solution might be to simply not have the credentials at all. From my limited testing, if the "login=" parameter were not in the URL in the first place, we would not seem to have this problem at all: the user would be presented with a MC login the first time they attempt to connect to a PC, they could log in as a MC user (with the right permissions), and MC would handle its own permissions and security. The disadvantage to this is that you would need to maintain separate TRMM and MC users, and manage their permissions for each system separately. This is not ideal, but fortunately there tend not to be that many RMM technicians so this is not terrible -- and it's a million times better than the current wide-open hole.
Use a common SSO mechanism within MC and TRMM. That eliminates the duplication of credentials and yet keeps the security domains separate. But a lot more developer work -- and on both projects.
Allow MC credentials and agents to be stored per-client within TRMM, instead of a single global entry. This does not solve the static and url-based issues, but it does assist with controlling which PC's can be controlled by which technicians. At least with this, a technician who has access to a particular client within TRMM will only have access to a particular client within MC as well. Allowing separate agents is also important: it allows new clients to appear in the correct MC group automatically as well, which would greatly reduce the management burden of adding new computers in a safe and controlled manner. (Otherwise, they'll have to be dumped into a single group and an MC admin will have to move them around.)

Additional context

Thank you for reading all of this. I really appreciate your time and attention. It seems that this issue is not new to you; however, it does not seem that the ramifications of this issue have been described in detail before to us end-users. Having a system that allows anyone with access to a URL to have high-level access to the entire remote control system, including remote control of each and every system it's connected to does not seem ideal. I imagine that you could do tricks like only allowing access to MC from a central Terminal Server machine, or only allowing access via a VPN; but that's really just passing the buck. Having a system with a single, static credential is never a good idea.

Giving us a checkbox to stop using the login parameter would fix the hole. And if we could have a way to add MC agents to each client, that would at least give us the ability to make sure that we could manage who had access to what systems at the client level with very little administrative burden. If down the road we had tighter integration or SSO access, that would be wonderful; but in the interim, we would have safe and simple user management without too much effort.

Originally created by @fts-tmassey on GitHub (Feb 18, 2022). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/980 **Is your feature request related to a problem? Please describe.** Any person who has access to a browser that has even *once* controlled *any* PC via TRMM, or has a copy of a URL used to control any such PC, they can now control *ALL* PC's accessible to *anyone* within TRMM forever, simply by using that URL! **Describe the solution you'd like** A way to secure MC sessions to not allow unlimited access to 100% of MC PC's from anyone with a URL. In addition, limit what PC's users can control, so that it accurately reflects TRMM permissions, and that does not put static Full Admin credentials embedded in unprotected clear-text directly into the URL. In the immediate-term: an option to tell TRMM to *not* use the login parameter and let the user log into MC directly through the iframe. In the near-term: separate MC agents per client. In the long-term: some sort of SSO or proper Mesh integration that does *NOT* push static, high-access credentials into the URL. **Describe alternatives you've considered** From my incomplete understanding, the issue revolves around the fact that TRMM uses a single, static set of login credentials to log all TRMM users into MC, and does so by pushing such credentials directly into the URL. This brings up two families of security issues: 1) The credentials are static and embedded in the URL. If someone were to copy and paste that URL, then literally *anyone* would be able to connect to that PC, whether they are a TRMM or MC user or not. If they can access the MC server, they can control the PC. And they can get that URL numerous ways, including simply searching the browser cache. 2) There is only a single set of MC credentials used within TRMM. That means that any PC's that need to be controlled by any TRMM user need to be accessible to that specific MC user. That also means that anyone who can get TRMM to generate a MC URL will be able to use that to gain access to *any* PC that is available within TRMM -- forever. There are a few limitations that make solving this as an end-user impossible: = Given that the credentials used by TRMM are static and clearly available right from the URL, the only credentials that can be put into TRMM can be ones that you would not mind anyone in the world using -- because if a URL slips out, whoever has that URL has the ability to log in as that user with *zero* barriers. This would include a terminated employee who simply keeps a copy of the URL. That means that the level of access that TRMM can safely use is effectively zero -- there is no mechanism to keep that connection safe and controlled. = Even if the credentials are secured between TRMM and MC, and a simple clear-text cut and paste does not allow the credentials to be grabbed, we still need a way to select what PC's can and cannot be controlled. As long as the connection to MC allows the user browse the full dashboard, they will be able to connect to any of the PC's. Therefore, we need a way to be able to narrow the connection between TRMM and MC, based on the permissions available to the current TRMM user. From my limited experience, I can think of a few ways that this could be addressed: 1) Do not have a single, static set of credentials between TRMM and MC. In fact, the easiest solution might be to simply not have the credentials at all. From my limited testing, if the "login=" parameter were not in the URL in the first place, we would not seem to have this problem at all: the user would be presented with a MC login the first time they attempt to connect to a PC, they could log in as a MC user (with the right permissions), and MC would handle its own permissions and security. The disadvantage to this is that you would need to maintain separate TRMM and MC users, and manage their permissions for each system separately. This is not ideal, but fortunately there tend not to be that many RMM technicians so this is not terrible -- and it's a *million* times better than the current wide-open hole. 2) Use a common SSO mechanism within MC and TRMM. That eliminates the duplication of credentials and yet keeps the security domains separate. But a lot more developer work -- and on both projects. 3) Allow MC credentials and agents to be stored per-client within TRMM, instead of a single global entry. This does *not* solve the static and url-based issues, but it does assist with controlling which PC's can be controlled by which technicians. At least with this, a technician who has access to a particular client within TRMM will only have access to a particular client within MC as well. Allowing separate agents is also important: it allows *new* clients to appear in the correct MC group automatically as well, which would greatly reduce the management burden of adding new computers in a safe and controlled manner. (Otherwise, they'll have to be dumped into a single group and an MC admin will have to move them around.) **Additional context** Thank you for reading all of this. I really appreciate your time and attention. It seems that this issue is not new to you; however, it does not seem that the ramifications of this issue have been described in detail before to us end-users. Having a system that allows anyone with access to a URL to have high-level access to the entire remote control system, including remote control of each and every system it's connected to does not seem ideal. I imagine that you could do tricks like only allowing access to MC from a central Terminal Server machine, or only allowing access via a VPN; but that's really just passing the buck. Having a system with a single, static credential is never a good idea. Giving us a checkbox to stop using the login parameter would fix the hole. And if we could have a way to add MC agents to each client, that would at least give us the ability to make sure that we could manage who had access to what systems at the client level with very little administrative burden. If down the road we had tighter integration or SSO access, that would be wonderful; but in the interim, we would have safe and simple user management without too much effort.

kerem closed this issue

2026-03-02 02:17:32 +03:00

kerem commented

2026-03-02 02:17:33 +03:00

Author

Owner

@BMTTeam commented on GitHub (Feb 18, 2022):

"sych mesh device groups with trmm permissions" - if possible the user on the remote PC to see the TRMM user name (or even better - Display Name) connecting/asking to get access to the user PC. Now is that static MC account (randomly generated) and end users are reluctant to allow access (even while talking with the support engineer on the phone)

@BMTTeam commented on GitHub (Feb 18, 2022): "sych mesh device groups with trmm permissions" - if possible the user on the remote PC to see the TRMM user name (or even better - Display Name) connecting/asking to get access to the user PC. Now is that static MC account (randomly generated) and end users are reluctant to allow access (even while talking with the support engineer on the phone)

kerem commented

2026-03-02 02:17:33 +03:00

Author

Owner

@dinger1986 commented on GitHub (Feb 18, 2022):

@BMTTeam that is easily sorted, just change the "real name" in mesh

This is already open as a feature request #182 search is your friend :), I suggest closing this.

Mesh was setup this way prior to other options being available in mesh

@dinger1986 commented on GitHub (Feb 18, 2022): @BMTTeam that is easily sorted, just change the "real name" in mesh This is already open as a feature request #182 search is your friend :), I suggest closing this. Mesh was setup this way prior to other options being available in mesh

kerem commented

2026-03-02 02:17:33 +03:00

Author

Owner

@silversword411 commented on GitHub (Feb 18, 2022):

This is trmm permissions syncing to mesh permissions for sure. Closing, can reopen if needed.

@silversword411 commented on GitHub (Feb 18, 2022): This is trmm permissions syncing to mesh permissions for sure. Closing, can reopen if needed.

kerem commented

2026-03-02 02:17:33 +03:00

Author

Owner

@BMTTeam commented on GitHub (Feb 18, 2022):

@BMTTeam that is easily sorted, just change the "real name" in mesh

This is already open as a feature request #182 search is your friend :), I suggest closing this.

Mesh was setup this way prior to other options being available in mesh

Well no-brainer here about that but #182 is almost two years old request.

@BMTTeam commented on GitHub (Feb 18, 2022): > @BMTTeam that is easily sorted, just change the "real name" in mesh > > This is already open as a feature request #182 search is your friend :), I suggest closing this. > > Mesh was setup this way prior to other options being available in mesh Well no-brainer here about that but #182 is almost two years old request.

kerem commented

2026-03-02 02:17:33 +03:00

Author

Owner

@silversword411 commented on GitHub (Feb 18, 2022):

Well no-brainer here about that but #182 is almost two years old request.

PRs are always accepted, you don't have anything else to do this weekend do you? ;)

@silversword411 commented on GitHub (Feb 18, 2022): > Well no-brainer here about that but #182 is almost two years old request. PRs are always accepted, you don't have anything else to do this weekend do you? ;)

kerem commented

2026-03-02 02:17:33 +03:00

Author

Owner

@BMTTeam commented on GitHub (Feb 18, 2022):

Easy boy!

@BMTTeam commented on GitHub (Feb 18, 2022): Easy boy!

kerem commented

2026-03-02 02:17:34 +03:00

Author

Owner

@fts-tmassey commented on GitHub (Feb 18, 2022):

Mea Culpa: I was wrong -- one of my two big issues above are incorrect. Per the MeshCentral 2 Users Guide, the URL login token expires after an hour: either you need an updated login code from a new TRRM URL, or MC will renew the session cookie every 30 minutes in the background when you are connected. I'm glad to know that I'm the dumb one here, and not the programmers. :) I apologize for the confusion and overreaction -- I should have tested it further before I wrote that part up. (But that doesn't change the fact that there's still several security issues that comes from using a single user for all connections.)

However, I respectfully disagree about closing this request as part of 'sync TRMM and Mesh permissions'. Sure, that feature would be great, but I get it: that's a big chunk of code and like you said, PR's are welcome if I have a free weekend.

Which is why I would love to have the interim steps. First, a checkbox to allow the URL to be generated without the login parameter, and allowing/forcing the user to log into Mesh directly. That gives me 100% of the security, because Mesh provides 100% of the security without TRRM short-circuiting it. Of course, I could just skip using the integration at all and simply use Mesh directly. That's what I'll do if I have to, but when you have lots of systems spread across a number of clients (and departments that need to be run as clients), it's a hassle finding the stupid PC once, let alone twice in two different systems! :) The link right there is really handy...

Second, which would clearly take a bit more work but hopefully would be very similar to the existing code, would be to allow a different Mesh user and agent per client instead of a single global setting. That would allow us to stick with the single TRRM installer/link per client we already have, and yet the new agent appears in the correct TRRM and Mesh group automatically. Otherwise, we would either have to have all new agents appear in a generic TRRM Device Group in Mesh, and then have a Mesh admin (who is likely not the person installing the agent in the first place) move the PC to the correct Device Group. Or we have to install and manage the two agents separately instead of just one.

Now, if you simply don't want to do any of that, hey, it's your project! :) But I really do think that my request is materially different from 'sync TRRM and Mesh permissions'. Even if the permissions sync, there are reasons to have both of these features in addition. If you would prefer that I create a much cleaner and simpler request that doesn't include the incorrect security assumptions, I would be happy to. Otherwise, again, thank you for your time and attention.

@fts-tmassey commented on GitHub (Feb 18, 2022): Mea Culpa: I was wrong -- one of my two big issues above are incorrect. Per the MeshCentral 2 Users Guide, the URL login token expires after an hour: either you need an updated login code from a new TRRM URL, or MC will renew the session cookie every 30 minutes in the background when you are connected. I'm glad to know that I'm the dumb one here, and not the programmers. :) I apologize for the confusion and overreaction -- I should have tested it further before I wrote that part up. (But that doesn't change the fact that there's still several security issues that comes from using a single user for all connections.) However, I respectfully disagree about closing this request as part of 'sync TRMM and Mesh permissions'. Sure, that feature would be great, but I get it: that's a big chunk of code and like you said, PR's are welcome if I have a free weekend. Which is why I would love to have the interim steps. First, a checkbox to allow the URL to be generated without the login parameter, and allowing/forcing the user to log into Mesh directly. That gives me 100% of the security, because Mesh provides 100% of the security without TRRM short-circuiting it. Of course, I could just skip using the integration at all and simply use Mesh directly. That's what I'll do if I have to, but when you have lots of systems spread across a number of clients (and departments that need to be run as clients), it's a hassle finding the stupid PC once, let alone twice in two different systems! :) The link right there is *really* handy... Second, which would clearly take a bit more work but hopefully would be very similar to the existing code, would be to allow a different Mesh user and agent per client instead of a single global setting. That would allow us to stick with the single TRRM installer/link per client we already have, and yet the new agent appears in the correct TRRM *and* Mesh group automatically. Otherwise, we would either have to have all new agents appear in a generic TRRM Device Group in Mesh, and then have a Mesh admin (who is likely *not* the person installing the agent in the first place) move the PC to the correct Device Group. Or we have to install and manage the two agents separately instead of just one. Now, if you simply don't want to do any of that, hey, it's your project! :) But I really do think that my request is materially different from 'sync TRRM and Mesh permissions'. Even if the permissions sync, there are reasons to have both of these features in addition. If you would prefer that I create a much cleaner and simpler request that doesn't include the incorrect security assumptions, I would be happy to. Otherwise, again, thank you for your time and attention.

kerem commented

2026-03-02 02:17:34 +03:00

Author

Owner

@bbrendon commented on GitHub (Feb 19, 2022):

Its also a duplicate of this https://github.com/wh1te909/tacticalrmm/issues/618

@bbrendon commented on GitHub (Feb 19, 2022): Its also a duplicate of this https://github.com/wh1te909/tacticalrmm/issues/618

kerem commented

2026-03-02 02:17:34 +03:00

Author

Owner

@fts-tmassey commented on GitHub (Feb 19, 2022):

That's a better way of doing it: simply use a token key for each TRMM user instead of per-client. Very nice! (But it would still be really nice to have the Mesh agent per-client, even without the token.)

But until then, I'd very happily settle for just getting TRMM out of the login process so we can eliminate that single account issue.

@fts-tmassey commented on GitHub (Feb 19, 2022): That's a better way of doing it: simply use a token key for each TRMM user instead of per-client. Very nice! (But it would still be *really* nice to have the Mesh agent per-client, even without the token.) But until then, I'd very happily settle for just getting TRMM out of the login process so we can eliminate that single account issue.

kerem commented

2026-03-02 02:17:34 +03:00

Author

Owner

@fts-tmassey commented on GitHub (Feb 19, 2022):

You wanted a PR, so I created a PR: https://github.com/wh1te909/tacticalrmm/pull/981

Its a rough proof-of-concept that adds a check box in Global Settings/MESHCENTRAL that enables or disables the ability to automatically log into MeshCentral via the login= parameter of the URL. With the checkbox checked, everything works like it always has. With the checkbox unchecked, the login= parameter is not included when you click on Take Control.

This is of course not complete as-is -- I have zero experience with this codebase so I'm sure I've missed important implementation items. In addition, there are details that will certainly need to be improved. For example, if the auto login is disabled, there probably isn't a need to enter the Username or Mesh Token, but the user will get an error if they're not in place, and I did not dig far enough to find out why.

@fts-tmassey commented on GitHub (Feb 19, 2022): You wanted a PR, so I created a PR: https://github.com/wh1te909/tacticalrmm/pull/981 Its a rough proof-of-concept that adds a check box in Global Settings/MESHCENTRAL that enables or disables the ability to automatically log into MeshCentral via the login= parameter of the URL. With the checkbox checked, everything works like it always has. With the checkbox unchecked, the login= parameter is not included when you click on Take Control. This is of course not complete as-is -- I have zero experience with this codebase so I'm sure I've missed important implementation items. In addition, there are details that will certainly need to be improved. For example, if the auto login is disabled, there probably isn't a need to enter the Username or Mesh Token, but the user will get an error if they're not in place, and I did not dig far enough to find out why.

kerem referenced this issue

2026-03-02 02:24:18 +03:00

[PR #595] [MERGED] Initial Parameterization of System Report WIP Script #1679

kerem referenced this issue

2026-03-14 07:30:36 +03:00

[PR #595] [MERGED] Initial Parameterization of System Report WIP Script #3631

Rows
Columns

[GH-ISSUE #980] feature request: sych mesh device groups with trmm permissions #595