How to: Extend SmartAccess Policies to ICA Sessions
You probably have heard by now that Access Gateway includes an Endpoint Analysis feature (EPA), and that you can enable or disable access to resources based on the results of EPA scans. But one side of this story that I don't feel is told often or clearly enough is how Presentation Server can respond to the EPA scans by showing or hiding certain applications, or by enabling/disabling ICA virtual channels.
The Access Gateway Advanced Edition page on citrix.com says:
Extensive SmartAccess capabilities allow administrators to define granular access policies, allowing the system to automatically adapt as users move between access scenarios.
And the following is listed as a key feature:
Advanced Citrix Presentation Server™ integration Further secure the environment with policy-based control of Citrix Presentation Server published applications, using end-point analysis and location awareness. Advanced policies allow control of capabilities within a Presentation Server session, including local client drive mapping, clipboard operations, and local printer mapping.
To translate this from brochure-speak into more tangible IT terms, let’s walk through the configuration steps that would be required for a real-world example:
"When my users log into their Presentation Server applications, I want to disable some ICA virtual channels like client drive mapping, client clipboard mapping and client printer mapping if they are logging in from a workstation that does not have Symantec Antivirus installed with a pattern file from August 15, 2006 or later."
We need to do four things in order to make this work:
- In AAC, create an Endpoint Analysis (EPA) scan that checks the client for Symantec
- Define a filter that will be true only if the EPA results are positive
- Create a Presentation Server policy to disable client drive mapping when the filter is not true
- Create a Presentation Server policy to enable client drive mapping when the filter is true
Create the EPA scan
Fire up the Access Suite Console on your AAC server and create a new Endpoint Analysis scan for Symantec. You're prompted to select the conditions when this scan should run: you can choose to have it run for all logon points and all client operating systems, or you can be more selective and make the scan run only on English Windows XP when the user hits an External logon point. You're then asked for the minimum required pattern file version, in the form YYYYMMDD.NNN:
Once the scan is created, users will download and run the EPA client when their OS, language and logon point conditions match the conditions that you defined for this scan. The results of the scan are sent back to the server before the user logs in.
Define an AAC Filter
Now that the EPA scan has been defined, you can create a filter that will be true only when the scan is true. In the Access Suite Console, click Create Filter and give your new filter a name: Antivirus Verified. Apply the filter to all your logon points and then select the Symantec EPA output:
This filter will only be true if the Symantec EPA scan passes successfully.
Presentation Server Policies
This is probably the trickiest part if you’ve never seen it done before. Filters are Boolean conditions that are associated with a user’s Access Gateway session, and a user’s filter list is passed to Presentation Server when they request their application list or request an application launch. But here’s the catch: only the filters that evaluated to True will be sent to Presentation Server. Filters that were not satisfied simply aren’t included in the information sent to the CPS XML broker. Because of this little twist, we can’t just write a policy that disables client drive mapping and tell CPS to enable the policy whenever that filter is false. We could perhaps define an advanced “inverse filter” where the result of the inverse filter is always the opposite of the original filter, but that’s not the most elegant approach and it would get to be an administrative headache as the number of AAC filters increases.
The better approach is to mirror in your CPS policies what AAC does with its resources: deny access by default and then pile on access policies that are only effective when a filter is true. To implement this strategy in CPS, you must first create a policy that represents the bare minimum privileges that you want users to have when they connect from a dirty machine and apply it to all Access Gateway users by default. Let’s call this the RestrictiveICA policy, and we’ll configure it to disable all client device mappings.
Right-click the policy and select Apply this policy to…
If you want this policy to apply only to users of Access Gateway, clear the “Apply to all other connections” box:
That will exclude your internal Web Interface and PNAgent users who are not connecting from the outside. (But in my opinion, location is no guarantee of security, so you should consider using AAC for all connections, even users who are at their desk on the LAN.)
Now you’ve got a CPS policy that locks down the ICA virtual channels for everyone by default. Next, create a more lenient CPS policy that turns the virtual channels back on. We’ll call this one Full ICA.
Watch out for the double negatives in the policy settings here. For example, in order to enable client clipboard mapping, you need to disable the policy setting that turns off client clipboard mapping.
Use the up/down arrows to move the Full ICA policy higher in the priority ordering, so that when it is effective it will override the settings in the RestrictiveICA policy.
When you choose whom to apply the policy to, add the AAC farm name and filter name so that the policy is effective only when the "Antivirus verified" filter is true.
And you’re done! When a user logs in from a machine without Symantec, only the RestrictiveICA policy will apply to them and their client device mapping virtual channels will be disabled. When they log in from a machine that has Symantec, both the RestrictiveICA policy and the Full ICA policy will apply to them, but settings in Full ICA can override settings in RestrictiveICA.
There's one other item that you need to take care of for this to work: enable the "Trust requests sent to the XML service" setting on each Presentation Server. The reason for this is that AAC and/or Web Interface will relay the filter list to the XML broker during app enumeration requests and ticket requests. If you wanted to really lock things down, you would set up IPSec policies or IP filtering rules to allow only trusted WI or AAC servers to send those requests.
Jay