v11: RDP Access via BIG-IP APM - Part 1

I wrote an article several months back on auto-launching Remote Desktop sessions with APM.  With the introduction of BIG-IP APM v11, there is a new built-in capability to support a full webtop.  This means that server, desktop, or other resources can be placed on the webtop for users to select once logging in.  In this first example, I’ll set up a static internal resource for users to connect to after logging in.

Create the Webtop

After logging in to the BIG-IP, open up the Access Policy tab and select Webtops->Webtop List and then click Create (or you can hit the “+” circled to the right of the Webtop List.) Give the Webtop a meaningful name and the type needs to be Full as show in Figure 1.

 

 

Create the RDP Resource

Still in the Access Policy tab, click Application Access->Remote Desktops->Remote Desktops and then click Create. There are a number of fields here, but for this example the only ones that need to be set are the Type (RDP), the Destination (Server or Desktop hostname or IP), and Auto Logon (Enable). When Auto Logon is selected, the username, password, and domain source variable fields are shown.  I accepted the defaults.

 

 

Create the Access Policy

Now that the two custom objects for the RDP Webtop are created, I’ll create the access policy (and virtuals) with the Network Access Setup Wizard for Remote Access under the Wizards tab. I create all my access policies this way, the wizard is very thorough and eliminates my tendency to overlook an object or misconfigure one, not to mention the time savings. In the first screen, I disabled AV checks (though in production I wouldn’t recommend this) as shown in Figure 3 below.

Next I create a new authentication resource (you can select existing if this is not a new installation), utilizing my test active directory server.

Next I configure the lease pool.  It’s just me in my test lab, so I only create a single client address, but you’ll likely need to choose the IP address range.

The next step is for network access configuration.  Corporate policies will dictate whether all traffic is forced through the tunnel or if split-tunneling is appropriate. For this example, I stuck with forcing all traffic through the tunnel to minimize the necessary configuration to show the features.

I only have one name server, my ad01 directory server, so I enter that and leave the rest blank.

 

 

Next I’ll enter the VIP address and leave the http->https redirect virtual enabled.

At this point, I review the configuration and click next.  If there are any errors, you can return to previous steps in the wizard and make corrections. Before clicking Finished in the next screen, I need to edit the access policy.

Once in the policy editor, click on the Logon Page object and set Field 3 from none to text and use domain as the post and session variable name.  Then below in the Logon Page Input Field #3 text box, enter Domain.

Next, click on the Resource Assign object and then click Add/Delete in the expression. I need to replace the webtop the network access wizard created and I need to select the RDP Resource I created.

 

 

 

 

Close out the policy and then click Finished in the Setup Summary screen. For my configuration I need to snat the traffic, so I enabled snat-automap on the virtual created by the wizard. Because I made changes to the policy, I need to re-apply it, so in the Access Policy tab I clicked on Access Profiles and then selected my profile and clicked Apply Access Policy.

That completes the configuration steps. Now it’s time to test.

Testing the Configuration

First I open a browser and navigate to my vip, https://10.10.20.30.

After login, my RDP resource is shown on my Webtop, along with my network access.

After clicking the rdptest icon, I am logged in automatically to my server.

 

 

It seems like a lot of steps, but I configured this in less than five minutes, which is far more efficient and far less error-prone than the previous solution. The video below shares the same steps covered here in screen captures.

Conclusion

This solution introduces a full Webtop environment for BIG-IP APM in version 11, which I took advantage of for statically configuring RDP resources for clients.  In part 2, I’ll introduce a dynamic option for the RDP resource.

 
Published Sep 13, 2011
Version 1.0

Was this article helpful?

7 Comments

  • Is it possible to use digital certificates for user authentication, and if so, could it be with self-sing certificates?. Regards
  • Yes, it can be done with self-signed certificates, or you can combine certs and username/password auth for stronger security.
  • Is it possible to hardcode the domain section? Dont want user to type in the domain.
  • just eliminate the handling of the domain altogether if you don't need to offer it as a selectable option
  • Jason, we use RSA servers as RADIUS AAAs, and users access via a fob (or soft token). In this setup, our users login with their RSA credentials (a PIN they setup, and the currently-displayed random number on their fob/token), then click on the RDP icon - after which they have to enter domain credentials. In this configuration, is it possible to set auto-login to log them into the RDP server? I'm ok with hard-coding the domain, but using RSA as the AAA server, the user's domain userid/password aren't in the session, correct? I'm guessing that we'd either have to configure the RDP server to also use the RSA device for authentication, or configure the portal to use AD for authentication, the way you show above. But maybe i'm wrong - is there any way to auto-login given the session variables in play after an RSA-based portal authentication? thx!
  • I'm curious as to the purpose of the Network Access resource that shows up on your WebTop. Is it a requirement to get your rdptest Application Tunnel working?
  • Is it possible to load balance against multiple RDP servers, essentially creating a VIP or pool for the RDP boxes on the WebTop?