Microsoft remote desktop customer Microsoft remote desktop customer is an application used to connect with a laborer running Microsoft remote desktop organizations. In organizations, laborers can partner, access, and control resources in their office-based Windows computers by using Microsoft's remote desktop customer. How secure is Windows Remote Desktop? Remote Desktop sessions operate over an encrypted channel, preventing anyone from viewing your session by listening on the network. However, there is a vulnerability in the method used to encrypt sessions in earlier versions of RDP.
Remote Desktop sessions operate over an encrypted channel, preventing anyone from viewing your session by listening on the network. However, there is a vulnerability in the method used to encrypt sessions in earlier versions of RDP. This vulnerability can allow unauthorized access to your session using a man-in-the-middle attack.
Remote Desktop can be secured using SSL/TLS in Windows Vista, Windows 7, Windows 8, Windows 10 and Windows Server 2003/2008/2012/2016. *Some systems listed are no longer supported by Microsoft and therefore do not meet Campus security standards. If unsupported systems are still in use, a security exception is required.
While Remote Desktop is more secure than remote administration tools such as VNC that do not encrypt the entire session, any time Administrator access to a system is granted remotely there are risks. The following tips will help to secure Remote Desktop access to both desktops and servers that you support.
Basic Security Tips for Remote Desktop
1. Use strong passwords
Strong passwords on any accounts with access to Remote Desktop should be considered a required step before enabling Remote Desktop. Refer to the campus password complexity guidelines for tips.
2. Use Two-factor authentication
Departments should consider using a two-factor authentication approach. This topic is beyond the scope of this article, but RD Gateways can be configured to integrate with the Campus instance of DUO. Other unsupported by campus options available would be a simple mechanism for controlling authentication via two-factor certificate based smartcards. This approach utilizes the Remote Desktop host itself, in conjunction with YubiKey and RSA as examples.
3. Update your software
One advantage of using Remote Desktop rather than 3rd party remote admin tools is that components are updated automatically with the latest security fixes in the standard Microsoft patch cycle. Make sure you are running the latest versions of both the client and server software by enabling and auditing automatic Microsoft Updates. If you are using Remote Desktop clients on other platforms, make sure they are still supported and that you have the latest versions. Older versions may not support high encryption and may have other security flaws.
4. Restrict access using firewalls
Use firewalls (both software and hardware where available) to restrict access to remote desktop listening ports (default is TCP 3389). Using an RDP Gateway is highly recommended for restricting RDP access to desktops and servers (see discussion below). As an alternative to support off-campus connectivity, you can use the campus VPN software to get a campus IP address and add the campus VPN network address pool to your RDP firewall exception rule. Visit our page for more information on the campus VPN service.
5. Enable Network Level Authentication
Windows 10, Windows Server 2012 R2/2016/2019 also provide Network Level Authentication (NLA) by default. It is best to leave this in place, as NLA provides an extra level of authentication before a connection is established. You should only configure Remote Desktop servers to allow connections without NLA if you use Remote Desktop clients on other platforms that don't support it.
NLA should be enabled by default onWindows 10, Windows Server 2012 R2/2016/2019.
To check you may look at Group Policy setting Require user authentication for remote connections by using Network Level Authentication found at ComputerPoliciesWindows ComponentsRemote Desktop ServicesRemote Desktop Session HostSecurity. This Group Policy setting must be enabled on the server running the Remote Desktop Session Host role.
6. Limit users who can log in using Remote Desktop
By default, all Administrators can log in to Remote Desktop. If you have multiple Administrator accounts on your computer, you should limit remote access only to those accounts that need it. If Remote Desktop is not used for system administration, remove all administrative access via RDP, and only allow user accounts requiring RDP service. For Departments that manage many machines remotely remove the local Administrator account from RDP access at and add a technical group instead.
Click Start-->Programs-->Administrative Tools-->Local Security Policy
Under Local Policies-->User Rights Assignment, go to 'Allow logon through Terminal Services.' Or 'Allow logon through Remote Desktop Services'
Remove the Administrators group and leave the Remote Desktop Users group.
Use the System control panel to add users to the Remote Desktop Users group.
A typical MS operating system will have the following setting by default as seen in the Local Security Policy:
The problem is that 'Administrators' is here by default, and your 'Local Admin' account is in administrators. Although a password convention to avoid identical local admin passwords on the local machine and tightly controlling access to these passwords or conventions is recommended, using a local admin account to work on a machine remotely does not properly log and identify the user using the system. It is best to override the local security policy with a Group Policy Setting.
To control access to the systems, even more, using 'Restricted Groups' via Group Policy is also helpful.
If you use a 'Restricted Group' setting to place your group, e.g., 'CAMPUSLAW-TECHIES' into 'Administrators' and 'Remote Desktop Users,' your techies will still have administrative access remotely, but using the steps above, you have removed the problematic 'local administrator account' having RDP access. Going forward, whenever new machines are added in the OU under the GPO, your settings will be correct.
7. Set an account lockout policy
By setting your computer to lock an account for a set number of incorrect guesses, you will help prevent hackers from using automated password guessing tools from gaining access to your system (this is known as a 'brute-force' attack). To set an account lockout policy:
- Go to Start-->Programs--> Administrative Tools--> Local Security Policy
- Under Account Policies--> Account Lockout Policies, set values for all three options. Three invalid attempts with 3-minute lockout durations are reasonable choices.
Best Practices for Additional Security
1. Do not allow direct RDP access to clients or servers from off campus.
Having RDP (port 3389) open to off campus networks is highly discouraged and is a known vector for many attacks. The options below list ways of improving security while still allowing RDP access to system.
Goodtask review. Once an RDP gateway has been set up, hosts should be configured to only allow RDP connections from the Gateway host or campus subnets where needed.
2. Use RDP Gateways (Best Option)
Using an RDP Gateway is strongly recommended. It provides a way to tightly restrict access to Remote Desktop ports while supporting remote connections through a single 'Gateway' server. When using an RD Gateway server, all Remote Desktop services on your desktop and workstations should be restricted to only allow access only from the RD Gateway. The RD Gateway server listens for Remote Desktop requests over HTTPS (port 443) and connects the client to the Remote Desktop service on the target machine.
Utilize Campus RDP Gateway Service. This is the best option to allow RDP access to system categorized as UC P2 and lower. Includes DUO integration. RDP Gateway Service is provided by the Windows Team. Documentation is available here: https://berkeley.sharepoint.com/sites/calnetad/gateway.
The RDP Gateway Service also supports the new Remote Access Services requirement of the draft MSSND update (requirement 8), which requires the use of an approved service (i.e., RDP gateway, dedicated gateway, or bSecure VPN) for access to the UC Berkeley network from the public Internet.
Dedicated Gateway Service (Managed). Needed for rdp access to systems that are UC P4 or higher. Must also be configured for DUO
Some campus units use an IST managed VPS as an RD Gateway. A rough estimate might be that 30-100 concurrent users can use one RD Gateway. The HA at the virtual layer provides enough fault-tolerant and reliable access; however a slightly more sophisticated RD gateway implementation can be done with network load balancing.- Dedicated Gateway Service (Unmanaged). Installing and configuring RD Gateway on department run hardware.
There are many online documents for configuring this embedded Windows 2016/2019 component. The official documentation is here: https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-se..
Installing the configuring, the role service is mostly as described; however, using a Calnet issued trusted Comodo certificate is recommended. Using a self-signed cert is ok for testing, and using a CalnetPKI cert can work if all clients have trusted the UCB root. The Comodo cert is usually better accepted so that your end users do not receive certificate warnings.
Configuring your client to use your RD Gateway is simple.The official documentation for the MS Client is here: http://technet.microsoft.com/en-us/library/cc770601.aspx
In essence, a simple change on the advanced tab of your RDP client is all that is necessary:
3. Change the listening port for Remote Desktop
Changing the listening port will help to 'hide' Remote Desktop from hackers who are scanning the network for computers listening on the default Remote Desktop port (TCP 3389). This offers effective protection against the latest RDP worms such, as Morto. To do this, edit the following registry key (WARNING: do not try this unless you are familiar with the Windows Registry and TCP/IP): HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp. Change the listening port from 3389 to something else and remember to update any firewall rules with the new port. Although this approach is helpful, it is security by obscurity, which is not the most reliable security approach. You should ensure that you are also using other methods to tighten down access as described in this article.
4. Tunnel Remote Desktop connections through IPSec or SSH
If using an RD Gateway is not feasible, you can add an extra layer of authentication and encryption by tunneling your Remote Desktop sessions through IPSec or SSH. IPSec is built-in to all Windows operating systems since Windows 2000, but use and management are greatly improved in Windows 10 (see: http://technet.microsoft.com/en-us/network/bb531150). If an SSH server is available, you can use SSH tunneling for Remote Desktop connections.
5. Use existing management tools for RDP logging and configuration
Using other components like VNC or PCAnywhere is not recommended because they may not log in a fashion that is auditable or protected. With RDP, logins are audited to the local security log, and often to the domain controller auditing system. When monitoring local security logs, look for anomalies in RDP sessions such as login attempts from the local Administrator account. RDP also has the benefit of a central management approach via GPO as described above. Whenever possible, use GPOs or other Windows configuration management tools to ensure a consistent and secure RDP configuration across all your servers and desktops.
By enforcing the use of an RDP gateway, you also get a third level of auditing that is easier to read than combing through the domain controller logins and is separate from the target machine so it is not subject to tampering. This type of log can make it much easier to monitor how and when RDP is being used across all the devices in your environment.
Restrict Access to RDP with Windows Firewall
If you have a campus-managed computer:
- Contact IT Client Services or your departmental IT support for assistance.
If you have a personally-managed computer and Administrator access:
- Follow the instructions in this article to update your Windows Firewall so that only authorized hosts and networks can access your system via Remote Desktop (RDP).
Settings > Update and Security > Windows Security > Firewall and Network Protection > Advanced Settings > Inbound Rules > Remote Desktop - User Mode (TCP-In) > Properties > Scope > Remote IP address > Add > This IP address or subnet
- Settings > Update and Security
- Windows Security > Firewall and Network Protection
- Advanced Settings
- Inbound Rules > Remote Desktop - User Mode (TCP-In) > Properties
- Scope > Remote IP address > Add
- Under This IP address or subnet, only add IP addresses and network subnets that should be authorized to connect to your computer's Remote Desktop (RDP) service. Some common examples of campus IP addresses and subnets are listed in the section below.
Campus IP addresses and subnets
Based on your needs, choose only authorized campus IP addresses and subnets to connect to your computer's RDP service. Network Operations & Services maintains the source list of UC Berkeley Campus Networks, but some common examples are included below for reference.
IST RD Gateway
To access your system via RDP directly from the Internet, utilize the Campus Remote Desktop Gateway. The RD Gateway will allow you to use your CalNet ID with Duo push notifications to connect. You can authorize the RD Gateway by adding the following subnet to your firewall rule:
- 169.229.164.0/24
El capitan os x. Campus Remote Access VPN Networks (bSecure Remote Access Services with GlobalProtect)
To access your system via RDP via the campus VPN, add one or more, as appropriate, of the following VPN networks to your firewall rule:
- Split Tunnel Client Networks
- 10.136.128.0/18
- Split Tunnel Client Networks
- 136.152.16.0/20
- Restricted Tunnel Networks
- 136.152.210.0/23
Campus Networks (onsite)
To access your system via RDP while on campus, add the appropriate campus wireless or wired networks to your firewall rule:
- AirBears2 and eduroam Wireless Networks
- 10.142.0.0/16, 136.152.28.0/22, 136.152.36.0/22, 136.152.142.0/24, 136.152.145.0/24, 136.152.148.0/22, 2607:f140:400::/48
- Berkeley Campus Wired Networks
- 128.32.0.0/16, 136.152.0.0/16, 136.152.0.0/16, 192.31.105.0/24
This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.
If you are using Windows Virtual Desktop, there are two supported options for launching Windows Virtual Desktop resources:
- Using the new Remote Desktop Client (MSRDC)
- Using the Windows Virtual Desktop (HTML5) web client ( http://aka.ms/wvdweb)
Many customers that I work for use web portals that contain tiles to business applications, comparable to the Microsoft My Apps portal, that includes custom tiles to apps they use. To access Windows Virtual Desktop RemoteApps, a common question is whether or not they can be included as tiles on their web portals.
In my search to answer that question, I stumbled upon a tweet of Freek Berson.
#WVD Preview Tip: The RD Web page (https://t.co/NPnKWqQHfR) allows access to RemoteApps & Desktops using #HTML5. Did you know it also has the option 'download the rdp file'? This allows you to leveradge the local WVD client! pic.twitter.com/EFpVehqYzt
Microsoft Rewards
I was very happy to learn that RDP files could simply be downloaded from the Windows Virtual Desktop web client! Straight after reading that tweet, I tried to download the RDP files from the web client. Unfortunately the feature to download them is removed from the web client's interface. Most noteworthy I couldn't find any documentation or comments on why that feature is removed.
At that point I decided to check out the network panel in the Microsoft Edge (Chromium) Developer Tools to monitor and inspect the requests to and responses from the Windows Virtual Desktop web client. So let's take a look at those findings:
Microsoft remote desktop customer Microsoft remote desktop customer is an application used to connect with a laborer running Microsoft remote desktop organizations. In organizations, laborers can partner, access, and control resources in their office-based Windows computers by using Microsoft's remote desktop customer. How secure is Windows Remote Desktop? Remote Desktop sessions operate over an encrypted channel, preventing anyone from viewing your session by listening on the network. However, there is a vulnerability in the method used to encrypt sessions in earlier versions of RDP.
Remote Desktop sessions operate over an encrypted channel, preventing anyone from viewing your session by listening on the network. However, there is a vulnerability in the method used to encrypt sessions in earlier versions of RDP. This vulnerability can allow unauthorized access to your session using a man-in-the-middle attack.
Remote Desktop can be secured using SSL/TLS in Windows Vista, Windows 7, Windows 8, Windows 10 and Windows Server 2003/2008/2012/2016. *Some systems listed are no longer supported by Microsoft and therefore do not meet Campus security standards. If unsupported systems are still in use, a security exception is required.
While Remote Desktop is more secure than remote administration tools such as VNC that do not encrypt the entire session, any time Administrator access to a system is granted remotely there are risks. The following tips will help to secure Remote Desktop access to both desktops and servers that you support.
Basic Security Tips for Remote Desktop
1. Use strong passwords
Strong passwords on any accounts with access to Remote Desktop should be considered a required step before enabling Remote Desktop. Refer to the campus password complexity guidelines for tips.
2. Use Two-factor authentication
Departments should consider using a two-factor authentication approach. This topic is beyond the scope of this article, but RD Gateways can be configured to integrate with the Campus instance of DUO. Other unsupported by campus options available would be a simple mechanism for controlling authentication via two-factor certificate based smartcards. This approach utilizes the Remote Desktop host itself, in conjunction with YubiKey and RSA as examples.
3. Update your software
One advantage of using Remote Desktop rather than 3rd party remote admin tools is that components are updated automatically with the latest security fixes in the standard Microsoft patch cycle. Make sure you are running the latest versions of both the client and server software by enabling and auditing automatic Microsoft Updates. If you are using Remote Desktop clients on other platforms, make sure they are still supported and that you have the latest versions. Older versions may not support high encryption and may have other security flaws.
4. Restrict access using firewalls
Use firewalls (both software and hardware where available) to restrict access to remote desktop listening ports (default is TCP 3389). Using an RDP Gateway is highly recommended for restricting RDP access to desktops and servers (see discussion below). As an alternative to support off-campus connectivity, you can use the campus VPN software to get a campus IP address and add the campus VPN network address pool to your RDP firewall exception rule. Visit our page for more information on the campus VPN service.
5. Enable Network Level Authentication
Windows 10, Windows Server 2012 R2/2016/2019 also provide Network Level Authentication (NLA) by default. It is best to leave this in place, as NLA provides an extra level of authentication before a connection is established. You should only configure Remote Desktop servers to allow connections without NLA if you use Remote Desktop clients on other platforms that don't support it.
NLA should be enabled by default onWindows 10, Windows Server 2012 R2/2016/2019.
To check you may look at Group Policy setting Require user authentication for remote connections by using Network Level Authentication found at ComputerPoliciesWindows ComponentsRemote Desktop ServicesRemote Desktop Session HostSecurity. This Group Policy setting must be enabled on the server running the Remote Desktop Session Host role.
6. Limit users who can log in using Remote Desktop
By default, all Administrators can log in to Remote Desktop. If you have multiple Administrator accounts on your computer, you should limit remote access only to those accounts that need it. If Remote Desktop is not used for system administration, remove all administrative access via RDP, and only allow user accounts requiring RDP service. For Departments that manage many machines remotely remove the local Administrator account from RDP access at and add a technical group instead.
Click Start-->Programs-->Administrative Tools-->Local Security Policy
Under Local Policies-->User Rights Assignment, go to 'Allow logon through Terminal Services.' Or 'Allow logon through Remote Desktop Services'
Remove the Administrators group and leave the Remote Desktop Users group.
Use the System control panel to add users to the Remote Desktop Users group.
A typical MS operating system will have the following setting by default as seen in the Local Security Policy:
The problem is that 'Administrators' is here by default, and your 'Local Admin' account is in administrators. Although a password convention to avoid identical local admin passwords on the local machine and tightly controlling access to these passwords or conventions is recommended, using a local admin account to work on a machine remotely does not properly log and identify the user using the system. It is best to override the local security policy with a Group Policy Setting.
To control access to the systems, even more, using 'Restricted Groups' via Group Policy is also helpful.
If you use a 'Restricted Group' setting to place your group, e.g., 'CAMPUSLAW-TECHIES' into 'Administrators' and 'Remote Desktop Users,' your techies will still have administrative access remotely, but using the steps above, you have removed the problematic 'local administrator account' having RDP access. Going forward, whenever new machines are added in the OU under the GPO, your settings will be correct.
7. Set an account lockout policy
By setting your computer to lock an account for a set number of incorrect guesses, you will help prevent hackers from using automated password guessing tools from gaining access to your system (this is known as a 'brute-force' attack). To set an account lockout policy:
- Go to Start-->Programs--> Administrative Tools--> Local Security Policy
- Under Account Policies--> Account Lockout Policies, set values for all three options. Three invalid attempts with 3-minute lockout durations are reasonable choices.
Best Practices for Additional Security
1. Do not allow direct RDP access to clients or servers from off campus.
Having RDP (port 3389) open to off campus networks is highly discouraged and is a known vector for many attacks. The options below list ways of improving security while still allowing RDP access to system.
Goodtask review. Once an RDP gateway has been set up, hosts should be configured to only allow RDP connections from the Gateway host or campus subnets where needed.
2. Use RDP Gateways (Best Option)
Using an RDP Gateway is strongly recommended. It provides a way to tightly restrict access to Remote Desktop ports while supporting remote connections through a single 'Gateway' server. When using an RD Gateway server, all Remote Desktop services on your desktop and workstations should be restricted to only allow access only from the RD Gateway. The RD Gateway server listens for Remote Desktop requests over HTTPS (port 443) and connects the client to the Remote Desktop service on the target machine.
Utilize Campus RDP Gateway Service. This is the best option to allow RDP access to system categorized as UC P2 and lower. Includes DUO integration. RDP Gateway Service is provided by the Windows Team. Documentation is available here: https://berkeley.sharepoint.com/sites/calnetad/gateway.
The RDP Gateway Service also supports the new Remote Access Services requirement of the draft MSSND update (requirement 8), which requires the use of an approved service (i.e., RDP gateway, dedicated gateway, or bSecure VPN) for access to the UC Berkeley network from the public Internet.
Dedicated Gateway Service (Managed). Needed for rdp access to systems that are UC P4 or higher. Must also be configured for DUO
Some campus units use an IST managed VPS as an RD Gateway. A rough estimate might be that 30-100 concurrent users can use one RD Gateway. The HA at the virtual layer provides enough fault-tolerant and reliable access; however a slightly more sophisticated RD gateway implementation can be done with network load balancing.- Dedicated Gateway Service (Unmanaged). Installing and configuring RD Gateway on department run hardware.
There are many online documents for configuring this embedded Windows 2016/2019 component. The official documentation is here: https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-se..
Installing the configuring, the role service is mostly as described; however, using a Calnet issued trusted Comodo certificate is recommended. Using a self-signed cert is ok for testing, and using a CalnetPKI cert can work if all clients have trusted the UCB root. The Comodo cert is usually better accepted so that your end users do not receive certificate warnings.
Configuring your client to use your RD Gateway is simple.The official documentation for the MS Client is here: http://technet.microsoft.com/en-us/library/cc770601.aspx
In essence, a simple change on the advanced tab of your RDP client is all that is necessary:
3. Change the listening port for Remote Desktop
Changing the listening port will help to 'hide' Remote Desktop from hackers who are scanning the network for computers listening on the default Remote Desktop port (TCP 3389). This offers effective protection against the latest RDP worms such, as Morto. To do this, edit the following registry key (WARNING: do not try this unless you are familiar with the Windows Registry and TCP/IP): HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp. Change the listening port from 3389 to something else and remember to update any firewall rules with the new port. Although this approach is helpful, it is security by obscurity, which is not the most reliable security approach. You should ensure that you are also using other methods to tighten down access as described in this article.
4. Tunnel Remote Desktop connections through IPSec or SSH
If using an RD Gateway is not feasible, you can add an extra layer of authentication and encryption by tunneling your Remote Desktop sessions through IPSec or SSH. IPSec is built-in to all Windows operating systems since Windows 2000, but use and management are greatly improved in Windows 10 (see: http://technet.microsoft.com/en-us/network/bb531150). If an SSH server is available, you can use SSH tunneling for Remote Desktop connections.
5. Use existing management tools for RDP logging and configuration
Using other components like VNC or PCAnywhere is not recommended because they may not log in a fashion that is auditable or protected. With RDP, logins are audited to the local security log, and often to the domain controller auditing system. When monitoring local security logs, look for anomalies in RDP sessions such as login attempts from the local Administrator account. RDP also has the benefit of a central management approach via GPO as described above. Whenever possible, use GPOs or other Windows configuration management tools to ensure a consistent and secure RDP configuration across all your servers and desktops.
By enforcing the use of an RDP gateway, you also get a third level of auditing that is easier to read than combing through the domain controller logins and is separate from the target machine so it is not subject to tampering. This type of log can make it much easier to monitor how and when RDP is being used across all the devices in your environment.
Restrict Access to RDP with Windows Firewall
If you have a campus-managed computer:
- Contact IT Client Services or your departmental IT support for assistance.
If you have a personally-managed computer and Administrator access:
- Follow the instructions in this article to update your Windows Firewall so that only authorized hosts and networks can access your system via Remote Desktop (RDP).
Settings > Update and Security > Windows Security > Firewall and Network Protection > Advanced Settings > Inbound Rules > Remote Desktop - User Mode (TCP-In) > Properties > Scope > Remote IP address > Add > This IP address or subnet
- Settings > Update and Security
- Windows Security > Firewall and Network Protection
- Advanced Settings
- Inbound Rules > Remote Desktop - User Mode (TCP-In) > Properties
- Scope > Remote IP address > Add
- Under This IP address or subnet, only add IP addresses and network subnets that should be authorized to connect to your computer's Remote Desktop (RDP) service. Some common examples of campus IP addresses and subnets are listed in the section below.
Campus IP addresses and subnets
Based on your needs, choose only authorized campus IP addresses and subnets to connect to your computer's RDP service. Network Operations & Services maintains the source list of UC Berkeley Campus Networks, but some common examples are included below for reference.
IST RD Gateway
To access your system via RDP directly from the Internet, utilize the Campus Remote Desktop Gateway. The RD Gateway will allow you to use your CalNet ID with Duo push notifications to connect. You can authorize the RD Gateway by adding the following subnet to your firewall rule:
- 169.229.164.0/24
El capitan os x. Campus Remote Access VPN Networks (bSecure Remote Access Services with GlobalProtect)
To access your system via RDP via the campus VPN, add one or more, as appropriate, of the following VPN networks to your firewall rule:
- Split Tunnel Client Networks
- 10.136.128.0/18
- Split Tunnel Client Networks
- 136.152.16.0/20
- Restricted Tunnel Networks
- 136.152.210.0/23
Campus Networks (onsite)
To access your system via RDP while on campus, add the appropriate campus wireless or wired networks to your firewall rule:
- AirBears2 and eduroam Wireless Networks
- 10.142.0.0/16, 136.152.28.0/22, 136.152.36.0/22, 136.152.142.0/24, 136.152.145.0/24, 136.152.148.0/22, 2607:f140:400::/48
- Berkeley Campus Wired Networks
- 128.32.0.0/16, 136.152.0.0/16, 136.152.0.0/16, 192.31.105.0/24
This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.
If you are using Windows Virtual Desktop, there are two supported options for launching Windows Virtual Desktop resources:
- Using the new Remote Desktop Client (MSRDC)
- Using the Windows Virtual Desktop (HTML5) web client ( http://aka.ms/wvdweb)
Many customers that I work for use web portals that contain tiles to business applications, comparable to the Microsoft My Apps portal, that includes custom tiles to apps they use. To access Windows Virtual Desktop RemoteApps, a common question is whether or not they can be included as tiles on their web portals.
In my search to answer that question, I stumbled upon a tweet of Freek Berson.
#WVD Preview Tip: The RD Web page (https://t.co/NPnKWqQHfR) allows access to RemoteApps & Desktops using #HTML5. Did you know it also has the option 'download the rdp file'? This allows you to leveradge the local WVD client! pic.twitter.com/EFpVehqYzt
Microsoft Rewards
— Freek Berson (@fberson) June 19, 2019I was very happy to learn that RDP files could simply be downloaded from the Windows Virtual Desktop web client! Straight after reading that tweet, I tried to download the RDP files from the web client. Unfortunately the feature to download them is removed from the web client's interface. Most noteworthy I couldn't find any documentation or comments on why that feature is removed.
At that point I decided to check out the network panel in the Microsoft Edge (Chromium) Developer Tools to monitor and inspect the requests to and responses from the Windows Virtual Desktop web client. So let's take a look at those findings:
- First the webfeed is discovered during a query to https://rdweb.wvd.microsoft.com/api/feeddiscovery/webfeeddiscovery.aspx
- When querying the webfeed, it returns all the Windows Virtual Desktop resources, including RDP files!
- Looking further in the network panel, the content of the RDP files is actually being queried for and returned in the response!
I pasted the contents of the response into a .rdp file on a clean instance of Windows Sandbox. Unfortunately, I was unable to launch the RemoteApp.
The .rdpw file extension
If I quote the same tweet from Freek Berson again: 'This allows you to leverage the local WVD client'. That made me think, Windows Virtual Desktop uses a new Remote Desktop Client (MSRDC) as opposed to the Microsoft Terminal Services Client (MSTRC) that I tried to launch the RemoteApp with.
So I installed the new Remote Desktop client into the sandbox. As I'm trying to achieve launching Windows Virtual Desktop resources without asking end-users to open the new Remote Desktop Client at all, I didn't subscribe to the feed.
Microsoft Remote Desktop Rdp Files Downloads
Next I decided to change the default app associations for the .rdp extension to point towards the new Remote Desktop client. When I was about to change the default app association, I found out that there is a .rdpw extension pointing towards the new Remote Desktop client already! Even better, the description matches my intentions too.
Microsoft Remote Desktop Android Rdp File
Therefore I simply rename the .rdp file to .rdpw and try to launch it again.
The very first time opening a RemoteApp from a .rdpw file, you are prompted to authenticate to Windows Virtual Desktop. The credentials you enter will be cached, this does not subscribe you to the feed in the Remote Desktop app, neither will RemoteApps you have access to be added to your start menu.
If you don't have Single Sign On enabled (currently only available using ADFS), a second authentication prompt is shown, which is needed to authenticate to the session host.
NOTE: You can change the workspace id in the .rdpw file to a value of your liking, to display a friendly name when connecting to RemoteApps.
As a result, after you have successfully authenticated, the RemoteApp is launched!
Microsoft Remote Desktop Rdp Files Recovery
Wrapping up
Microsoft Remote Desktop Assistant
Now you've seen that it's possible to retrieve the contents for the .rdpw files from the Windows Virtual Desktop HTML5 Web Client, using the developer tools in your web browser, and that you can leverage the new Remote Desktop Client to launch Windows Virtual Desktop RemoteApps from those files!
