Hitting the Easy Button: Securing the Remote Desktop on F5 BIG-IP APM
Being able to provide the most effective remote access solution is critical, especially in these turbulent times. In this article printed with permission from authors Lucas Thompson & Michael Waechter, we're going to talk about Remote Desktop Web Access.
Solution Brief
In short, it enables end-users to access their Remote Desktop applications through the F5 APM Webtop. The benefits of utilizing Remote Desktop Web Access over a desktop can be many.
With the only requirement being a compatible web browser, Microsoft RDP application (comes installed with all modern versions of Windows), and a backend server hosting the applications… the solution speaks for itself.
When the Full Webtop is displayed, APM will fetch a list of RemoteApps available on the target Terminal Server via HTTPS (using the Server SSL profile on the APM virtual server) and the associated icons. They will then be presented to the end user. The connection is done over HTTPS to the APM, and APM uses RDP (port 3389) to the Terminal Server. In the classic Terminal Server Desktop use case, the user is assigned a ‘native’ type RDP resource. This icon is presented to the user on a Full Webtop. Access is made by selecting the icon. A .RDP file is downloaded to the end user client PC, and the browser will activate the OS’s native RDP client to proceed with the connection. The connection is done over HTTPS to the APM, and APM uses RDP (port 3389) to the Terminal Server.
Not only is the client setup simple, but the administration part of the equation is equally as easy to enable. I’m running version 14.1 (LTS) and here are a few screenshots of the setup.
To enable the solution, let’s click on Access -> Connectivity/VPN
Go ahead and choose VDI/RDP -> Remote Desktops
Add the relative information. (Note: It’s always best to have the host name be a FQDN, and add this as a LTM node for health monitoring.)
Technical Workflow
The user clicks a resource icon on the Full Webtop, an RDP file is downloaded and then executed by the TS client on the user’s PC. The RemoteApp use case has a few differences versus targeting a desktop, or terminal server directly. In this case APM Will:
- Obtain a list of the RD feeds.
- The list of RDP App Resources will be derived from the RemoteApp feed.
- The list of icons will be delivered to the end user’s browser.
- The end user’s browser will request the icon pictures via a proxy mechanism in the VDI module.
- Because the RemoteApp feed comes through HTTPS and IIS on the Terminal Server, we have to make sure that:
- BIG-IP data plane can route to the Terminal Server.
- BIG-IP can create a HTTPS connection to Terminal Server.
- Terminal Server is rendering the page correctly. When you browse to it (https://terminalserver/rdweb/) you should see something like this:
2008:
2012:
- Authenticate with the same credentials that the test user uses in APM, and you should see an App Feed or desktop feed:
Solution FAQ
What kind of licenses are used for RDP access?
APM has two license types: CCU and Access Session. Access Sessions are used for each established session ID. CCU are used for Network VPNs and other things that require more advanced features. Native Mode RDP does NOT use a CCU (connectivity) license. Only a single Access Session license will be consumed by a connecting user.
What RDP options are supported?
All of them. They’re basically echoed back to the client in the .RDP file. Put your desired parameter into the Custom Parameters area. It’s OK to use session variables in %{session.variable} format as well.
RDP Custom Parameters configuration Lists of the RDP options have been compiled by 3rd parties, including the one at https://www.donkz.nl/overview-rdp-file-settings/ which is quite comprehensive.
Please note that the following options are reserved for APM RDG use. If you attempt to apply these custom parameters, they will be ignored and/or overwritten by APM:
- Gatewayusagemethod
- Gatewayprofileusagemethod
- Gatewayhostname
- Gatewaycredentialssource
- Gatewayaccesstoken
- authentication level
- full address
- server port
- enablecredsspsupport
- signscope
- signature
- prompt for credentials on client
- domain
- username alternate full address
- gatewaybrokeringtype
RDP Window Title
The maximized window title for MSTSC inherits the target device name (not the RD gateway host). The medium-sized window title for MSTSC inherits the RDP filename (which is always “launch” -- see RFE 610244). One interesting thing that is possible is to internally-redirect the RDP session so that the client THINKS its connecting to one site, but then re-assign the remote host variable to a different site during the RAP access policy execution.
RemoteApps
It’s possible to create a lot of apps by using a PowerShell script on a RemoteApp-enabled terminal server.
Client Requirements
Microsoft Remote Desktop Client is supported for both Windows and Mac. Because the protocol used utilizes the Remote Desktop Gateway functionality, only newer RDP clients work. Legacy clients will likely not be able to create connections.
iOS/Android
The latest iOS / Android App Store RDP clients from Microsoft are supported. There might be some version conflicts, but for the most part the latest and greatest will work
Reconnections / Disruptions Reconnections work the same as normal RDP
If the user disconnects and reconnects, the session will be resumed. The client instructs the RD Gateway (APM) to again establish the session. The Remote Desktop session will be resumed also, the same way as with normal RDP. If the session is deleted or timed out or otherwise destroyed, the connection will stop, RDP will try to reconnect, but it will fail, and you will see this message from the MSTSC client.