Main | August 2006 »

July 28, 2006

See you at iForum 2006

Citrix iForum 06

Lots of Citrites, myself included, are gearing up for our annual end user event called iForum. Last year it was in Vegas and this year it will be back in Orlando at the Walt Disney World Swan & Dolphin.

I'm going to be a co-speaker for this breakout session:

Integrating and Customizing the Web Interface of Citrix Presentation Server
Sunday, October 22: 2:30pm – 3:50pm
Dolphin Hotel – Southern Hemisphere Ballroom III

And repeated:

9:30am - 10:50am Tuesday, October 24, 2006
Dolphin Hotel - Northern Hemisphere Ballroom D

I'm also teaching one of the Hands-on Technical Workshops, which are 3-hour mini-courses with hands on labs. My workshop is session #5:

Implementing and Administering Citrix Access Gateway Advanced Edition

If you think you might be interested in registering for any of the hands-on workshops, I suggest you do so quickly because some of the sessions are already sold out.

Hope to see you there!

July 26, 2006

ClientName issue resolved?

If you use Web Interface 3.0 or later, and especially if you work in health care, you have probably noticed that connections made to Presentation Server via Web Interface don't use the client's workstation NetBIOS name as the Presentation Server ClientName variable. Instead, it's a random string such as WI_e5KPgXSIWWtOWAQTg. This change was introduced as part of the Workspace Control feature that allows users to roam from device to device and have their Presentation Server sessions automatically reconnect when they roam from one workstation to another.

But there was a regrettable side effect of leveraging the ClientName variable for unique device identification: some applications, particularly health care apps like Epic, relied on the %CLIENTNAME% environment variable to pinpoint a user's location based on a database of known NetBIOS workstation names. If you run an application in your CPS farm that relies on the "real" client name, then you are left having to choose between application compatibility and workspace contol. (And app compatibility always wins!)

Let's take a look at how we got into this mess and how we're going to get out of it.

How we got into this mess

Long before Citrix released NFuse or Web Interface or even Program Neighborhood, we supported the notion of session reconnection. In a load-balanced WinFrame 1.7 farm for example, if you had a disconnected session and you connected to a published application, the load balancing algorithm would put aside the normal load metrics and send you to the server where your session resides, regardless of how busy that server was.

The thing is, the load balancing decision had to be made before you authenticated. (Remember this was before Program Neighborhood, back in the days of Citrix "Application Manager", which would give you a drop-down list of all published applications, whether you had permission to connect to them or not.) So to get you sent back to your disconnected session, the master browser would associate your workstation name with the disconnected session. When the client requested the address of the least-busy server, the workstation name would be included with that request. If there was a disconnected app associated with that workstation name, then that's the server you got sent to. Then if you authenticated as the user with a disconnected session, you would get reconnected. Otherwise you'd get a new session on what might have been the busiest server in the farm.

Flash forward to 2004 and the ClientName mechanism is still in place, but most people now use Web Interface for published application enumeration. While developing the Workspace Control feature, the WI developers needed a way to distinguish between a CPS session that is spawned for Uesr1 on Workstation A from a session spawned by that same user on Workstation B. To do so, WI generates a random string such as e5KPgXSIWWtOWAQTg and sets it as a cookie in your browser. When WI renders an ICA file, it adds the line ClientName=WI_e5KPgXSIWWtOWAQTg to mark that session. This was the only way at the time to uniquely associate a browser-to-WI connection with an ICA Client-to-Presentation Server connection.

Now when you look at the client name in the Presentation Server console or by querying the %CLIENTNAME% environment variable within a session, you'll see something like WI_e5KPgXSIWWtOWAQTg instead of the real workstation name. If your app needs to know the real client name, the only workaround was to remove the ClientName tag from the Web Interface template so that the ICA client would send its normal string during ICA connections. But that breaks workspace control, because there's no secure, reliable way for a web server to know the name of your workstation.

Thomas Koetzing wrote a good article about the ClientName problem a while back. After WI 3.0 was released I wrote an article that discussed the negative effects of removing the ClientName tag.

How we're going to get out of it

To fix this problem, Web Interface needs to uniquely identify each workstation without relying on the ClientName variable and without knowing what the real workstation name is. For the next release of Presentation Server, the WI dev team in Cambridge has devised what I think is an elegant solution: they will leverage the ticketing model that we already use during authentication.

Recall that when a user authenticates to WI and launches a published application, the WI server performs a ticket request, where the user's credentials are sent to the XML broker, the XML broker relays the credentials to the least-busy server and then the least-busy server generates a random ticket that can be used by the ICA client for authentication. The ticket is passed back to Web Interface and included in the rendered ICA file. See section 5.4 of the Web Interface 4.0 Troubleshooter's Guide for a detailed look at how ticketing works.

Web Interface will still generate a random string to identify each workstation and set it as a cookie in the browser. But instead of jamming it into the ClientName field, the ID will be passed to the XML broker along with your credentials during a ticket request. When you land on the target server and present your ticket, it now knows who you are and knows the WI-generated ID of your workstation. If you disconnect, it can use that information where it would have used the ClientName variable before.

This is going to be a fairly big change. It requires modification not just of Web Interface, but the XML protocol used between WI and Presentation Server has to be extended to support the enhanced ticket request, and the IMA and Load Management underpinnings on Presentation Server have to be modified to use this new XML element. So older Presentation Server farms won't be able to benefit. Fortunately, there are no ICA client dependencies here, so you will only have to upgrade your farm and your WI servers--not every end user client--in order to get this benefit.


July 21, 2006

Certificate conversion tool: pfx2pem

Here's a pretty typical stubmling block you might run into if you want to migrate from Secure Gateway servers to an Access Gateway appliance: Your Secure Gateway server running Windows already has a certificate installed and you'd like to re-use that certificate on the Access Gateway appliance instead of paying for a new certificate. But the Secure Gateway certificate is buried in the local machine store of a Windows box and the Access Gateway expects a certificate and private key in the UNIXy PEM format. How can you get that certificate and private key off the Windows box and onto the CAG?

Hopefully, when you originally requested the certificate for your Windows server, you enabled the "Mark keys as exportable" option. If not, you are out of luck here because the private key associated with your server certificate is now imprisoned on that Windows box. But assuming the private key is exportable, you should be able to view the certificate in the Certificates MMC snap-in and export it out to a file.

When you export the certificate, you'll be asked whether you want to export the private key as well, and prompted for a password to protect that private key. (This option is greyed out when the key is not exportable.)

This export process produces a file that has a .PFX extension. PFX is short for Personal inFormation eXchange. I'm not sure why Microsoft didn't just go ahead and use the .PIE extension here. I mean, everybody loves PIE, right?

The PFX file format is also known as a PKCS#12. It's a secure envelope that contains both the certificate (public key) and its corresponding private key in a single file. Guard these sorts of files carefully, because if they fall into the wrong hands, they can be used to impersonate your server on the Internet. That's why you are prompted for a password when the file is created--when you know the password you can install this certificate onto any other server.

Access Gateway expects certificates in PEM format, which is a Base64-encoded text file. Open up a DER-encoded certificate or a PFX file in Notepad and you will see jibberish because those are binary file formats. But a PEM-formatted certificate is readable and easy to send over e-mail, like this:


When you upload a certificate to Access Gateway, it expects it to be in this PEM format. AG also expects the private key to be in the PEM file as well, so a proper PEM file for AG 4.2 would look something like this:

Bag Attributes
localKeyID: 01 00 00 00
Microsoft CSP Name: Microsoft RSA SChannel Cryptographic Provider
friendlyName: 8d790ff1becfddffad82a49ecf38a234_ef64343b-cae7-4db9-8025-eec430840df7
Key Attributes
X509v3 Key Usage: 10
Bag Attributes
localKeyID: 01 00 00 00
subject=/C=US/ST=Florida/L=Fort Lauderdale/O=Citrix Systems/OU=Technical Support/
issuer=/DC=ctx/DC=gemini/CN=Citrix iForum 2004

Access Gateway 4.2 and earlier require that you use certificates with an unencrypted private key. This will change in 4.5, where the encrypted private keys will be supported and encouraged. Netscaler expects PEM formatted certificates too, and supports the upload of password-protected private keys.

The AG Administrator's Guide advises you to use OpenSSL to convert your certificate into PEM format. Just find a UNIX system or find a Win32 port of OpenSSL, go out to a command prompt and type:

openssl pkcs12 -in cert.pfx -out newcert.pem -nodes

(BTW, that -nodes flag is not the plural of node, it means "no DES encryption".)

But that's a hassle. You don't want to spend all day at a command prompt cd'ing into the right directory and typing fully qualified file paths and such. So here's pfx2pem, a little Windows shell wrapper that will generate and execute the OpenSSL command for you:


To use pfx2pem, just drag and drop your PFX file onto the pfx2pem.wsf icon. It prompts you for the password and then spits out a PEM file right next to the original PFX file.

There are two versions of the tool included:

  1. pfx2pem - generates a PEM file with an unencrypted private key. Use this for CAG 4.2.x and earlier.
  2. pfx2pem-des - generates a PEM file with an encrypted private key. Use this for Netscaler and future versions of CAG.

July 19, 2006

Can Netscaler perform SSL Offload for Secure Gateway?

I've been asked multiple times whether the Netscaler appliance could be used as a Secure Gateway replacement. It can handle a lot more SSL transactions per second than the typical Windows box, and would take a large burden off the secure gateway servers, allowing for more concurrent users. In this article I'll explore the topic and illustrate one possible solution that works today.

Since Citrix acquired Netscaler, there haven't been any major changes to the Netscaler operating system in terms of Access Suite integration. Netscaler was already a very mature and successful product with its own road map already well defined. Presentation Server integration is now part of that road map but it's going to take a while. So unlike Access Gateway, Netscaler cannot fully replace a Secure Gateway server because the Netscaler box doesn't yet understand things like STA ticketing, CGP and ICA.

Secure Gateway expects the following sorts of traffic to arrive on port 443:

  1. HTTPS, which SG can relay to a Web Interface server
  2. ICA in CGP in SSL, where the CGP layer includes a ticket that must be validated by a Secure Ticketing Authority (STA), or
  3. ICA in SOCKS in SSL, where the SOCKS layer includes a ticket that must be validated by a Secure Ticketing Authority (STA)

When traffic arrives, SG unwraps the SSL layer and then deals with the payload based on those three use cases. Recent ICA clients (since 9.0) will send ICA in CGP in SSL; older ICA clients use SOCKS. The CGP protocol is what enables session reliability through a secure gateway server. See my Secure Gateway Troubleshooter's Guide for more details on this.

Looking at the SG server's httpd.conf file, it is easy to disable the SSL expectation. SG 3.0 is based on Apache, and there are three "VirtualHost" sections in the httpd.conf file. For example:

#Gwy Settings - CGP



CgpProtocol On

RequireTicket On
CGPHandshakeTimeout 100000
RegisterProtocol CGP

# SSL Params
SSLEngine On
SSLCertificateHash 6b5c6b264e0a07d0fbd30816cf68f13371076d1d
SSLProxyEngine On


You can turn off SSL for each virtual host by simply changing the line "SSLEngine On" to "SSLEngine Off".

If you do that for all three virtual host sections and then restart the SG service, you will have a Secure Gateway service that now expects these sorts of protocols to arrive on port 443:

  1. HTTP, which SG can relay to a Web Interface server
  2. ICA in CGP, where the CGP layer includes a ticket that must be validated by a Secure Ticketing Authority (STA), or
  3. ICA in SOCKS, where the SOCKS layer includes a ticket that must be validated by a Secure Ticketing Authority (STA)

Now you're ready to set up a Netscaler and do the SSL offload.

  1. Create a TCP service entity for each Secure Gateway box on port 443
  2. Put a certificate on the Netscaler and create an SSL Offload virtual server that uses the SSL_TCP protocol and the Least Connections load balancing method. Persistence is not required for ICA connections. Add the TCP services you created in step 1.
  3. Configure web interface to use the FQDN of the certificate you used in step 2 as the Secure Gateway FQDN

It would be a good idea to create a separate SSL offload virtual server just for the web interface traffic too, which relays HTTP to the WI servers on port 80 instead of relaying that traffic through the hacked up secure gateway service.

I tried this little experiment and it works. The protocol stacking looks like this:

Browser --[HTTPS]--> Netscaler --[HTTP]--> WI --[XML]--> Presentation Server

ICA Client --[ICA+CGP+SSL] --> Netscaler --[ICA+CGP]--> SG --[ICA+CGP]--> Presentation Server

Some day the Netscaler will probably have all the Secure Gateway functionality, like the Access Gateway appliance does today. Until then, this experimental topology may provide you with better throughput and allow you to get more users per SG server by offloading the encryption tasks to a Netscaler.


July 04, 2006

A webinar and a white paper on AAC

Last month I delivered a public "TechTalk" webinar that covers the basics of how to implement Access Gateway and Advanced Access Control in about an hour. You have to register to view it, but it's free and open to the public.

To view ithe webinar, go here: and click Register now.

Another piece of work I completed recently is a white paper that details the options you have for deploying Web Interface in an AG+AAC 4.2 deployment. It's challenging because AAC servers are designed to be stateless but WI servers are stateful and require session persistence. If you have multiple AAC servers and multiple WI servers, it takes some planning to create a redundant solution.

The white paper is Citrix KB article CTX109960 and can be downloaded here:

Using Web Interface 4.2 with Access Gateway Advanced Edition 4.2 - How to Build a Fault Tolerant Deployment


July 03, 2006

Hybrid Parallel deployment of Access Gateways

Today I helped a customer (who shall remain nameless) design an Access Gateway solution where they had the following requirements:

  • The gateway should check for the existence of a client certificate during logon
  • Users who had the client certificate should be able to log in and get Presentation Server icons
  • Users should be able to connect to the Presentation Server applications without requiring an SSL VPN client

Sounds simple enough, right? But there's a problem: the ICA client cannot present client certificates to the gateway when making an ICA+SSL connection, and the gateway cannot be set to "request" client certificates, only to "require" client certificates. When you set AG to require client certificates, you break its ability to act as a Secure Gateway for ICA clients.

So the solution I proposed was to use a separate gateway just for ICA connections, and tunnel only the HTTPS traffic through the Access Gateway #1 en route to AAC. The two gateways run parallel to one another, but gateway #2 does not accept user logons, only ticketed ICA traffic. In order to get through gateway #2 you must have a ticket from the Secure Ticket Authority (STA). In order to get a ticket from the STA, you must authenticate to AAC and Web Interface, and in order to do that you must have the client certificate and a valid username/password.


Each gateway will need its own certificate, its own unique FQDN and its own publicly routable IP address. You can use Secure Gateway software for gateway #2 if you want, or you can use a 2nd AG appliance. If you use an appliance for gateway #2, you'll need an AG user license for each concurrent ICA connection that is made through the gateway. Be sure not to join the 2nd gateway to the AAC farm, or it will inherit the "require client certificates" setting.