Cannot connect to MeshCentral: iframe is simply white (incorrect gotonode?)

[fts-tmassey]

Tactical RMM (TRMM) Server:
Ubuntu 20.04
Browser: Firefox 97.0
TRMM Version 0.11.3
Installation: Standard

External MeshCentral (MC) Server:
Ubuntu 20.04
MC Version 0.9.83

Agent Info:
Version: 1.8.0
MeshCentral Agent: 0.2.1.3 (as shown in MeshAgent.exe Properties)
Agent OS: Windows 10 Pro, 64 bit v21H2

Describe the bug
When I click on either Take Control or Actions/Remote Background, the iframe for the MeshCentral component is simply a white (empty) box.

To Reproduce
Log into TRMM
Select an agent
Click on Take Control
Get a new tab that contains the thin Agent Status header, but the MC iframe below is completely white. Same happens with Remote Background.

Expected behavior
I should get the MC remote control content in the iframe.

Screenshots
I will add if needed, but it's a white box... :)

Additional context
In digging into this, I looked at the URL for the iframe. The information is sanitized and reproduced here:

https://mc.example.com/?login=&gotonode=95BC0609AE7C1D04347BB4FBDF6618A03A16B5BB71BDCDD3C8E051242B07E9E1826739AFE7F8919843EFF54E9A4924B50&viewmode=11&hide=31

However, when I log into MC as the same user and open the page for that agent, here is the URL:

https://mc.example.com/?viewmode=10&gotonode=lbwGCa58HQQ0e7T732YYoDoWtbtxvc3TyOBRJCsH6eGCZzmv5$iRmEPv9U6aSSS1

I notice that the gotonode parameters are completely different. it seems that the TRMM URL might use a different form of encoding than the direct-from-MC example, so I'm not certain if they decode to the same thing or not; however, if I cut and paste the MC gotonode into the TRMM URL, it works correctly.

Is it possible that the TRMM agent is not using the correct ID for MC?

To attempt to diagnose this further, I have done the following, none of which changed anything:

= Searched for "MeshAgent.exe" on the entire client computer: the only one found was in "C:\Program Files\Mesh Agent"
= Uninstalled the TRMM agent from the client (using Add/Remove Programs)
= Confirmed that "C:\Program Files\TacticalAgent" and "C:\Program Files\Mesh Agent" were removed.
= Reinstalled the TRMM agent
= Attempted to use the "Take Control" function: no change.
= Repeated all of the above steps but using the "Remove Agent" action instead of manual uninstall.
= Used Actions/Agent Recovery/Mesh Agent
= Rebooted TRMM server
= Rebooted MC server

This is a new setup this week. Earlier in the week, the "Take Control" button worked fine, but sometime over the last few days it stopped. I do not recall making any configuration changes.

The MeshCentral User ID and Login token seem to be correct. If I were to browse "https://mc.example.com" directly, the MC dashboard opens, logged in as the MC user I put into TRMM. If I then log out from MC there and use TRRM to Take Control, I still get the white box, but if I browse "https://mc.example.com" again, I'm taken to the MC main dashboard no problem. So it seems to be logging in successfully.

(That leads to an unrelated concern: does this mean that my users will be able to bypass the user permissions controls in TRMM simply by connecting to a client they can connect to, then open MC directly to get access to everything that TRMM can manage?)

Please let me know what additional information or testing I can provide to you. Thank you very much!

[dinger1986]

So the agent is available in mesh and you can connect directly to it? Is this a standard install nothing fancy with proxy's etc?

Also yes it does mean you can get round the user controls in tactical using mesh

[fts-tmassey]

That is correct: the agent is available in Mesh, I can remote control, get a file list, etc. Everything is working 100% correctly in Mesh. Everything that is provided by the TRMM agent seems to be working 100% correctly as well: when I use the Remote Background action, I can use the Services tab and see services just fine; but the Terminal and File Browser tabs simply have a white iframe.

The agent PC is a completely standard Windows 10 PC. Because this is a test environment, I only have the agent on two PC's right now, and the problem happens with both. There are no proxy servers ,etc. involved. The servers are cloud-based VM's and the PC's are behind a Ubiquiti EdgeRouter X NAT firewall, with no outbound restrictions, etc.

---

ETA: I re-read your message about user controls: I originally read it as a question, and it seems you meant it as a statement. To rephrase what I think you are saying: it is a known issue that any TRMM user will have 100% total access to 100% of the PC's that the TRMM user in MC has access to, simply by browsing the MC URL. Assuming that this is the case, I will look and see if there is a security issue for that: that's not cool at all... :) The below text is kept for reference, but you don't need it:

As for the getting around controls part: I haven't investigated that yet, so I may be missing something, and I don't want to derail this issue. I was just really surprised that while trying to debug the iframe issue I browsed my bare MC URL and it took me directly into the MC dashboard as the unique Full Admin user I used for TRMM without me entering a user ID or password. To make sure there wasn't anything stale, I logged out of MC and reloaded the URL: I got the login prompt again. But once I used TRMM to try to connect to a client, if I go to the bare MC URL, I go right back into the dashboard as the TRMM user, with Full Admin rights.

If I can do that, can't anyone else who has access to TRMM, even if they've been limited within TRMM to only a single PC? And if so, can't they then control any PC that that Full Admin user has in MC? That would very much not be my intention: some of my TRMM users only have access to certain clients. But like I said, I have not fully investigated this. If you know that I'm missing something and can tell me in a sentence, great, I won't waste your time with a second issue. But if not, I will happily create a separate issue if I find out that I can use that to gain control over a PC that a given TRMM user should not be able to.

[dinger1986]

Did this used to work?

---

This has always been the case as mesh is used only for remote. You can use another remote viewer or give users direct access to a machine with mesh

[fts-tmassey]

It worked initially, yes. And then something changed, and it does not now work. To my knowledge, I made no changes, either to the agent PC's (the problem happens with multiple PC's), nor to either the TRMM server nor the MC server. I barely looked at the thing in the last couple of days, and like I said it's a new, test install so I'm the only one with access to it.

[dinger1986]

moved to discussion. Have you enabled mfa?

[fts-tmassey]

I have not enabled MFA on Mesh. MFA is enabled on TRMM as part of install, of course.

Is there a way to compare the ID that TRMM is using internally vs the one that the MC agent is using? I'm not sure if you saw the part where if I change the gotonode parameter it works fine.

[dinger1986]

yeah I dont know about that, I know that for most users it just works.

its rarely anything as technical as that. if its new rebuild I am sure itll work the second time

[fts-tmassey]

More digging. The URL as created by TRMM is incorrect.

The gotonode parameter in the URL used by MC is the base64-encoded Node ID. When decoded, it ends in: 9A 49 24 B5. If you look at the URL as used by TRMM, it is not encoded, and it ends in: 9A4924B50. Notice the extra zero at the end.

Sure enough, if I take the URL that the iframe is using and remove the trailing zero, it works correctly.

Now, if I run "C:\Program Files\Mesh Agent\MeshAgent.exe" -nodeid from the client's command line, I get:

95BC0609AE7C1D04347BB4FBDF6618A03A16B5BB71BDCDD3C8E051242B07E9E1826739AFE7F8919843EFF54E9A4924B5
0
(There's a newline between the end of the node ID and that trailing zero.)

I have no idea how you're getting the node ID and putting it in TRMM, but it seems that this extra zero has come along for the ride.

In my ignorance, I would suggest the possibility of using the registry key at [HKEY_LOCAL_MACHINE\SOFTWARE\Open Source\Mesh Agent] "NodeId" ? It has the base64-encoded ID that the Mesh Agent is using, and also has the advantage of matching what the Mesh URL uses, which would make it real obvious if the gotonode parameters match or not, without having to encode/decode them to see.

Maybe there's an obstacle to using that. But in any case, TRMM seems to be using the wrong URL.

I also confirmed this with a second TRRM agent PC: The Take Control iframe URL had an extra zero at the end of the gotonode parameter. Remove it, and the connection works fine.

[silversword411]

Are you using Firefox or chrome for this?

[wh1te909]

this is why in the docs we say do not update meshcentral on your own and let the update script handle it for you
the mesh version is pinned to the trmm version
i am already aware of this issue, it only happens in new mesh release and i already have a ticket open to fix it
Ylianst/MeshCentral#3656
if you use the version of meshcentral that tactical installs you won't have this issue

[fts-tmassey]

Thank you. I look forward to an update in the future. As I described initially, this is an external Mesh server, so updating Mesh with the TRMM script is not practical. What is odd is that I intentionally did not update Mesh since the initial integration, when it actually worked! Of course, it is also a brand new Mesh server, and I didn't have a specific version of Mesh to initially install, either, which is how I got ahead.

Looking at the update script, it seems it pulls the desired Mesh version from https://raw.githubusercontent.com/wh1te909/tacticalrmm/master/api/tacticalrmm/tacticalrmm/settings.py so I will keep an eye out there and keep my Mesh in sync with what is expected.

Thank you for your help.

[reduakt]

Same issue here. White frames in case of "Take Control" or "Remote Background". The Header is displayed fine. But the frame, which should display the meshcentral content, is empty. I checked the url and the /?gotonode=& value is empty in my case. Managing the devices via meshcentral website directly is working flawlessly.

My meshcentral is version 1.1.4. This value comes from the settings.py during install.sh or upgrade.sh script. TRMM Server is version v0.15.9.

I did not change my meshcentral version manually.

[dinger1986]

is this for all devices?

You havent changed the group name, username, mesh settings in Global Settings?

Have you ran the check_mesh command to see if its working correctly? https://docs.tacticalrmm.com/troubleshooting/#agents-not-installing-or-updating

[reduakt]

Yes, every device. no changes in Global Settings. check_mesh command is fine, too.

I checked 'Disable Auto Login for Remote Control and Remote background'. Now i can see the login screen from MeshCentral. As soon as I log in, the white frame is shown and it's url has no value for `gotonode´.

[wh1te909]

@reduakt can u manually run this from an elevated cmd prompt on the agent (from C:\Program Files\TacticalAgent directory):
tacticalrmm.exe -m recovermesh -log debug -logto stdout

want to see if it's getting the mesh node id, you should see something like this in the output

BODY   :
{
   "func": "syncmesh",
   "agent_id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
   "nodeid": "E5316407441D22D49CFDFD41649A73E905CC9162F1E1FC1F684A2E099A5F9EB4235DB4C35F77A7FF1C525D175D786019"
}

[reduakt]

Thanks a lot for the hint. I was able to identify my Problem.

Running tacticalrmm -m recovermesh -log debug -logto stdout returned the following lines:

[....]
DEBU[0000] /opt/tacicalmesh/meshagent does not exist. Skipping
[...]
BODY   :
{
   "func": "syncmesh",
   "agent_id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
   "nodeid": ""
}

I identified my Problem under Linux:
I installed the tacticalagent and meshagent binaries to a different location, but their paths are hard coded in agent.go from rmmagent repo. Since my meshagent was stored in different location, the tacticalagent binary was not able to call it in order to fetch the nodeid.

Creating symlinks to $PATH could be a solution, so the binaries can find each other. A second idea could be to store both binaries in the same folder, so the location does not need to be hard coded and the CWD can be used. Both scenarios need a reworked installation bash script, too.

I can now fix my Problem. Thanks for your help!