Working with APM Webtops–Part 1

Last fall I released a series of articles on configuring APM for remote desktop access:

These are great starter articles into the power that APM offers in presenting a user with a method to get to their desktop. But if the user just needs to get to the file system for a file, or check mail via OWA, launching the desktop is a little much. In part one (of two) of this series, I’ll expand on the function of the webtop to include web portals and network access.

Solution Overview

I’m going to create a webtop with 5 objects:

Outlook Web Access
Spiceworks Web Interface
Cacti Web Interface
Remote Desktop Link (custom to each user utilizing an Active Directory attribute)
Network Access

The Components

There are several components that make up the core of this solution. I’ll start with the access profile and build from there. Before creating the profile itself, I’ll work on the various objects that comprise the profile, starting with the AAA Server. There are many options on this front (ldap, radius, tacacs, etc). My authentication of choice for this article is Active Directory. I create the auth server by clicking the plus on the Access Policy –> AAA Servers –> Active Directory menu item.

You can specify a domain controller, but if you leave it blank, the APM will pick up the domain controllers for your domain and give you some redundancy. Next, I create a full Webtop.

I disabled the Minimize To Tray setting (enabled by default) to workaround an issue with Firefox version 9 as described in Solution 13319. Now I create the first of three Webtop links.

I create two more for my Spiceworks and Cacti management tools web interfaces, at which point I have three Webtop links.

Now I create a lease pool for my remote access clients.

After that, I create my network access list.

Once the network access list is created, I configure the ip verion, selecting my lease pool and selecting split tunneling to avoid non-essential traffic traversing the tunnel. I specify the domain used internally by *.local.domain.

Now I specify the name servers and the default domain suffix.

There are other options I’ll cover in part 2, but for now I click update on the network access list and move on to create the connectivity profile.

I didn’t change any of the customizations, I only specified custom in the event the parent is changed this profile will remain as is. Next, I create the remote desktop application.

I have stored the desktop name of each AD user in their description attribute so it can be retrieved by APM in the AD Query object in the visual policy. The Session variables are supplied by the user in the logon page. Now that all my helper objects are created, I can create the access policy.

All my users are english speakers only, so that is the only language I enable. After creating the access profile, I begin the visual policy definition. The first thing I add is a geolocation check. None of my users connect outside the US, so I add the default geolocation check, which results in the policy below.

After the gelocation check, I add a logon page. I’m using the domain information for autologon purposes for users, so I specify that field in the logon page before clicking save

After my logon page, I add an AD Auth object, selecting the active directory AAA Server I created earlier.

Immediately after the AD Auth object, I add an AD Query object. Like the AD Auth object, I select the same AAA Server. I also set the search filter to pull out attribute information on the current user.

Still in the AD Query, I delete the Primary Group ID branch rule, leaving only the fallback before clicking save.

Next, I add a Full Resource Assign object immediately after the AD Query object. In this object, I select all the objects I created earlier (webtop, webtop links, and network access and remote desktop resources)

After flipping the fallback of the Full Resource Assign from Deny to Allow, my visual policy is as follows:

And that completes the heavy lifting. Now I just need to create a certificate, and a clientssl profile, then apply the new ssl profile, an http profile, the access profile, and the connectivity profile to a virtual server and I’m ready to test this out.