mirror of
https://github.com/amidaware/tacticalrmm.git
synced 2026-04-26 23:15:57 +03:00
[GH-ISSUE #987] External Mesh usage brings just login-screen #598
Labels
No labels
In Process
bug
bug
dev-triage
documentation
duplicate
enhancement
fixed
good first issue
help wanted
integration
invalid
pull-request
question
requires agent update
security
ui tweak
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/tacticalrmm#598
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @JSuenram on GitHub (Feb 24, 2022).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/987
Latest MC Version
0.9.89 used
Debug-Mode in MC bring:
COOKIE: ERR: Bad AESGCM cookie due to exception: Error: Unsupported state or unable to authenticate data
COOKIE: Decoded AESSHA cookie: {"a":3,"u":"user//j.suenram","time":1645728156000,"dtime":329}
WEB: handleRootRequestEx: cookie auth ok.
Installation Method:
Agent Info (please complete the following information):
latest
Describe the bug
Instead of remote-control in MC-Window, Logon-Screen is shown.
To Reproduce
Use latest MC-Version on external Installation.
Expected behavior
Remote-Control of selected Agent
@dinger1986 commented on GitHub (Feb 24, 2022):
So you have updated to the newest mesh?
@JSuenram commented on GitHub (Feb 24, 2022):
Sure, as taking part in active development of MC we have to be on the latest version.
Also testing the integration of TRMM as we used to use both in conjunction but always on separate Installations.
@dinger1986 commented on GitHub (Feb 24, 2022):
New versions are tested by the team prior to it being available in the upgrade script, I would suggest reverting to the latest stable version
@JSuenram commented on GitHub (Feb 24, 2022):
I am pretty sure it would work, this is just to be treated as info that there is an issue which might be taken care of.
We can workaround this no problem.
@wh1te909 commented on GitHub (Feb 24, 2022):
i have just upgraded to 0.9.89 but unable to reproduce, login still works. however mesh is installed on same server as trmm.
can you share your config.json and also on your server hosting mesh please run
node /meshcentral/node_modules/meshcentral --logintokenkey(change to whatever path your meshcentral is installed at) and compare that token key with what appears in tactical's web ui in Settings > Global Settings > Meshcentral@JSuenram commented on GitHub (Feb 24, 2022):
Maybe it is due to the fact, we are using LDAP-Authentication in MeshCentral....
Token is correct and identical in TRMM.
config.json is adapted from install.sh except more customization but nothing special.
{
"$schema": "http://info.meshcentral.com/downloads/meshcentral-config-schema.json",
"comment1": "This is a simple configuration file, all values and sections that start with underscore (_) are ignored. Edit a section and remove the _ in front of the name. Refer to the user's guide for details.",
"comment2": "See node_modules/meshcentral/sample-config-advanced.json for a more advanced example.",
"settings": {
"cert": "some_cert",
"_WANonly": true,
"_LANonly": true,
"sessionKey": "SomeKey",
"port": 443,
"aliasPort": 443,
"redirPort": 80,
"redirAliasPort": 80,
"agentsInRam": true,
"trustedproxy": "10.255.192.1",
"desktopMultiplex": true,
"authlog": "/etc/meshcentral/auth.log",
"plugins": true,
"WebRTC": false,
"compression": true,
"wsCompression": true,
"agentWsCompression": true,
"AllowLoginToken": true,
"AllowFraming": true,
"webrtcConfig": {
"iceServers": [
{ "urls": "stun:stun.services.mozilla.com" },
{ "urls": "stun:stun.l.google.com:19302" }
]
},
"mysqlDumpPath": "/etc/meshcentral/meshcentral-backup",
"mySQL": {
"host": "SOME_SERVER",
"port": "3306",
"user": "SomeUser",
"password": "somePASS",
"database": "meshcentral"
}
},
"domains": {
"": {
"titlehtml": "",
"title": "Remotesupport",
"title2": " - RemoteSupportTool - V 0.01a",
"titlepicture": "title-mycompany.png",
"welcomeText": "Willkommen zum Fernwartungs und Webmeetingportal.",
"welcomePicture": "welcome.png",
"LoginPicture": "welcome.png",
"GeoLocation": true,
"CookieIpCheck": false,
"agentCustomization": {
"displayName": "TEXT - QuickSupport Agent",
"description": "TEXT - QuickSupport Agent background service",
"companyName": "TEXT",
"serviceName": "TEXT",
"_foregroundColor": "FFFEFE",
"_backgroundColor": "#87888A",
"image": "welcome.png",
"remoteMouseRender": true,
"fileName": "Agent"
},
"userConsentFlags": {
"desktopnotify": true,
"terminalnotify": true,
"desktopprompt": false,
"terminalprompt": false,
"desktopprivacybar": true
},
"desktopPrivacyBarText": "{1} - ist mit Ihrem System verbunden!",
"minify": true,
"_newAccounts": true,
"_userNameIsEmail": true,
"AllowHighQualityDesktop": true,
"CertURL": "https://FQDN:443",
"ManageAllDeviceGroups": [ "Blip1","Blop2" ],
"agentInviteCodes": true,
"AgentSelfGuestSharing": true,
"mstsc": true,
"ssh": true,
"auth": "ldap",
"ldapUserName": "sAMAccountName",
"_ldapUserBinaryKey": "objectSid",
"ldapUserKey": "sAMAccountName",
"ldapOptions": {
"url": [ "ldaps://serverA:636", "ldaps://ServerB:636" ],
"bindDN": "CN and so on",
"bindCredentials": "some password",
"searchBase": "DC=yes:ther_is_one",
"searchFilter": "(&(sAMAccountName={{username}})(objectClass=organizationalPerson))",
"tlsOptions": { "rejectUnauthorized": false },
"reconnect":true
},
"_altmessenging": {
"_name": "Ticket",
"_url": "some URL"
},
"customui": {
},
"_letsencrypt": {
"comment": "Requires NodeJS 8.x or better, Go to https://letsdebug.net/ first before trying Let's Encrypt.",
"email": "some mail",
"names": "DNS-FQDN",
"production": false
},
"smtp": {
"host": "some server",
"port": 587,
"from": "some mail",
"user": "some user",
"pass": "some pass",
"tls": false
}
}
@wh1te909 commented on GitHub (Feb 24, 2022):
hmm yea could be ldap. I just tested by installing mesh 0.9.89 on an external server and it still works. can you try disabling ldap temporarily or other things in config.json to try and get it working so we can see what's causing it to break
@sadnub commented on GitHub (Feb 24, 2022):
Does it want the ad domain in the cookie?
@JSuenram commented on GitHub (Feb 25, 2022):
And if, how to configure?
@sadnub commented on GitHub (Feb 25, 2022):
github.com/wh1te909/tacticalrmm@4f8615398c/api/tacticalrmm/agents/models.py (L699)This is the function we use to generate that cookie.
We use it like this:
github.com/wh1te909/tacticalrmm@4f8615398c/api/tacticalrmm/agents/views.py (L205)We pass in user//username, but between the // we could specify a domain like
user/domain/username.Curious to see if that is needed now with an ldap setup. Do you need to specify the domain when you log in? Or are there any other debugs you can run from within mesh to see if the domain is used for other mesh tasks?
@JSuenram commented on GitHub (Feb 25, 2022):
As we are in the default domain in mesh, no, there is just entering Username/Pass on logon....
@sadnub commented on GitHub (Apr 17, 2022):
We can't reproduce this. It is possible that the ldap configuration is interfering, but I don't think this is something we can fix. If there are other settings, we need to add we can definitely do that.