Let me start off by saying that we were hoping to support 64-bit operating systems much sooner, but we had some unanticipated challenges that expanded the scope of effort required. Getting all of our Access Gateway plug-ins to support 64-bit Vista, as well as Windows 7 and MacOS, has been and continues to be a top priority for us this year. It's also critically important that we fit into the Citrix Receiver framework for delivering all the various Citrix plug-ins to the end user. We're nearly there.

I'm pleased to announce that we are releasing today version 4.6.1 of Access Gateway, Standard Edition which offers full support for 64-bit Windows Vista, Windows 7 32-bit and 64-bit, and MacOS. You can get the clients and appliance firmware now from the Citrix.com downloads area: http://www.citrix.com/download/

As you know, we have three distinct variants of Access Gateway: Standard, Advanced and Enterprise, each of which has a separate lineage and uses different client protocols & endpoint analysis features. We are planning to deliver Win7, 64-bit and MacOS support for all three editions.

Vista 64-bit, Windows 7 & IE8

• AG Standard supports 64-bit Vista and Windows 7 today, using version 4.6.1.
• AG Advanced Edition users can log on from 64-bit machines if the appliance is upgraded to 4.6.1, but full support for endpoint analysis and IE8 is not available until AAC Hotfix 5, due out in early January.
• AG Enterprise Edition is expected to include a new 64-bit capable client in version 9.1.100, ETA is December.

Macintosh

Last month, we announced the availability of our first Access Gateway Plug-in for MacOS, which now connects to AG Standard Edition (4.6 or later) and Enterprise Edition (9.1.98 or later). Support for Advanced Edition is expected by January with AAC Hotfix 5. As we were closing down the release, Apple released their "Snow Leopard" (10.6) version ahead of schedule. We were planning not to offer 10.6 support until a few months later, because we were expecting this to be another large effort pertaining to 64-bit support. However, Apple did not enable 64-bit kernel mode by default in client machines, only on their XServe platform. This is good news for us, because the MacOS client seems to be working fine on 10.6 with the default 32-bit kernel mode.

One thing that makes 64-bit support on MacOS different from 64-bit Windows: with MacOS users can run 64-bit applications even if the kernel is running in 32-bit mode. Nevertheless, we do plan on supporting 64-bit kernel mode on the Mac with our next release of the Mac plug-in in Q1 of next year.

Not supported

To avoid prolonging our release schedules any longer, we made a couple of tough trade-offs regarding older operating systems. We decided that we will not be able to provide official support for:

• Windows XP 64-bit
• MacOS 10.4 ("Tiger")

(I've heard anecdotally that the 64-bit Vista client actually does work on XP 64-bit, but we have not fully tested it and we are not officially supporting it.)

Access Gateway Client OS Support

To summarize, the supportability matrix that we are filling in over the next few months looks like this:

If you have any questions or comments, please feel free to let me know.

Jay

Access Gateway Enterprise Edition 8.1 Documents

There are a few minor gotchas to watch out for with this release:

Support for Windows Vista

Version 8.1 (finally) supports Windows Vista for endpoint analysis and full network-layer access. In version 8.0 we only had beta-level Vista support. But there are two limitations in 8.1:

1. The IE Active Plugin does not work on Vista, you have to deploy the full client.
2. Only 32-bit Vista is supported.

Clientless access to web sites and file shares

This is a highly demanded feature and for a first release it works great. There may be some web apps, especially those that make heavy use of AJAX or complex client-side Javascript to calclate URLs, that don't work through the clientless access. In this mode of access, as the web traffic passes through the Access Gateway, the gateway rewrites all the HTML so that any internal links or URLs use the Access Gateway address instead. This search-and-replace process occasionally misses links if they are constructed by a programming language instead of normal HTML. Outlook Web Access 2003 and 2007 work fine, and a lot of effort went into correcting the rewrite misses. SharePoint sites still see a few glitches in this version when going clientless.

Web Interface Integration

You can now simply point the Access Gateway to a Web Interface site URL and it will automatically display in the Access Gateway's default home page. When you hear "Web Interface Integration" it's easy to conclude that Web Interface is running *on* the Access Gateway appliance, but that's not the case here.

The user interface is more or less the same, except the old "dog bone" desktop icon is now a nice blue padlock circle matching the theme of all the other Citrix products.

One thing that always bugged me about the 8.0 client was that when you launched it, all it did was add an icon to the system tray. Then you had to go and right-click the icon to log on. Not good for all those users who haven't discovered their right mouse button yet. In 8.1, the client loads *AND* the logon page appears. And in 8.0 if you were already connected and you double-clicked the icon, you basically got yelled at with "another instance is already running!" In 8.1, if you launch the desktop icon while you are already connected, it politely asks if you want to log off.

If there are any AG-E customers out there reading this, please let me know what you think of version 8.1.

Jay

First, some background. Thinstall virtualizes elements of the Windows operating system like files and registry hives, so applications install and run in a "sandbox" without impacting other apps or system components. Their virtualization framework gets packaged in along with the application executable and DLLs, which means there's no software required on the endpoint. Applications don't have to be installed, they just run. And since each app gets its own sandbox, you don't have to worry about Application A causing problems with Application B.

In other words, Thinstall solves the same set of problems as Microsoft SoftGrid and the Application Streaming feature of Citrix Presentation Server.

Clearly this extends the competition between VMWare and Citrix. Both companies are out pitching solutions for virtual desktop market (VMWare VDI, Citrix XenDesktop) as well as the virtual server market (VMWare ESX, Citrix XenServer). The acquisition of Thinstall illustrates VMWare's desire to compete in the App Delivery market too.

VMWare understands that the hypervisor is on a path to commoditization, that they have to expand their solution set through acquisitions to solve more problems than server consolidation (and do so as quickly as possible before their P/E ratio comes back to earth). And they are right to be looking up the stack toward the application as the direction to move. As Citrix has been saying for years, applications are the central unit of thought for IT managers, the raison d'etre for IT. Applications alone make IT relevant to the business.

Why this is good news for Citrix

Yes, this means competition against the mainstream Citrix product portfolio, which at first blush looks like bad news for Citrix. But the move only validates that the Citrix story around app delivery is moving from a relative niche market where Citrix enjoyed 80% market share into the mainstream IT market that will be shared by multiple large vendors. As VMWare, undeniably the hottest technology IPO of 2007, enters this market, it raises the visibility of what Citrix has been doing all along: virtualizing application access. I would expect to see more acquisitions related to app delivery over the next year or two, and it would also follow that as the app delivery market matures and consolidates we will see more innovation and lower prices.

App Delivery is Citrix turf. Thank you, VMWare for shining the spotlight on our corner of the data center!

1. Client Choices - You can offer the user a choice page where they decide whether to launch the Secure Access Client and initiate a full VPN tunnel, or just go with Presentation Server access via Web Interface. You can also make it so that when the user fails to meet some endpoint analysis criteria, the only choice they get is Web Interface.
   
   
2. Access Method Fallback - Without showing a client choice page you can simply fall back from VPN access to Web Interface access if the client fails an endpoint analysis scan. Presentation Server is used as a quarantine access method.
3. Windows Vista VPN Client (Beta) - Build 8.0.50.3 includes a beta Vista VPN client. It lacks a few features but for basic tunnelling it works fine.
   

If you want more technical detail on how to configure AG-E and get the SmartAccess hooks into Presentation Server that allow you to control which apps a user can launch and which ICA virtual channels they can use based on endpoint analysis, then you should download my SmartAccess Deployment Guide for AG-E. The guide has step-by-step instructions for setting up a basic deployment, from installing the license and certificate to configuring AG and CPS policy settings. Once you get the basic configuration steps done, tweaking the deployment for your needs is a lot easier.

Jay

I'm happy to report that this limitation has been addressed with the release of the Win32 Presentation Server client version 10.1. Somehow this new feature managed to escape the readme.

Access Gateway (any edition) can be set to require a valid client certificate before allowing users to log on, and Access Gateway Enterprise Edition can go further and actually authenticate the user based on the certificate alone. When the option to require a client certificate is enabled, and Web Interface is configured to send Presentation Server clients through the gateway unassisted by a network-layer tunnel, the ICA client must perform its own SSL handshake with the gateway and pump the ICA traffic through that SSL tunnel.

Here's a screenshot of the new 10.1 client in action when the gateway is set to require a client certificate.

The practice of creating a De-Militarized Zone (DMZ - a network separating the Internet from the corporate LAN) is anachronistic. DMZ's started when computing was comparatively stationary. Computers were big boxes that sat on or under a worker's desk and were physically wired to the network. Physical location provided a good measure of security, because in order to get onto the corporate network you had to have a computer that was plugged into the office wall.

No longer. These days, ubiquitous wireless laptops follow users in and out of the office. Users run their applications from anywere, including the office, home or Wi-Fi hot spots.

To deliver those applications to remote users, network managers increasingly find themselves poking holes or adding NAT rules on the firewall that separates the DMZ from the corporate LAN. And the firewall rules that allow traffic into the LAN are typically exceptions granting access to the most trusted resources: domain controllers, web servers, application servers, SQL databases and the like. The CSO never wants to put another rule on that firewall, but application access trumps firewall configuration every time. Eventually, the inner firewall begins to resemble swiss cheese.

Furthermore, increased user mobility adds to the risk of an infected machine walking in through the front door under the arm of a trusted employee. The DMZ offers no protection here. IT groups respond by adding layers of anti-virus protection on all managed PC's and patching internal servers as though they were bastion hosts. Anti-X protection is everywhere: on the endpoints, on the servers and on the network.

Why then should we continue to spend time and money creating and maintaining a separate DMZ network? If the premise is that the DMZ subnet might become fully compromised and the attacker's access level should be restricted at that point by routing and firewall policies, then surely it is a false sense of security when access to sensitive back-end data is inevitably permitted in the name of application access.

Citrix is part of this question - we provide solutions that enable secure remote access to all types of applications (Access Gateway) and solutions that protect web applications where they are vulnerable: at the application layer (NetScaler and Application Firewall). In a typical deployment, the Access Gateway, NetScaler or App Firewall will be placed in the DMZ and then the poor network admin has to go and create firewall rules for everything that the Citrix devices will ever connect to on the LAN. A couple customers lately (who I would consider in the vanguard) have abandoned the practice of maintaining a firewall between their SSL VPN server and their internal LAN. It sure makes deployment and upkeep easier as new applications are added.

Of course, I don't expect many companies will walk away from the DMZ topology any time soon. The more paranoid use a dual-stage DMZ, which creates double challenges for enabling application access.

To put this in context I have been running a DMZ on my home network for the past year or so, and I have found it adds very little safeguard but makes day-to-day tasks more complicated than I care for. I'm just about ready to go back to a flat subnet protected by a good external firewall.

This is not the first release of the Enterprise Edition gateway, but it’s the first release to include the same ICA proxy capabilities as the Standard and Advanced editions of Access Gateway. This allows remote users to traverse the DMZ and access applications hosted on Citrix Presentation Servers without requiring any sort of VPN client. Citrix has been selling the Access Gateway Standard and Advanced Editions for the past couple years as a replacement for the Windows-based Secure Gateway component, allowing you to get those Windows servers out of your DMZ and replace them with hardened security appliances. Now Enterprise Edition is also on the table as an option to consider for SG Replacement.

If you’re looking to replace your Secure Gateway servers with an Access Gateway appliance, the most important difference Enterprise Edition 8.0 brings to the table is scalability. The Standard Edition Model 2000 appliance (or “Baby CAG” as some have called it) can host a maximum of 2000 concurrent ICA sessions, and that is when it does nothing but ICA. For Enterprise Edition, there are three appliance models to choose from, supporting up to 10,000 sessions per appliance:

• Model 7000 – 2,500 concurrent sessions
  
  
  


• Model 9000 – 5,000 concurrent sessions
  
  
  


• Model 10000 – 10,000 concurrent sessions
  
  
  

I won’t bore you with a full feature list but there are a few interesting things that stick out in terms of features only available on the Enterprise Edition:

• Client Certificate Authentication – Users can establish a VPN connection by presenting a smart card or soft certificate in lieu of a username and password.


• Multiple virtual servers – You can host as many “virtual” SSL VPNs as you want on a single physical appliance. Each SSL VPN virtual server can have its own IP address, its own certificate and its own set of policies.


• VPN traffic compression – Leveraging the NetScaler compression technology, you can have all user traffic within the VPN tunnel compressed to reduce bandwidth.


• Built-in high availability – You can deploy two appliances in an active/passive pair and all VPN session information is shared between the two. If the primary gateway fails, the secondary gateway takes over without requiring users to log back in.

Like the Advanced Edition, you also get "SmartAccess for Presentation Server" – that is, you can filter published applications and CPS policies in response to endpoint analysis. For example, hide some sensitive app icons and turn off client drive mapping when the user is connecting from an unmanaged endpoint. I posted an article on this concept a while back.

Unlike the Advanced Edition which consists of an appliance plus one or more Windows servers, the Enterprise edition is a standalone box – there’s no AAC server farm to install and configure.

Sadly though, the Enterprise Edition still has some things it won’t do, things which we offer today in the Advanced Edition. The Advanced Edition is nowhere near as scalable as the Enterprise edition, but it’s still the only edition right now that can do these things:

• Clientless access to internal web sites (web proxy) – the Enterprise edition requires a VPN client to reach web servers on the LAN.
• File Type Association– the ability to declare in a policy that certain documents must only be accessed via Presentation Server, not downloaded to the user’s device. (Though I suppose you could arrange your authorization policies to make this the case in Enterprise Edition, by denying direct access to the web servers or file servers.)
• HTML Preview – This is really a Windows function and I’m not sure it could be done effectively without requiring a Windows server.

So don’t assume that Enterprise Edition will be able to do absolutely everything that the Standard and Advanced editions can do at this point. Depending on what your needs are, the Advanced Edition might be a better fit, especially if you don’t need to support more than about 500 concurrent users. But if you really want high user density and connectivity to Presentation Server applications without tons of Windows servers in your DMZ, it’s time to take a look at Access Gateway Enterprise Edition. And you can rest assured that Citrix is working to close that feature gap as quickly as possible.

So is it a NetScaler?

In talking to people about this release, there seems to be a lot of confusion out there about how the Access Gateway Enterprise Edition lines up with Citrix NetScaler. Let me see if I can explain it:

• Access Gateway Enterprise Edition is sold as a standalone SSL VPN product. It shares the same core OS (derived from FreeBSD) and the same hardware platforms as the Citrix NetScaler, which is sold as a load balancer and application switch. But when you buy an Access Gateway, you cannot use it as a load balancer too.
  


• However – Access Gateway licenses can be added to a Citrix NetScaler load balancer, resulting in a single appliance that is both a load balancer and an SSL VPN. You can only add AG user licenses to the Enterprise or Platinum editions of the Citrix NetScaler.

Jay

1. Introduction to Active Directory Federation Services
2. Web Interface ADFS Integration
3. Configuration Walk-through
4. Alternative Deployment Scenarios
5. Q&A

You can download the video file, powerpoint slides and other supporting documents here:

• Download the video
• Download the PowerPoint slides
• Web Interface for ADFS Frequently Asked Questions
• Citrix Ping Identity Solution Guide
• RSA Solution Guides for Web Interface
• ADFS Forum on support.citrix.com
• Using Federated Authentication with Web Interface 4.5
• Service Principal Names and Delegation in Presentation Server

As it turns out, ADFS is just the beginning of the story. The work Citrix did to enable support for Federation has opened up a host of other authentication options that have never before been possible, like web portal SSO, soft certificate logins and third-party single sign-on where the user needn't know their domain password. Before we get into all these new possibilities, let me explain how Citrix supports ADFS and why it means more than just ADFS.

It's All About Kerberos

When Web Interface is used with ADFS, the Web Interface site is protected by the ADFS Web Agent. The ADFS Web Agent is an ISAPI filter from Microsoft that blocks access to IIS web pages until the user can present a valid identity assertion from a trusted account partner. If you don't have a valid identity assertion, you get redirected back to federation servers where authentication takes place. Once you get your claim and the web agent can validate your identity, it produces a Kerberos token on the web server allowing access to the local web pages. If the web server belongs to the same domain as your Presentation Servers, then through the magic of Kerberos delegation you can see and launch applications that are published on Presentation Server.

To pull this off, Citrix had to enhance the Web Interface and Presentation Server side of things to support logging in with just a Kerberos token. Plus, the WI and CPS computer objects in Active Directory have to be configured to support Kerberos delegation--a chore whose drudgery rises exponentially with the size of your CPS farm. (I'd love to see some new tools be developed that help with the process of configuring delegation for all the Presentation Servers. It should be possible to script it with ADSI but coming up with a silver bullet that works for all deployments would be quite tricky.)

If you can soldier through the process of setting up delegation for your Citrix servers, you get some very interesting new authentication options. With this new functionality, all Web Interface needs is a Kerberos token to use in the CPS domain. It can get that token from the ADFS web agent or from any other process.

Read on to find out how this can be done today and what sorts of new options it opens up for authenticating to Citrix servers.

You can create a special type of Web Interface 4.5 site that leverages the new advanced Kerberos support without requiring ADFS. To create such a site, you have to use the command-line site creation tool sitemgr to create the site instead of clicking the “Create site” task in the Access Management Console. The WI team deftly added a switch to sitemgr that turns the Kerberos functionality on but leaves ADFS-specific items turned off: Federated=Yes.

The sitemgr tool is located on the Web Interface 4.5 server beneath Program Files\Citrix\Web Interface\4.5. Run sitemgr -h for details on all available parameters. For example, open a command prompt and issue the following commands:

cd "\Program Files\Citrix\Web Interface\4.5"
sitemgr -h

To create the federated Web Interface site that does not rely on ADFS, include the Federated=Yes parameter in the site definition string supplied to sitemgr. For example, to create a web interface beneath /Citrix/AccessPlatform where CPS4A is the name of a Presentation Server running the XML service, issue the following command from the Web Interface 4.5 server (all on one line):

sitemgr -c "WIDest=1:/Citrix/AccessPlatform, Config=Local,XMLService=CPS4A,XMLSPort=80,Federated=Yes"

Once the site is created using sitemgr, it can be managed as usual using the Access Management Console. You'll notice there are no authentication options to configure--it just uses whatever identity it gets from IIS. If you leave anonymous access to the web pages enabled, then it will run as the NETWORK SERVICE account and you won't see any application icons. But if you disable anonymous access, you can use any of the various IIS authentication methods to identify the user.

So, anonymous authentication needs to be disabled for the IIS folder where the site resides. For example:

• In IIS Manager, edit the properties of the /Citrix/AccessPlatform virtual directory
  
• Select the Directory Security tab
  
• In the Authentication and access control section, click Edit
  
• Clear the checkbox for Enable anonymous access and click OK
  

Finally, configure delegation in the manner described in Appendix B and you can parlay that IIS authentication all the way into a Presentation Server session. Add Password Manager in the last mile to deal with any application-specific passwords and you've got one smooth SSO solution.

Have Token, Will Travel

A Web Interface site created with the Federated=Yes switch can work as a pure Kerberos pass-through authentication solution, which would not require any changes to the user's appsrv.ini file. In a previous post I discussed how these benefits surface in a normal ADFS deployment when you do not define an ADFS account partner, but in fact you can get the same benefits without using ADFS at all, simply by flipping the Federated=Yes bit.

Or, it could work with authentication providers other than ADFS that validate the user’s identity and then produce a Kerberos token using protocol transition. Here are a couple authentication solutions I'm aware of that support protocol transition (and I'm sure there are more):

• RSA Access Manager (formerly known as ClearTrust)


• Ping Identity PingFederate

Or, the federated WI site could sit behind an SSL VPN (such as Access Gateway Enterprise Edition) or a reverse proxy server (such as Microsoft ISA Server) that performs downstream authentication to back-end web servers on behalf of the logged on user. Any device that supports Basic, Digest or NTLM authentication to downstream web servers ought to work.

Or, you can use the client certificate mapping feature of IIS to associate a user’s certificate with a domain account on the CPS side. When the user presents the certificate to IIS, they get a Kerberos login for the CPS domain. The certificate could reside on a smart card or in the user's profile.

Until now, none of these scenarios were possible.

Other Requirements

The following items are required for Federated sites:

1. The Web Interface server must be a member of the Presentation Server domain (or a trusted domain).
   
2. User identities must be mapped to accounts in the Presentation Server domain. If using the straight Kerberos scenario this is not an issue, but for certificate mapping or a third-party federation solution you may need to perform some sort of account mapping.
   
3. The Web Interface and Presentation Servers must be configured for delegation in the same manner as the documented ADFS deployment. Refer to Appendix B of the Web Interface 4.5 Administrator’s Guide for details, especially pages 164-166.
   
4. The Citrix Presentation Server must be no earlier than version 4.0 with Hotfix Rollup Pack #2.
   
5. The XML Service on Presentation Server must be hosted by IIS and must be defined in the WI site configuration as a host name, not an IP address.

The following items mentioned in the Web Interface 4.5 Administrator’s Guide are required for ADFS deployments but are not necessarily required for a federated site that uses an authentication method other than ADFS:

• Windows 2003 R2
  
• Active Directory Federation Servers
  
• Shadow accounts
  

For more information about what Citrix is thinking in regards to user identity management, take a look at the following posts on CitrixCommunity.com:

• Welcome to the IAM Blog from the Project Callisto Team
  
• Identity in the Citrix Access Infrastructure (Wherefore Art Thou?)
  

Jay

https://www.citrix.com/English/ss/downloads/downloads.asp?dID=36407

Version 4.5 of WI introduces the following new features:

• Web-based Self-Service Password Reset support for Password Manager 4.5
• Password expiration notification
• Application streaming support for the soon-to-be-released streaming product (Project Tarpon)
• Built-in support for Active Directory Federation Services
• Published application URLs – drag and drop app icons from the web page to your desktop, or add applications to your IE Favorites list!
• Enhanced rebranding support from within the Access Management Console
• Supports SSL encryption of Configuration Manager traffic
• Based on .NET 2.0

There seems to be a problem with the link to the Administrator's Guide right now, so I'm posting a copy of it here:

Web Interface 4.5 Administrator's Guide (English)

Also available for download today are new versions of Web Interface 4.5 for UNIX, the Web Interface 4.5 SDK and Web Interface for IBM WebSphere.

The way this works, in a nutshell, is the following:

1. From a domain workstation, the user points IE to an IIS domain member web server. IIS performs Integrated Windows Authentication (using either NTLM or Kerberos) to ascertain the user's identity.


2. Web Interface reads the user identity and performs a lookup to determine which domain groups the user belongs to.


3. The list of groups (SIDs) is sent to the Presentation Server XML broker and the applications published to those groups is returned to Web Interface.

That takes care of getting the icons painted on the web page, but connecting to one of those application uses an entirely different authentication method: the ICA client must eavesdrop on the user's workstation logon, store the credentials in memory (ssonsvr.exe) and then replay those credentials (or send a Kerberos ticket) through an ICA virtual channel when connecting to a Presentation Server.

As you can see, the initial web server authentication does nothing to help with the ICA session authentication. If you have ever struggled with a deployment of Web Interface that uses the "Pass-through" authentcation method, you are all too familiar with the pain-points that this situation creates:

• Users require changes to their appsrv.ini file in order to support the sending of their password or Kerberos ticket through an ICA virtual channel (SSOnUserSetting=On and EnableSSOnThruICAFile=On)
• After installing the client, users must log out of their workstation and then log back in again so that ssonsvr.exe can learn their credentials

You can eliminate those pain points by leveraging the ADFS-enabled version of Web Interface. This is available today as a special post-4.2 release, and ADFS support will be part and parcel of Web Interface 4.5 when it ships.

ADFS is typically regarded as a single sign-on tool for .NET web applications, but the ADFS-enabled Web Interface release empowers you to deliver the same degree of federated single sign-on for applications hosted on Citrix Presentation Server. You can read more about the current ADFS WI release here:

Web Interface with ADFS Support Administrator's Guide

If you're still reading at this point, congratulations! We're past the obligatory intro material and here's where it starts to get interesting. The administrator's guide referenced above explains that you must create "shadow accounts" for users in the foreign domain, complete with an alternate UPN suffix in your domain. For example, if the CPS servers are in the treyresearch.com domain and the users are in the adatum.com domain, the treyresearch Active Directory domain would have to be configured to support adatum.com as an alternate UPN suffix, and then accounts for each ADatum user would have to be created, using the adatum.com suffix, in the TreyResearch domain.

You're supposed to set up a federation server in both domains, one for the account partner domain (where users are authenticated) and one for the resource partner domain (where CPS resides). But the technology behind identity federation can be used for more than just the typical B2B type scenarios.

Interestingly, you can treat a single domain as both the account partner and the resource partner. If you set up a federation server in your CPS domain but forego the whole process of defining an Account Partner, users within the CPS domain can still point to the ADFS-enabled web interface site and get signed on automatically. What's more, creating the so-called "shadow accounts" is not necessary in this scenario, as WI will use the pre-existing domain user accounts when it validates your federated identity.

The end result is a Web Interface site that displays application icons automatically AND signs the user onto a Presentation Server without requiring the client to send credentials or Kerberos token through the ICA client. Client machines need not have any special settings in their appsrv.ini because a new Kerberos token is generated by the federation server, handed to Web Interface and then passed on to the CPS XML broker.

Can you say zero help desk calls?! If you want to try this, be aware that you'll need Windows Server 2003 R2 for the federation server and Web Interface server. (The WI and Federation servers can be hosted on the same machine if you are short on boxes.) The requirements are all spelled out in the administrator's guide referenced above, but I want to emphasize that you do not need to upgrade your CPS servers to R2. They just need to be CPS 4.0 with Hotfix rollup pack #2 or better.

This example of using ADFS without an external account partner is a slightly abnormal application of the ADFS feature, and it's only the tip of the iceberg in terms of the new possibilities that federation brings to the table. I've also toyed with a scenario where the user authentication can be performed by a soft certificate stored in the user's profile:

Take a workstation that does not belong to your domain and install a user certificate in the web browser on that workstation. Then configure the ADFS account federation server web agent scripts to require SSL Client certificates and enable the directory service mapper in IIS. When WI redirects the user to their account federation endpoint URL, they get challenged for a user certificate. The ADFS web agent reads the certificate, maps it to an AD account and then passes your identity claims up to web interface. Users can log on from any workstation, regardless of the workstation's domain membership, and authenticate to Presentation Server using only their certificate. Without ADFS, the only certificate-based logon that CPS can support is using a physical smart card where PC/SC calls can be redirected through an ICA virtual channel.

There's no end to the authentication challenges you can solve by leveraging ADFS. It's a real game-changer! No wonder Andrew Innes, the WI architect, referred to the WI ADFS integration as a "monumentally huge tectonic shift ".

Are you using ADFS in creative ways yet for your Citrix users? If so, I'd love to hear about it.

Jay

"Please click here if you are not automatically redirected."

The message sometimes flashes by in an instant but in other cases it can take between 5-10 seconds before the user is shown the WI logon page. The redirect code itself is just a BODY ONLOAD tag that bounces the user onto the .../auth/login.aspx page where they authenticate. But why does it sometimes take so long?

Once the scripts are compiled and the DLLs are in memory, subsequent requests are much faster: faster than the old ASP architecture where each script had to be parsed every single time an HTTP request came in.

By default, IIS 6.0 will unload a web application pool if it has been idle for 20 minutes. This means that if nobody hits the WI site on that server for 20 minutes, the next person that does use the site will experience the compilation delay.

IIS also recycles application pools by default once every 29 hours. Not sure where they came up with 29 hours as the value for this... the practical effect is that the application pool recycles every day but at a 5-hour offset from the day prior.

You can reduce the number of times the application pool unloads by increasing or disabling the idle timeout for the Application Pool named 'CitrixWebInterfaceAppPool' or 'CitrixWebInterface4.2AppPool'. If you have 4.0 and 4.2 installed on the same server you will have both application pools:

Right-click the app pool and choose Properties. On the Recycle tab, you can just clear the setting for recyclying the app pool every 29 hours:

Then view the Performance tab and configure the option "Shutdown worker processes after being idle for (time in minutes)". I usually just clear the checkbox so this never happens:

With these changes, the delay should only happen whenever the web server (or IIS) is restarted.

JayT

PS: While we're looking at that performance tab, be aware that if you increase the "Web Garden" number from 1 to 2 or higher you will break WI. Doing so creates multiple copies of the web application pool process, which from a session variable point of view is a lot like having two separate web servers with non-persistent load balancing taking place between them. When a user gets bounced from one thread to the other, the new thread does not have any of their session varialbes in memory and they see the dreaded error "Your session is in an inconsistent state."