If you are running an environment with a modern management strategy where your clients are highly mobile and managed by cloud services, your built-in direct connection based tools like RDP or Remote Assistance are limited in usability for supporting your devices. In general with the mobile workforce nowadays we can’t rely on solutions needing a direct connection between two devices.
The lesser known built-in Quick Assist from Windows 10 implements a different way of connecting to the remote client. The supporter connects to a Microsoft cloud service by starting Quick Assist and logging in with a Microsoft Account (MSA and AAD accounts supported). Quick Assist will hold a connection to the Microsoft cloud service and the supporter is given a connection code. The user who needs assistance also starts Quick Assist and connects the the same session by specifying the connection code. This way both clients can use outbound connections to the Microsoft cloud service and the cloud service is acting as a broker between both clients. This allows flexible connectivity to remote clients wherever they are. Even behind some firewalls we normally don’t have any issues to successfully build a connection. In fact this is the same approach all the third party vendors like AnyDesk, TeamViewer, BeyondTrust Remote Support (aka Bomgar), or LogMeIn are using with their remote support software products.
That’s great but why should I care about a remote support solution anyway if I have Teams?
That’s a valid point in times where collaboration tools like Microsoft Teams are available and we have screen sharing capabilities where we can give control to someone else:
The main issue is the elevation of privilege’s. I guess everyone is familiar with the User Account Control (UAC) in Windows. If you try to elevate a process from a standard user context you will be switched to the so called Secure Desktop, the dimmed desktop in the background is the Secure Desktop which can not easily be circumvented:
The Secure Desktop can not be handled by the collaboration tool Microsoft Teams. As soon as the Secure Desktop appears the shared screen looses track of the session and the remote supporter can’t control any UAC dialog:
Actually this is the same for Quick Assist, as soon as you try to elevate a process as supporter you loose the session and you get a black “pause” screen like this:
Do I have to switch to third party software for elevation support?
It depends on what functionality you need for your support processes. Third party normally has a lot of functionality which is needed in enterprise environments like extensive logging/auditing etc. All third party products normally support also the elevation scenario, but there is a way to accomplish remote support even with the Windows 10 built-in Quick Assist solution. The simple solution here is to deactivate the “Secure Desktop” on your clients:
As soon as this is done, the elevation prompt will be visible in the Quick Assist session and can be controlled and the remote supporter can enter credentials for elevation. Instead of the black pause screen you will see the UAC prompt (without secure desktop):
The downside is that the secure desktop is designed that no one can remote control the UAC dialog and inject something as the dialog is not running on the users interactive desktop. Without the secure desktop the UAC dialog is running like every other Windows dialog on the interactive desktop of the user. This makes the device vulnerable to UAC spoofing attacks. If you and your security department are feeling okay with that fact, you can re-configure the devices and get a working Remote Support solution out of the box from Microsoft built directly into Windows 10 called Quick Assist.
Okay wait but what about Microsoft Teams when I disable the secure desktop? Yes, it would be the logical conclusion that we are able to control the UAC dialog via Teams then also, but that’s not the case. You will see the dialog but you are unable to control it. You can’t enter credentials or click on any of the buttons:
How to reconfigure my devices now?
To deactivate the prompt on the secure desktop, you can easily use a simple PowerShell script provided on my GitHub account and deploy it via Intune to your devices. I used an AAD device group for assignment here:
When successfully applied you will see it in the Intune portal:
The script is very simple and checks if the PromptOnSecureDesktop value is not 0 and will set it accordingly to 0. You can find the script here:
https://github.com/okieselbach/Intune/blob/master/DisablePromptOnSecureDesktop.ps1
You might have configured UAC already with a custom Intune profile or you use the Intune MDM Security Baseline for Windows 10. The baseline will configure the UAC to a more strict default for standard users to deny UAC requests:
So, you might need to adjust these policies. You can also implement the same behavior by configuring the Intune profile without using the PowerShell script. As already mentioned and shown above, the Microsoft security recommendation for UAC is not to disable the secure desktop. As security is always a trade off between usability and security, you have to adjust from time to time some settings for your organizational needs. If your user support needs this and the security department is taking that risk, you can move forward with this solution.
This might help if Quick Assist provides you enough functionality to support your processes, or if you not have the budget for an additional remote support tool. But actually there are some remote support tools which are quite affordable and providing way more functionality and don’t require to turn of Secure Desktop, one of the candidates here is AnyDesk.
A last goodie and small side note, there is a keyboard shortcut to open Quick Assist via:
[Ctrl] + [Win] + [Q]
And because Quick Assist is available from the beginning you can call it very early in the process. In the next screenshot I have used the keyboard shortcut during enrollment in the Autopilot user ESP phase (sorry for the german Quick Assist window):
I hope this helps if you are looking for a cheap built-in solution to get Quick Assist to work even with elevation and UAC prompts.
Happy supporting of your user base.
UPDATE 2020-04-22:
Many thanks to one of my blog readers (Tomasz) who mentioned this approach in the comments! I will show the approach to disable Secure Desktop during a remote session when you have enabled the local Administrator account or any other additional local admin account on the target device. Meaning you can keep the local admin credential and do not provide them to the user. It gets a little hacky but it can help people in times of WFH to have another way of enabling elevation for remote support, when no management channel else like MDM, GPO, internet-based software management is available.
The solution relies on the fact that the “run as different user” does not show an UAC dialog on secure desktop. I’ll quickly demonstrate the way to disable the UAC with the help of this fact. Hold Shift while right click on PowerShell and choose “Run as different user”:
Now you will get a run as dialog without Secure Desktop:
Here you can type in a local admin account or the built-in Administrator account if your devices have it enabled. You will get a PowerShell running in the context of the .\localadmin in my case:
In that PowerShell I’m still not able to do task which require elevation as you can see with my first command “reg add” to write to HKLM. But interestingly I’m able to open secpol.msc as you can see. In the normal user session secpol.msc can’t be opened, you get this dialog:
With the ability to open secpol without UAC you can modify the Prompt for Secure Desktop policy to disable the Secure Desktop and UAC will be shown on the interactive desktop again:
If you have an enabled the built-in local Administrator account, you can use that one for run as different user:
and you will get a PowerShell which is automatically elevated (as long as you run the Windows default UAC settings):
Elevation can be seen in the title and my reg add to HKLM succeeded this time. That way you can modify the the reg key for Secure Desktop directly, or again use secpol.msc to modify it.
Yeah, this approach needs a local admin account but if you have one and do not have any other management channel this might be your rescue.
Anyway go leverage this for unattended access?
No not with Quick Assist, it is bound to the code and approvals from the user. Which is for most people a good thing as and users need to be in control, but I understand that companies also have requirements for unattended solutions. With Quick Assist I don’t see any chance to accomplish this.
This tool works very well. It would so be great if you could limit the usage rights via policy to people from the same tenant or even specific user groups (e.g. helpdesk) to prevent abuse by fraudsters.
I’m trying to configure this via OMA-URI, not sure why it doesn’t apply. thoughts? ./Vendor/MSFT/Policy/Config/LocalPoliciesSecurityOptions/UserAccountControl_BehaviorOfTheElevationPromptForStandardUsers == Integer == 3
Hi Jose,
via a custom OMA-URI you should use: ./Vendor/MSFT/Policy/Config/LocalPoliciesSecurityOptions/UserAccountControl_SwitchToTheSecureDesktopWhenPromptingForElevation = 0 (Interger) to disable the Secure Desktop.
Reference:
https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-localpoliciessecurityoptions#localpoliciessecurityoptions-useraccountcontrol-switchtothesecuredesktopwhenpromptingforelevation
best,
Oliver
Thank you Oliver, I’ll give it a try
I am sorry to tell you that this advice is not valid when you are accessing computer, where logged user is just a standard user.
In that case you are not able to turn off UAC via altering registry settings.
In fact everything that will require admin privileges will end up displaying UAC.
So if your user is just a standard user, you will not be able to do anything.
This days most of the users will be using standard account not admin, unless they use account that was created when Windows was installed. In that case will have and admin privileges….
I believe you should mention that in your article, that you can use above method only when user has admin privileges already…
Hi Tom,
that’s not true the solution does work with logged on standard users. check the picture with Quick Assist and the UAC dialog it even shows that the user is not in administrator mode meaning the current logged on user is standard user. Without this capability it wouldn’t be a worth to mention, as you also mentioned almost every enterprise is running with standard users nowadays. Try it yourself, just go to a device with standard user, change the regkey (it will be recognized on the fly) and start the Quick Assist session, you will see the UAC can be controlled from the supporter and he can enter some valid admin credentials.
best,
Oliver
Oliver, thank you for this article, its clarity, and for adding the OMA-URI policy in the comments. As you know with the current state of COVID19 policies and regulations, this will be a boon to support my users remotely and can be undone once we have returned from quarantine. Thank you so much
So, here’s the caveat. A standard user cannot save the registry change in order to get the required assistance with Quick Assist. The scenario is a remote user who can’t install the VPN client due to UAC and therefore can’t connect to the work domain to get policies and what not. It’s a Catch-22 situation and the issue many are struggling with with the recent WFH situation. If anyone has some suggestions or workarounds to make this work, I’d love to hear it. Thanks.
I think this requires some form of remote management MDM set up before hand. We’re using intune so it was just a matter of pushing the policy or a powershell script to change the registry entry.
If you weren’t set up for remote management of your devices before, you’re in a pretty bad position for this. You may have to locally configure new machines with aremote management/MDM solution configured and setup some type of physical machine swap out process.
Dear Harjit Dhaliwal
I used solutions listed below. Worked for me.
It works best if you have credential to local admin, and even better if this is built in local admin.
First I checked who is the admin by using command: ”net users”
Then used admin account (that I have credentials to) to run cmd as that admin user.
While in cmd box running as admin user, I have issued command “secpol.msc”
This opened box\window with local security polices and under “local polices” –> “Security options” point to policy that says: “User Account Control: Switch to the secure desktop when…”
and change that to disable. Apply etc.
After that you will still get UAC prompt, however is popping as a box for typing admin credentials and is not dimming the desktop.
This way you can see UAC prompt while remoting via Quick Assist, and open things by right click and open as admin etc.
if this still not work for you, then only way is to use local admin account to activate built in administrator account and use that account for everything else, as build in administrator account is not triggering UAC prompt, and all commands issue with this account are accepted and issued without elevating etc.
That’s an interesting approach, I think I will update the post later to show this nice little workaround with some screenshots. Thanks for sharing Tomasz.
Hi Oliver, do you know if the text prompt can be modified that the remote user sees and needs to accept it?
Hi,
I’m not aware of any method to modify this…
best,
Oliver
Wonder what are the impact on disabling secure desktop?
With regards to Tomasz suggestion not sure how you were able to disable the securedesktop remotly, when you run cmd as admin you would have prompted for uac?
Hi Gts,
I’ve written about the impact in one of the paragraphs. The main impact is that your device is vulnerable to UAC spoofing attacks. If your security department is okay with that you’re good to go if not it’s not a solution for you. Tomasz approach needs a local administrator account and with that prerequisite you are able to make a QuickAssist session and use this local admin via the run-as way of process creation in this case the cmd and you will not see the normal UAC dialog you will see the run-as dialog which is not on the secure desktop but in case of the secedit command it still allows to modify the setting even if no UAC dialog was upfront. So, with this approach you are able to modify the SecureDesktop setting in a QuickAssist session so that you are able to proceed with a turned off secure desktop and you are able to interact with regular UAC dialogs in the existing and new QuickAssist sessions. The UAC dialogs are not shown on the secure desktop after the modification. All this is not needed if you have a management channel like Intune. It would be the case if you have to support a device where you not have a working management channel to reconfigure the secure desktop setting. Try it yourself, follow my instruction and use QuickAssist and connect to a LAB VM for example. You can verify the behavior I described easily.
best,
Oliver
Thank you for the quick response and not sure what you mean by “All this is not needed if you have a management channel like Intune” as I do have intune and UAC is an issue with quick connect. As you described above I am concerned tunning off secure desktop completly.
The „All this is needed …“ reference was in regards to the Tomasz suggestion. If you have Intune you don’t need this, your decision is only are you willing to take the risk of disabling the SecureDesktop or not. I think the risk needs to be looked at, and in addition to cost, and usability gain in case of support. Like always in IT the answer is it depends of your situation and security demands 🙂
Rather than disabling the Secure Desktop, run PowerShell as your admin user (as above) and elevate using the following command:
start-process powershell –verb runAs
Ask the user to click ‘yes’ and you’ve got an elevated shell.
Also a good way of achieving the goal 👍
start-process powershell –verb runAs —– prmoted for the UAC in secure desktop where i couldnt see the prompt through the quick assist
i also tried to create a shortcut and shift+rightclick run as an admin which also didnt elevate with admin (however i was able to type the admin details)
i would like to acieve with secure desktop
the uac policy is set for prompt for credentials in secure desktop in microsoft baseline
Hey RG,
I really think there is no way currently to use it with enabled Secure Desktop. There would be a way when QuickAssist would support UIAccess. Remote Assistance is supporting UIAccess and is able to turn of Secure Desktop to run successful. See here: https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop. Quick Assis sadly does not support this feature.
best,
Oliver
Hello,
I tried Tomasz solution which is to disable Secure Desktop through the use of secpol.msc (or gpedit.msc). I used a local administrator to do that and I succeeded. However, even if secure desktop seems to be disabled, I still have UAC popups on remote computer (which is normal of course) BUT I still have a black screen on Quick Assist.
I also checked the registry and the key is set on “0”.
What’s wrong in my case? FYI, I’m using Windows 10 v1803 64bits.
Regards,
DeltaSM
Hey DeltaSM,
that’s interesting, looks like the setting does not take into effect. Honestly, I’m not aware of any other setting which could still block you. The only thing I could imagine is maybe a GPO, MDM policy or something similar, always resetting your setting back to 1, but obviously I think that would have be seen from your side. But worth a double check it would be, to verify if there is no other policy resetting your key. Another idea I don’t have at the moment.
best,
Oliver
Hello Olivier,
First of all, thank your for your answer.
The concerned computer is not part of a domain. It’s in WORKGROUP with no GPO, MDM or other policies applied. It’s a simple Windows installation with a limited rights user.
Maybe our Windows 10 version (1803) is too old?
This issue is not a problem anymore but it’s always interesting to report a bug 🙂
Regards,
DeltaSM
Interesting… I would not expect Windows 10 version 1803 to behave differently here as this UAC setting is available since Vista time and I think there were no major changed in UAC until now. Hmmm 🤫… really no idea why this happened. I guess to finally clarify it, a 1803 device would be needed to be deployed and then the we would have to try to reproduce the issue for further detailed analysis. But I think that should only be done if it introduces a major issue.
I will try to reproduce this problem one day once I have some free time 🙂 But for now, it’s not a problem anymore.
Regards,
DeltaSM