As I mentioned in a previous post, Web Interface now supports federated authentication. From a Citrix perspective, Federation allows a user to be authenticated in their home domain and then run applications on a Presentation Server that resides in a different (and untrusted) domain. Web Interface 4.5 officially supports Microsoft's Active Directory Federation Services (ADFS). You can find all the details in Appendix B of the Web Interface 4.5 Administrator's Guide.
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.
Web Interface for ADFS without ADFS
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"
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):
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.
The following items are required for Federated sites:
- The Web Interface server must be a member of the Presentation Server domain (or a trusted domain).
- 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.
- 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.
- The Citrix Presentation Server must be no earlier than version 4.0 with Hotfix Rollup Pack #2.
- 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: