Ylianst
Elevated uac prompt non admin
Hi all,
My question is let's say I have an end user that hasn't got admin rights on there work pc but I know the admin creds
on the meshcentral server I send them an invite link to download the agent but only to run it, I don't see the elevated uac prompt when I want to install a program
Is there anyway I can see the uac prompt or even send the admin creds and send it to the uac
Thanks, Rob
This is something I've been trying to figure out... Normally, this doesn't work, because you need admin privs to see the secure desktop. Also, normally windows will block piping the credentials into RunAs, so as a workaround I tried using a pseudo console, which worked, but it spawned a non-interactive session so it wasn't able to access the desktop. I think I tried again using the pseudo console, but then using it to RunAs in conjunction with the task scheduler, to get an interactive session... But IIRC, I think the issue I came up with in that scenario, is that only LocalSystem can scrape the secure desktop, unless you set UAC to use interactive instead of secure desktop. I didn't try that last test yet tho, since it was a very convoluted way to run the agent...
I ran the last test I mentioned just now. If you set the UAC to interactive (which you need admin to be able to do), then the agent running in user space, is able to scrape the UAC prompt, and show it on remote desktop, however, the agent lacks permission to be able to inject the mouse click on the UAC panel. It can move the mouse over the button, but is unable to click the button... Still need to figure that one out...
Well I know one way to do it, is to use the process elevation to install the agent as a background service, because LocalSystem has no problems with UAC and secure desktop. And then uninstall the service on close, etc
Ok, sound logical. What has to be done to make it work? And I guess there should be a clear "User Consent" when this is done to make sure AV-Software does accept this behavior?
I know splashtop sos can do this even when the agent isn't installed and all the client gets is a link from the sender
https://support-splashtopbusiness.splashtop.com/hc/en-us/articles/360002438071-Connecting-with-Admin-Rights?_ga=2.236141382.699387586.1643449024-1441798112.1643449023
And anydesk
https://support.anydesk.com/knowledge/administrative-privileges-and-elevation-uac#portable
good news
if you install meshcentral router on your pc that connects to your meshcentral server, from there you can install via admin via rdp
on the end users pc, if you send them an invite and they run the assistant
there pc will appear under the meshcentral router
click "add map" give it a name and application select "rdp"
it will appear under mappings, then just connect to rdp via the admin account for that pc
good news
if you install meshcentral router on your pc that connects to your meshcentral server, from there you can install via admin via rdp
on the end users pc, if you send them an invite and they run the assistant
there pc will appear under the meshcentral router
click "add map" give it a name and application select "rdp"
it will appear under mappings, then just connect to rdp via the admin account for that pc
I don't think this is comparable or even a solution. It's a dirty workaround which may work in some cases... But it has to be possible to make elevating from Agent a feature/option. In my opinion this is one of the biggest issues for using MeshCentral Remoting Windows-System where you have limited access to at all.
I mean this is a dirty solution to install the agent but once you have installed the agent it will then work with uac prompts... I will check this and get back to you
success it works
so the user/client can run the assistant, once you map the user/client pc via rdp in meshcentral router, you can rdp as admin and then you can install the meshcentral agent no problem as you see the UAC prompt as were admin
you will then see 2 pcs/agents under the group, just delete the assistant one
success it works
so the user/client can run the assistant, once you map the user/client pc via rdp in meshcentral router, you can rdp as admin and then you can install the meshcentral agent no problem as you see the UAC prompt as were admin
you will then see 2 pcs/agents under the group, just delete the assistant one
But still not a solution if you want to remote-support a single standalone client and need to elevate. This might help if you can reach the client or use MC router, but that is not the case in many situations.
in my scenario i know the admin privs as its a work pc, the user/client has just got a standard user and NOT admin
i just send them an invite link to get the assistant app and works perfectly
Ok, so I looked further into this. Simply elevating to admin is not sufficient to scrape the secure desktop, as even in interactive mode, remote injection is blocked. The only way around this, is to use LocalSystem. So when I looked into how other software does it, it seems that is exactly what they do. They actually do a priveledge escalation to then install and manually execute a background windows service with the intent to spawn a process running as LocalSystem, then remove the installed service...
The issue with that for the meshagent, is the user experience. Currently, with shared links, the admin will see a device popup on the web interface... Then they will need to provide credentials for the elevation. The easiest way to to get LocalSystem, is to spawn another instance of the agent as LocalSystem, but this means the admin will need to then interact with a different device on the webux. Even if the agent were to keep the IDs the same, the device would still disappear then reappear on the webux. Once the agent disconnects, the webux will revert views...
The ideal situation, is that the credentials are passed to the agent in the KVM tunnel, which is what Ylian suggested. However, the current kvm uses redirected std pipes to communicate with the parent process... The agent would need to spawn LocalSystem which would in turn spawn the child KVM process... That process needs to interact with the main agent process... So in order to get that to work, I would need to implement a shim to relay the communications.
Since I'm already in the middle of writing a new KVM module that uses MSFT's Desktop Duplication API, it may be better/simpler to modify that version I'm writing to support a named pipe in addition to std redirection, so that it can communicate directly with the main agent process, negating the need to implement a relay.
Looking forward to this new KVM module! If I can help with, just give me a hint....
anydesk have caught on im using it for professional use now, as im using it frequently every day to log in users machines
hows the elevated UAC module coming along @krayon007
Not yet, I've been focused on stability and memory usage improvements. As well as other bug fixes
Same question here, @krayon007 - this feature seems to be kinda crucial for any Remote Desktop tool or similar, so I think it would be really great if you could prioritize this as the whole project would benefit from it. I'd help if I could, but I really don't speak C :/
any update or should i give up and go with another RMM solution @krayon007 @Ylianst
@robina80 We don't know what the future of MeshCentral looks like yet, so I think this is kind of a low priority for both of them right now. See the discussion at https://github.com/Ylianst/MeshCentral/discussions/4795