Introduction
One of the core differences between traditional Remote Desktop Services and Windows Virtual Desktop is they way clients connect to (RD/WVD) resources. Microsoft have introduced a new mechanism within Windows Virtual Desktop called Reverse Connect.
Traditional Remote Desktop Services (RDS) connectivity:
Clients would typically connect to a RD Gateway for external access to RDS resources. The RD client would connect to the RD gateway over TCP 443, authenticate with Active Directory, and then the Gateway would establish a secure inbound session to the selected/chosen resource (RemoteApp/Desktop). In more recent versions of windows, the RDS Gateway can also use the UDP port 3391 (when configured) to enable dual transport for improved connection quality compared to the traditional TCP method. UDP does provide significant improvements over higher latency/unreliable networks.
UDP bidirectional endpoints connection
You can read more on deploying a 2012 RD Gateway here: https://ryanmangansitblog.com/2013/03/27/deploying-remote-desktop-gateway-rds-2012/
You can also read more information on the Terminal Services Gateway Server Protocol here and Remote Desktop Protocol: UDP Transport Extension here
WVD Reverse Connect:
There is no requirement for any inbound ports to be configured or opened on a VM to setup a RDP connection on WVD. This is essentially a reverse proxy security feature straight out of the box. Communication between the host pool/s and WVD core SaaS components is completed using TCP https (443) only (at time of writing). That being said, for those using third party firewall’s/security appliances, you may need to double check rules allowing access to Azure services.
Reverse connect also provides new benefits like setting policies including conditional access policies. For example; Client time of day restrictions via IP address, controlling access via the Client IP address, time and/or other.
How Reverse Connect works:
- A user launches the RD Client, they enter in their credentials and authenticate with Azure AD. on successful sign in, Azure AD returns a token to the RD Client.
- The RD Client then presents a token to the Web Access component, the Broker service then query’s the SQL Database to determine the available and authorised resources for that user.
- The user selects and clicks on the chosen resource and connects to the Gateway.
- The broker service then orchestrates the connection from the host agent to the Gateway.
- The User is then able to access and use resources requested (Desktops/Apps).
Diagram showing connection flow for WVD
As you can see from the diagram above, resources connect from the inside of Azure to the gateway. meaning that Desktops and Apps will only ever connect to the Microsoft managed Azure services and will not connect directly out to the public network/s. The RD client authenticates and connects to the RD gateway component, and the desktop/apps (Azure VM’s) connect to the gateway. All communication and session connectivity is managed at the gateway.
Shadowing:
I have noticed that Shadowing is currently not supported out of the box however you are able to use third party tools to enable shadowing. You can also deploy a Jump server to the WVD Host/s vnet/s and using MSTC commands to shadow. Further to this, you could also Connect local client devices or deploy a small host pool for WVD Management enabling admins to shadow large WVD deployments. Please note you would need to script the output of IDs for multiple servers or run qwinsta on each VM.
qwinsta lists the sesssion id’s and state.
qwinsta
Once you have the session ID, you are then able to use mstsc /shadow to connect to the session in question.
The following command will allow you to shadow and control the session.
mstsc /v:rdsh01 /shadow:5 /Noconsentprompt mstsc /v:rdsh01 /shadow:5 /control
The above video shows you a jump server connecting and shadowing a session in Windows Virtual Desktop.
Microsoft have suggested that shadowing may be added as a future feature to WVD. Take a look at the community post here: Shadowing is not supported directly out of the box (at the time of writing).
Looking at Reverse connect on the client and Host VM:
When taking a closer look at connectivity, you can see on both the client and Session host/VM, they are both using TCP 443.
Client Connection to RD Gateway in Windows Virtual Desktop:
As show in the screenshot, you can see the client (msrdc.exe) has connected to the WVD gateway IP 41.136.28.200 on https 443.
Session Host connection to RD Gateway in Windows Virtual Desktop:
Same again, you can see from the screenshot below, that the host (RDSH) is connected to the WVD Gateway on 51.136.28.200 on https 443.
as shown using Remote Display Analyser, The Active transport protocol is “TCP (Reverse-Connect)”
Remote Display Analyzer showing a Round Trip Latency of approximately 56 ms
Beware of Network Latency:
its important to note that, as the UDP dual transport feature is not currently available on Windows Virtual Desktop (at time of writing) you need to be aware of the potential challenges when deploying WVD for remote workers who may have higher latency connections. This also may cause cost implications as you would need to deploy multiple host-pools across multiple regions for remote works operating in different geographic locations. as deploying all hosts out of the same region may have an impact to user experience and performance.
Please see the link for Windows Virtual Desktop Experience Estimator to see the round trip time (RTT) in ms across available regions.
Windows Virtual Desktop Experience Estimator showing an example of Round Trip Time (RTT).
Summary
Reverse Connect (RC) provides out of the box security and enables WVD customers to use Azure Active Directory Conditional Access security to apply granular control user access. Reverse Connect also removes any exposure of the Windows 10 Multi session or other host VM’s as all resources connect to the Gateway, and there is no requirement for a direct connection out to the public network/s. This provides a improved security mechanism compared to traditional RDS. This should also encourage existing RDS customers to consider moving to Windows Virtual Desktop for enhanced security. A reverse proxy feature like Application Request Routing like ARR can be complicated to deploy in traditional implementations of Remote Desktop Services.
It is a shame that UDP dual transport is not available as of yet (time of writing) however when testing WVD, at a latency of around 79 RTT, I did not experience any issues on performance. Overall, experience is very good.
As shown in this blog post, you can shadow WVD users, you just need some though on the best way you like to manage this.
Update from Scott Manchester and some of the features coming soon:
As always, any questions, feel free to add them to the comments section.
Ryan Mangan's IT Blog 