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.

when ACCESS_POLICY_AGENT_EVENT {
  # 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
}
when ACCESS_POLICY_COMPLETED {
  # 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

Conclusion

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

BIG-IP

BIG-IP Access Policy Manager (APM)

news

security

tech tip

v11: RDP Access via BIG-IP APM&ndash;Part 3

Add an iRule Event

Customize RDP Hostname

Testing the Changes

Conclusion

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