Remote Assistance With Shadow Session

One of the basic requirements when providing IT support is to interact with the user. Whether it involves troubleshooting or assistance, frequently our users appears to be unaware of what they are doing, or their ability to analyze and describe the problem is on par with that of the average user of a baby tablet.

The only way to save ourselves and our nervous system from the user will therefore be to see with our own eyes what is happening on their desktop using remote desktop software such as AnyDesk, TeamViewer, and the like, paying the relevant license if due, or…

…or let’s see how to do all this using a tool provided by Microsoft itself, even if not very well advertised (maybe because it’s free?): Shadow Session

It’s essentially an RDP session that works very similarly to Windows Remote Assistance, except it doesn’t require an internet connection, and most importantly, the user will simply need to “accept” the connection with a click without getting lost in additional steps.

How to enable RDP Shadowing

Let’s see how to do it in an Active Directory Domain environment. So, we’ll create a Group Policy Object (GPO), and through the Group Policy Management Editor, we navigate to Computer Configuration / Administrative Templates / Windows components / Remote Desktop Services / Remote Session Host / Connections

If it’s not already enabled, let’s activate Remote Desktop and let’s make sure to delve into the security parameters and their implications (RTFM here). If you’re lazy, enable everything and cross your fingers

At this point verify the settings in Set rules for remote control of Remote Desktop Services user sessions. By default, all users belonging to the Administrators group on the remote host are enabled to perform shadowing with the user’s consent. Personally, this seems like the most appropriate choice, but obviously adapt it to your context..

Allow RDP Shadowing on Firewall

Unfortunately, the infamous RDP port 3389 is absolutely useless in this case. In fact, shadow sessions use port 445/TCP and other Ephemeral ports that are completely dynamic within the range 49152-65535/TCP. Therefore, the only solution is to allow them collectively on the firewall. In the case of the native Windows Firewall, we can enable two predefined rules

• File and Printer Sharing (SMB-In)
• Remote Desktop - Shadow (TCP-In)

The latter rule exclusively allows listening for the RdpSa.exe process.

Remote connection to the user session using RDP Shadowing

To initiate the connection, we use the official Windows Remote Desktop client. Unfortunately, as of today, there isn’t an option for shadowing in the GUI. Therefore, we’ll have to start it from the command line

1

mstsc.exe /shadow:<Session ID> /v:<Computer name or IP address>

This is the basic syntax, but we can also specify the options below

• /prompt - You will be asked to specify the username and password to connect with, instead of using your current user
• /control - You will have full control of the remote mouse and keyboard. Without passing this option, you will have view-only access to the remote session
• /noConsentPrompt - No consent will be requested from the remote user for accessing their session

Finally, we will need the Session ID of the remote session, which we can always obtain from the command line with

1

qwinsta /server:<Computer name or IP address>

And here’s the output where we see that the “Active” session of our beloved user has ID 1

We can then proceed with the connection

The user will receive the request, with the authorization we request (view or control), which they will need to accept

And finally, we’ll be able to see and interact with the user session

Easy, right? We could often save ourselves from using qwinsta, as the session ID, if it’s not a server, will almost always be 1. But, since we want to be prepared for anything and we don’t want to to break one’s b waste time, here’s a devilish .bat file that will make our lives better

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

@echo off
set session=0
set /p remotePc=Nome o IP computer: %=%
for /f "tokens=2-4" %%a in ('qwinsta /server:%remotePc%') do @if "%%c"=="Active" (
 set session=%%b
 set user=%%a
)
IF NOT "%session%"=="0" (
 echo "Connessione a %user%"
 start /max /wait mstsc.exe /v:%remotePc% /shadow:%session% /control
 exit
) ELSE (
 echo "Non ci sono utenti attivi"
)

Yes, I know, sooner or later I’ll convert it to PowerShell, but a .bat file, as evil as it may be, has an undeniable advantage: it’s just a double-click away even for the most basic users… you never know when a “Muggle” (quoting) of IT might have to use it, as we see below.

RDP Shadowing without administrative rights

By default, only administrators can create shadow sessions. However, it might be essential for non-privileged users, such as application support users, to have this functionality as well. Of course, we wouldn’t want to grant them administrative rights, right? RIGHT

We create a Security Group on our Active Directory domain and populate it with standard users who will provide support

Then, we grant permissions to this group via shell. Shell, you ask?! Yes, indeed, no GPO can help us, nor can a registry key. So, what we’ll need to do is run this PowerShell script on the computer that will receive the connection

1
2
3

#: Restart required
$obj = get-wmiobject -Name "root\CIMV2\terminalservices" -Class "Win32_TSPermissionsSetting"| Where-Object TerminalName -eq "Console"
$obj.AddAccount("contoso.local\RDP_SHADOW-Users",2)

And what if I regret it? To reset the standard permissions, here’s the reverse function

1
2
3

#: Restart required
$obj = get-wmiobject -Name "root\CIMV2\terminalservices" -Class "Win32_TSPermissionsSetting"| Where-Object TerminalName -eq "Console"
$obj.RestoreDefaults()

Considerations

What we’ve seen proves to be very useful in domain networks where we have the ability to directly access the machines via LAN/VPN/MPLS, and/or where they don’t have internet access to use software like AnyDesk, TeamViewer, etc.

A necessary condition is, of course, the adequate setting of the software firewall running on the clients, preferably enabled only for Domain Profile networks.

Not bad for being free, right? What do you rely on for remote support?

Feel free to share your experiences in the comments, see you soon.