« July 2006 | Main | September 2006 »

August 29, 2006

Beware the Repair

A word of warning for all you Web Interface gurus out there:

If you make any changes to the Web Interface 4.0 scripts or image files beyond what is exposed in the Access Suite Console, then be sure to keep a backup of your changes. There are some landmines in the console that could blow away all your script changes if you're not careful, such as the "Repair site" option:

This option effectively deletes and recreates all scripts from the installation source, so any edits other than what goes in WebInterface.conf will be lost. This is also true if you use the "Manage IIS Hosting" task to move the site from one path or one IIS virtual site to another.

Read on if you'd like more information on why this is the case and how to maintain your changes in spite of repair or move tasks.

On your WI4 server, take a look inside the Program Files\Citrix\Web Interface\4.2 folder. You should see a file called wi.zip which contains all the scripts and image files for a default Presentation Server site.

Whenever the repair option is performed in the Access Suite Console, here's what happens:

  1. A copy of the configuration (WebInterface.conf) is set aside for safe keeping
  2. The existing script files located beneath your wwwroot folder are deleted along with all IIS metabase settings
  3. The scripts from the wi.zip file are extracted and placed beneath wwwroot in the path you selected, and IIS metabase settings are recreated
  4. The configuration file from step 1 is restored

So if there are any changes to the ASPX scripts, include files or image files you would like alway to be a part of your Web Interface site, just open up that wi.zip file, make the changes there, then recompress it. After doing that, any new site you create will contain your edits and the repair/move options in the Access Suite Console won't destroy your changes.

There are also a couple other zip files in there: mcm.zip for Conferencing Manager sites and pna.zip for Program Neighborhood Agent sites. Common.zip contains all the DLL's that drive the Web Interface objects.


August 15, 2006

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:

  1. In AAC, create an Endpoint Analysis (EPA) scan that checks the client for Symantec
  2. Define a filter that will be true only if the EPA results are positive
  3. Create a Presentation Server policy to disable client drive mapping when the filter is not true
  4. 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.


August 09, 2006

Thoughts on the Orbital Data acquisition

On Monday Citrix announced that it had signed an agreement to acquire privately-held Orbital Data, a network appliance builder out of San Mateo, California. This makes the fourth Citrix acquisition of Silicon Valley appliance makers (Net6, NetScaler, Teros and now Orbital Data).

How does this box fit in with the rest of Citrix?

Citrix WANScaler

Citrix NetScaler already optimizes traffic to web browsers, relying on standard HTTP optimizations that are available in all modern browsers and by tuning the TCP connections to the client and back-end web servers. When users go through a NetScaler device to access a web server farm, they get better performance without having to install any software on their client machine. This asymmetric aproach is perfect for dot-coms like Google or MySpace who need to push out tons of HTTP traffic to anonymous clients all over the web.

But what about non-HTTP traffic? NetScaler can't really help there unless you are using it as an SSL VPN. The NetScaler SSL VPN client can perform multi-protocol compression. What about, for example, users in a branch office who need access to file servers at the company headquarters? It would be overkill to make all the branch office users log into an SSL VPN when there's already a WAN link in place.

That's where Orbital Data fits in. It's a symmetric solution, where you put one box in HQ and then another box at the branch office. The two Orbital Data devices perfrom site-to-site traffic optimization for any protocol. Its transparent "bump-in-the-wire" architecture means that clients in the branch office and servers at HQ need no software to get the benefits.

If you've worked with Citrix for a while, you already know that one of our core compentencies as an organization is rapid and frequent product renaming. ;-) We've already got a brand new brand name in mind for the Orbital Data boxes: Citrix WANScaler. I think this is a perfect name actually, it rolls off the tongue and conveys its purpose succinctly.

How does this mesh with the Citrix VOS strategy?

Citrix is all about delivering applications to users. For the past year or so we have been communicating a three-pronged approach for dealing with three different types of applications:

  1. Virtualize client/server applications with Presentation Server
  2. Optimize web-based applications with NetScaler
  3. Stream desktop applications with Project Tarpon

WANScaler will extend the "Optimize" message to embrace more than just HTTP traffic. It optimizes traffic on WAN links between offices within an organization. There's a nice little Powerpoint presentation posted on citrix.com that summarizes the WANScaler benefits and how it fits in with the rest of our VOS strategy.

What does WANScaler have to do with Presentation Server?

Not much really. The ICA protocol is already highly efficient and compressed so there's not a tremendous amount of value that a network appliance can add. The sweet spot for Orbital Data is optimizing traffic for applications and data that would otherwise use overly chatty protocols that run like molasses over a high-latency WAN link (like CIFS). However, most WAN links are not dedicated to ICA traffic, and by optimizing the other protocols on the WAN link, more room will be left over for ICA traffic. So Presentation Server users may notice better performance too by virtue of having a WAN link that is less congested.

I think this is a good move for Citrix, and one that was widely anticipated.


August 04, 2006

Java Client 9.4 released

Attention ICA Java client users! Citrix just posted version 9.4 of the ICA Java client libraries:


Apart from the various enhancements laid out in the readme, this version of the Java client has been signed by a more recent certificate. The 9.3 code signing certificate expires tomorrow, August 5, so upgrade today to avoid certificate warning messages.

August 02, 2006

Citrix ships Access Gateway 4.2.3

Today Citrix posted a new hotfix for Access Gateway, which brings the current version up to 4.2.3:

v4.2.3 Hotfix for Citrix Access Gateway

The article lists 20 issues resolved by this hotfix. I thought I would spend a moment talking about #16:

16. Session reliability sessions are dropped when the Secure Ticket Authority (STA) is restarted. (TT23204)

As you probably know, the Secure Ticket Authority creates a one-time-use ticket that allows the user to connect through the gateway en route to a Presentation Server. If the gateway can validate the ticket, then the traffic is allowed through and that ticket can never be used again. So why would restarting the STA affect sessions that are already established?

The answer lies in how Session Reliability is implemented for Gateway connections (Secure Gateway or Access Gateway). The requirement for session reliability is that if the user's network connection is severed, we should be able to create a new ICA+SSL connection through the gateway and get reconnected to the Presentation Server session without the user having to re-authenticate. But how do we pull that off if the original connection ticket from the STA has already been used?

When a user opens a connection through the Gateway with session reliability enabled, the gateway first validates their connection ticket as before, but then immediately requests a 2nd ticket from the STA. This 2nd ticket is a reconnection ticket, which is sent down through the CGP protocol to the end user. This reconnect ticket is only used if the connection gets broken and the user needs to re-establish their transport-layer connection to the gateway.

Tickets issued by the STA naturally expire after a fixed amount of time--for reconnect tickets I believe the default is 500 seconds. At some point before that 500 second window expires, the gateway needs to "refresh" the reconnect tickets of all the users who are currently connected. So the gateway will periodically check back in with the STA to perform ticket renewal for the connected sessions. When this happens, you'll see an entry such as this in the Access Gateway system log:

(07/15/06 19:44:10):server:sta_proto: Entering renew_sta_tickets

The STA needs to stay alive for this to succeed, because the reconnect tickets are not persisted to disk; they are just held in memory at the STA. If you bounce the XML service or reset IIS on the server acting as the STA, you will flush all the current tickets from memory and and all the users who were relying on those tickets will sacrifice their reconnect capability.

Now here's the bug that was fixed in 4.2.3: when the Access Gateway failed to renew a reconnect ticket at the STA, it would forcefully disconnect the user's session instead of allowing them to remain connected minus the session reliability feature. The corrected behavior is that users will not lose their session because of a ticket renewal failure, but instead they will only lose the ability to withstand brief network outages.