Feature Request: A mesh user per Tactical RMM user

[TnTBass]

What looks to be happening currently is that there is a single mesh user created and used for all TacticalRMM users.

This presents a bit of a challenge when notifications or consent is turned on in mesh. Instead of seeing "TnT has connected" the end users see "mesh has connected", no matter which Tactical RMM user actually connected to the endpoint.

Instead, I would like to see a mesh user per Tactical RMM user, so this kind of notification and any additional auditing can be clear and straight forward.

[johnnyq]

+1

This should also apply to client when a client is created it should create a group under mesh central with that client name and all managed computers should be added to that group.

Tactical User <------------> MeshCentral User Tactical Client <-----------> MeshCentral Group Tactical Client Site <-----> MeshCentral Group { CLIENT NAME - SITE }

[johnnyq]

@wh1te909 Would something like this make sense to implement and would it be difficult to implement.

[technoicon]

Hi,

I think this is a decent idea. I would suggest this though:

Tactical User <------------> MeshCentral User Tactical Client <-----------> MeshCentral Group Tactical Client Site <-----> MeshCentral Tag

The tags don't show in MeshCentral Router would be nice if they did. I might put a feature request in mesh central for this.

[johnnyq]

@technoicon thats even better!

I was thinking last night about another scenario. You may want some devices in mesh central that are not in tactical for example a linux and mac client. So maybe an option could be to add a tag tacticalrmm to the devices that are in tacticalrmm.

There also needs to be sync method when client/device/site is renamed in tactical it should be renamed in meshcentral and vice versa

[dinger1986]

I have 2 groups in mesh, 1 which is tactical rmm and I largely ignore it and the other is Others for Linux and some old macs or windows computers for customers we aren't moving into the RMM mainly home users.

I don't see why you would need more users? Although you can create them easily enough in mesh and give them control. Notifications can be setup as well so it shows the company name etc.

Separate groups etc seems a lot of work when at the moment it works pretty well using ids etc is there even an api or something for mesh so that can be written to it? Otherwise it's writing right to the DB and that's a pain!

[technoicon]

I would assume the users could then be given permissions? or only allowed access to certain machines in the future? I'm also no so concerned about users but rather the groups part of this request.

Some people just use mesh router and having mesh groups link with tactical groups would be ideal for that.

[dinger1986]

I guess once tactical is permissions based then the argument for the integration to mesh would follow as it would be pointless having one and not the other.

[fts-tmassey]

After update to 0.12.2, I just used the PR in Issue https://github.com/amidaware/tacticalrmm/pull/981 to add the ability to allow/force the user to log into Mesh: with very few obvious changes it works just fine.

Why do I want this? Because this very tiny feature allows Mesh to manage permissions 100% correctly, with zero participation from TRMM. This significantly improves the security, with very little effort. This allows you to limit which systems a tech can control -- not all techs are created equal...

This feature by itself is very useful. But it is made even more useful and transparent with one addition: moving the devices within Mesh into separate groups. Right now, I do this manually within Mesh and it works correctly. It would be very nice to have a little bit of help from TRMM on this: if we could store the mesh_device_group per site in addition to a single global entry, then there would be zero manual work to get 100% permissions management even when new systems are added!

I started to create a proof of concept PR. I got to the point where mesh_device_group is properly created and stored in the site, such that the existing core setting could serve as a system default, so you can simply ignore this feature if you won't use it. But when I dug into how the mesh installer is downloaded to the agent during install, it seems to me that it doesn't give TRMM any kind of site ID, so it can't know what site to get the info from.

I've got ideas on how to get around that (similar to arch, create an optional "siteID" parameter: if it's supplied, see if there's a non-NULL site.mesh_device_group, otherwise use core.mesh_device_group), but there's zero chance that anything that I do in this regard is going to be remotely acceptable, so creating a proof-of-concept PR probably isn't worth the effort. However, if you really want to see the pieces I have, I'm more than happy to push them into a PR -- even if it's just for a laugh... :)

But, please consider adding these two small and straightforward features. The very simple checkbox to allow/force techs to have to log into mesh (so that each tech can have their own permissions instead of a single system-wide default) and allow a site-specific mesh_device_group to override the system default so that the installer can download the site-specific mesh installer (so that new devices get added to the correct Mesh group and therefore set with the correct permissions automatically).

Again, thank you very much for your time and attention.

[silversword411]

@fts-tmassey

If I read your post correctly, your #981 PR breaks all mesh integration, forcing users (one or all) to have double-logins to use TRMM. Yes, this allows you to manually force mesh login per managed user so there isn't a permission bypass which currently exists.

Your proposal is a kludge, and redundant work when the proper fix is:

• Sync trmm users to mesh users
• Sync sites to groups to sync permissions
• Establish permission synchronization between the two.

This is planned, but farther down on the todo list (v.12 did get some mesh integrations, like auto-install building, and I think there was something else so a tighter integration process has been started).

If you can get a properly implemented sync in a PR, then it will most likely be accepted.

If you're just breaking all automatic mesh integration for everyone making TRMM daily use worse, it will most likely not be integrated. If you have something to commit, definitely do...maybe something you post can be used in a properly implemented final fix.

[fts-tmassey]

You do not read it correctly. My suggestion makes exactly one functional change: removes the "login" parameter from the remote control URL. This gives the tech a Mesh login prompt the first time they do a remote control, and only then. They then log in as a personal Mesh user. Once they login, everything works exactly like it did before. Absolutely no integration is broken.

What is the point of this change? With this change, we go from having all techs use a single super-user Mesh account (and therefore with zero ability to secure Mesh on a per-tech basis) to having each tech use their own Mesh account, and therefore with the ability to secure each tech individually.

Because remember: with the current technique, all the tech has to do is open the standard Mesh interface directly with their browser after controlling a single PC: they can now control any PC. By using their own Mesh credentials instead of the auto-logged-in super-user, they can't. That's a LOT of security to give up just to "free" the tech from having to log in to Mesh one time.

Is this a kludge? I won't argue. Is it redundant if you had a perfectly-functioning TRMM permission and sync system? Sure. But my suggestion/PR is a dozen lines of code that make one very small change (literally add an additional global settings checkbox and an if statement in generating the URL to remove the login parameter). It can be done very simply and it won't change the default configuration at all unless you change that checkbox. How long will it take to create the "proper" sync and permission system? And during that time, it's not possible to limit who can control what machines.

Think of it this way: TRMM sees the need to manage which techs can see or manage which clients within its own system. This took effort to create this, but it was seen as valuable. I would think that it would be straightforward to imagine that we would want that same level of management for controlling remote access to devices in Mesh. And in fact, Mesh has the same sort of management concept. But using a single login in Mesh makes it impossible to actually use the Mesh system. As long as TRMM allows (actually forces!) all techs to use a single login, it will be impossible to control access to Mesh devices.

To address this, it will be essential to stop TRMM from pushing all Mesh connections into a single user account. That is exactly what my PR does. It's a 95% solution that greatly improves privacy and security. The only kludge is that an extra settings checkbox gets added that might be able to be removed when there's a full sync in the future. The actual code change is vanishingly small.

At this point, I'm more surprised that the developers don't see this as a security issue than the fact that nobody likes my PR. It's impossible to prevent a tech from controlling 100% of the devices in the system. I'm glad that you have a collection of techs that you can trust 100% and have no problem with giving them 100% access. I do not. In my experience, some techs have a tendency to over-reach their understanding or abilities and need to be contained. A tech who works on an "I can't print" ticket is not necessarily one who should also be able to mess with critical servers. And some customers wish to control who has access to sensitive or private machines -- the CEO's laptop, for example. These are both impossible to do with the current TRMM configuration.

ETA: By the way, I'm not married to my solution in any way. I'd love a much more complete and feature-rich solution. But waiting for such a complete solution is a problem that makes TRMM unusable beyond an environment with only a single tech or two -- it can only be used when you trust 100% of your techs to have access to 100% of your controlled systems.

[fts-tmassey]

Thank you very much for reading all of this. I really do appreciate your time and attention. I'm actively trying not to argue while writing all of this. It seemed to me that you might have misunderstood what I'm asking for, why I think there is an actual security issue involved, and just how small a change (both in code and in tech experience) it would take to fix this issue. That's why I've written so much here, which might just be repetitive. It isn't because I want to fight about it, but I do want to make sure that there is no confusion about it.

If the developers understand and acknowledge that, yes, all techs clearly and trivially do have remote access to 100% of the systems in the entire system, that there is no way to avoid this at this time, and it is an acceptable solution to leave it this way for the foreseeable future, I won't argue. If that fits their use case, I envy them: their techs must all be great. That's not sarcasm: I wish I could have 15 techs I could trust like that to stay in their lanes. Sadly, I do not: I absolutely need the ability to control who can see and control what remote devices.

[silversword411]

Well...there's a bug in v0.12.3, so you could update right now, get your no auto-login for now. ;)

I understand why you're asking. Yes, currently mesh with auto-login is a bypass of all the security permissions/restrictions setup in TRMM. Yes, it is not intended to be this way forever, but dev time is scarce...and it's being spent elsewhere atm.

If you're interested in financing an accelerated dev timeline on mesh permission sync send an email to help@amidaware.com requesting such and they'll get back to you with an estimate.

[fts-tmassey]

Thank you very much for the clear and straightforward reply. If you can write "currently mesh with auto-login is a bypass of all the security permissions/restrictions setup in TRMM" with a straight face, especially when there is a simple way to prevent this with very minimal impact...

From what I can tell, @silversword411 's role seems to be as gatekeeper to the developers -- a tough job to be sure. I can't see if there is a formal relationship between you and the most visible developer, @wh1te909 , or @amidaware or such. Nor do I necessarily need to know, but because of this vagueness, I'm tagging @wh1te909 on this reply to make sure someone I can identify as a developer is aware of @silversword411 's assessment. I don't need or expect any kind of reply, but I don't want to simply assume silence is agreement. Beyond that, I am now satisfied that my point is understood and therefore will no longer engage on this point unless asked to.

This really isn't about this specific issue. If it were, I would simply patch the code: I literally just have to remove "login={token}&" from lines 229-231 of api/tacticalrmm/agents/views.py and be done with it -- I don't need it to be configurable... :) Easy peasy, still 100% integrated with virtually zero side-effect -- the tech logs into Mesh once and everything is perfect from there.

The larger issue for me is how the project itself views its relationship to security. Once you state, as you do in your comment, that you truly understand that this allows a tech to bypasses all security by opening a single, simple and obvious URL, I now have a better understanding of the role that this aspect of security holds within the project. You might feel that this is only allowing techs higher level of access (which is true) and is therefore acceptable. You have the right to that position -- but then what was the value of using precious developer time to build out all that other tech-facing security in the first place?

Once again, truly, thank you very much for your reply. That is exactly what I was looking for: a clear, unambiguous acknowledgement of the current situation. I have exactly the information I was looking for, even if it wasn't the answer I would have liked.

[silversword411]

Yes, I keep devs from wasting time on replies to asked/answered questions and other community interactions so they can focus their time on coding for the benefit of all in the community.

Permissions is a new feature only 6 months old: https://github.com/amidaware/tacticalrmm/releases/tag/v0.9.0 and statements like:

The larger issue for me is how the project itself views its relationship to security.

are FUD.

Tactical is still pre v1.0 software, and the per client/site permissions feature enhancement isn't completed yet.

Tighter mesh integration is progressing here, feel free to add PRs to this repo in the furthering of this goal: https://github.com/amidaware/meshctrl

You can work on integrating with mesh by parsing this appropriately, a ported version of this to python will allow quicker mesh permission integration: https://github.com/Ylianst/MeshCentral/blob/master/meshctrl.js

We appreciate constructive participation.

[sadnub]

@fts-tmassey You can get the functionality you want by changing a character in the mesh login token, so that it is incorrect. Efforts are being made to create a tighter mesh central integration to support various login methods, even user-based token sign-in with totp token generated. I am almost done porting Mesh's meshctrl library to python.

Mesh doesn't have a very straight forward API since it relies on websockets and some data manipulation to actually get things to work, but the plan is to (at some point):

• map trmm sites to meshgroups
• map users to mesh users and hopefully be able to supply a username to the logintoken so they get the correct permissions
• sync site/client permissions to mesh

I hope this answers your question and please test the workaround. I just tried on my setup and it appears to work. It will even keep you signed in so that going to remote control again doesn't prompt another sign in.

[MiM-TMassey]

I don’t have a TRMM system handy to test, but won’t that break all Mesh use by TRMM? The agents download the Mesh agent from TRMM, and TRMM gets it dynamically from Mesh, and that requires a token. That means the TRMM agent install won’t be able to deploy the Mesh client.

There is no problem with TRMM having such a powerful Mesh login — but not to expose it to the outside world, or to channel multiple users through a single set of permissions.

Maybe I’m mistaken or misunderstand what you’re saying, and if so I apologize. In either case, there is already a straightforward workaround documented above that sufficiently addresses this specific issue.

[sadnub]

@MiM-TMassey You are right. I forgot we recently changed a few things like getting the mesh exe automatically and this depends on the login token.

I just added the "disable autologin for take control and remote background" option in the Mesh Central configuration in TRMM. https://github.com/amidaware/tacticalrmm/commit/b5e3b16e3a5c2e6cfa0bf788e592676f5ab94e76

Will be in the next release

[ninjamonkey198206]

I tried reading through some of these and got lost... I'm tired.

Not sure if I need to add a new request or expand on this one.

What I'd like to see is at least the logged in T-RMM user passed through to the messages the remote client sees from Mesh.

Being told that Tactical is sharing your screen makes some clients nervous. They usually like to know who is actively using their system, write it down, something.

Clients are twitchy anyway, no need to spook them further. They're like horses, you have to be calm, clear, and non-threatening or they're likely to hurt their equipment or themselves.

[dinger1986]

What I'd like to see is at least the logged in T-RMM user passed through to the messages the remote client sees from Mesh.

Can you not just change the "real" name on mesh to something the customer recognises? We can catch up on discord and see if this is an issue.

[styx-tdo]

Well...there's a bug in v0.12.3, so you could update right now, get your no auto-login for now. ;)

I understand why you're asking. Yes, currently mesh with auto-login is a bypass of all the security permissions/restrictions setup in TRMM. Yes, it is not intended to be this way forever, but dev time is scarce...and it's being spent elsewhere atm.

If you're interested in financing an accelerated dev timeline on mesh permission sync send an email to help@amidaware.com requesting such and they'll get back to you with an estimate.

No, actually, they told me it looks like I am planning to resell TRMM, breaking the license. They didn't send an estimate. Just my experience, tho. Took them 2 months to tell that, too, then going dark.

[wh1te909]

Released in v0.18.0 check out the video to see the how it works.