I’ve run into this exact same problem 3 times now in one week, so I figure that probably doesn’t bode well and I should attempt to do something about it.
With 3 different pieces of software (one of them ours), the remote control functionality is imperfectly implemented. Let’s see if this sounds familiar to anyone. You are the helpdesk. You attempt to connect to a user’s desktop. You have to elevate an application. When you do, you (the helpdesk who actually has the password) doesn’t see the UAC dialog – instead, the end user (who does not have the password) does. Even if you decide to give the user the password (it happens), you then can’t control or even see the elevated application.
Kind of makes it hard to be a helpdesk when that happens.
Here are the 3 solutions that I have seen to this problem:
Here’s what I wish all 3 had done:
Now, most people don’t really understand what this is for, and the UAC manifest is typically just a copy/paste affair. But it pays for the remote desktop developer to pay attention to it. For any regular piece of software, you generally want to stay away from it – it’s dangerous, and sidesteps a significant security feature (UIPI). But if you are remoting the desktop, it’s precisely what you want – you need to be able to see everything!
It’s dangerous enough, in fact, that we won’t allow you to set it without digitally signing your application. By default, you also have to have it installed in a secure location (such as Program Files). You can set a group policy to not require a secure location, but there is no option to not require a signature.
However, once set up, it’s really powerful. You’ll be able to remote every possible kind of window – any integrity level at all. No more blank, unresponsive screens. Everything comes across, regardless of integrity level.
You’ll also be able to leverage the group policy that lets you prompt NOT on the secure desktop if you are a UIAccess application – that way you don’t have to lose the defense in depth of using the secure desktop for normal elevation, but you also avoid writing code to remote the secure desktop when your remote desktop application is running.
All in all, you are just full of win.
Now, it’s my job to fix up apps that are written suboptimally, so you may be wondering how I did getting these working?
Anyone writing desktop remoting applications, please consider using this. And feel free to contact me if you have questions. I would be delighted to help you.
For the record, here is the corrected manifest for the one I was able to fix:
<?xml version='1.0' encoding='UTF-8' standalone='yes'?> <assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'> <assemblyIdentity version="18.104.22.168" processorArchitecture="X86" name="Microsoft.FixedUpApp.SupportConsole" type="win32" /> <description>Fixed Up App</description> <dependency> <dependentAssembly> <assemblyIdentity type='win32' name='Microsoft.Windows.Common-Controls' version='22.214.171.124' processorArchitecture='x86' publicKeyToken='6595b64144ccf1df' language='*' /> </dependentAssembly> </dependency> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> <security> <requestedPrivileges> <requestedExecutionLevel level="asInvoker" uiAccess="true"/> </requestedPrivileges> </security> </trustInfo> </assembly>