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.

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.

"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?