v11: RDP Access via BIG-IP APM–Part 3

In Part 1, I configured a full Webtop in APM with a static RDP host. In Part 2 ,I modified that configuration to allow users to specify their RDP destination. In this article, I’ll make a couple changes to the final configuration in Part 2 to have the last hostname “remembered” across sessions.

Add an iRule Event

Yes! Finally an iRule in this series. In order for an iRule to be triggered, however, I need to add an iRule event to the policy. Why do I need an iRule? Well, in order to recall the previous session’s hostname, I need to store it somewhere. In this case, I’ll be using the BIG-IP session table, accessing it with the table command. I’ll add the iRule event immediately before the RDP Hostname page so the previous hostname can be displayed there if applicable. I gave the event an ID of 1.

The iRule itself is pretty simple.  Set the user to a variable, which becomes the table key for the user’s rdp host destination. If it’s there, it’ll be pre-populated, otherwise, it won’t. In the completed event, it’s much the same except the hostname is stored instead of being looked up.

  # This event runs immediately before the RDP Hostname logon page
  # Grab username entered on the logon page
  set user [ACCESS::session data get session.logon.last.username]
  # Look up in session table to see if a hostname is already saved for a user
  set hostname [table lookup $user]
  # Pre-fill the hostname session variable (to be shown on the RDP hostname entry page)
  ACCESS::session data set session.logon.last.hostname $hostname
  # This event runs after the RDP hostname entry page
  # Grab username entered on the logon page
  set user [ACCESS::session data get session.logon.last.username]
  # Grab hostname entered on the RDP hostname entry page
  set hostname [ACCESS::session data get session.logon.last.hostname]
  # Save this in the session table (does not time out)
  table set $user $hostname "indefinite"

Once the iRule is saved to the system, it should be applied to the rdp virtual as shown in Figure 2.

Customize RDP Hostname

Before the auto-population will work, I need to comment out a few lines in the logon.inc file for the RDP Hostname logon page to make sure the field is always auto-populated (even with an empty string). To get to the file, I click the Access Policy tab in the menu and then Customization and then expand out Customization Settings->/Common/rdptest->Access Policy->RDP Hostname. Click on Views at the top and select Advanced. Click logon.inc under RDP Hostname and then comment out the lines selected in Figure 3.

After clicking Save Draft then Save, I navigate to Access Policy->Access Profiles and click Apply Access Policy to update the changes.

Testing the Changes

Now that the policy is applied, I can login and see that the field on first attempt is empty.

On the second time through, I see that the hostname I selected is pre-populated as expected.

I added a log statement to each of the iRule events to track the table key/value pair. For first time through, notice the  host is empty on the ACCESS_POLICY_AGENT_EVENT, but is populated by the time the policy completes:

Oct  4 11:18:03 tmm info tmm[19079]: Rule /Common/rdptest_autopopulate <ACCESS_POLICY_AGENT_EVENT>: User=dc.user, Host=
Oct  4 11:18:12 tmm info tmm[19079]: Rule /Common/rdptest_autopopulate <ACCESS_POLICY_COMPLETED>: User=dc.user, Host=ad01.devcentral.test.local


All three parts of this series explored the Webtop functionality and different ways to customize the approach for user access to Windows resources secured by BIG-IP Access Policy Manager.  Many thanks to James Goodwin and the APM team for great source material and continued development of excellent access solutions.

Related Articles

Published Oct 04, 2011
Version 1.0

Was this article helpful?


  • Hello,


    I've been using this for a long time but it looks as if there's some issue if you try it with 11.4.1


    Once I type the IP address of a PC the link appears but when I click it , the new window appears, tcpdump shows RDP traffic, it says that it's connecting with the server but finally it doesn't work and the system fails:


    Jan 22 14:56:45 sherlock emerg logger: Re-starting tmm


    Jan 22 14:56:46 sherlock emerg logger: Re-starting tmm1


    Jan 22 14:56:46 sherlock emerg logger: Re-starting tmm2


    Jan 22 14:56:46 sherlock emerg logger: Re-starting tmm3


  • JRahm_128324's avatar
    Historic F5 Account
    hi Manuel, I'd open a case on that, and when you do, can you email me the case number at j dot rahm at f5 dot com? Thanks, Jason
  • we had a similar issue with application tunnel in v11.4.1 hf2. When traffic when through the tunnel, tmm crashed.


    We've got from support an EngHF 635.10 containing 5-6 bugfixes.


    Maybe you should request it opening a support ticket.