For several versions now Web Interface has included a feature that allows users to authenticate using a smart card instead of entering their username and password. It works like this:
- During the SSL handshake, IIS metabase settings trigger a request for the client certificate
- IIS Directory service mapping associates the user certificate with a user account in Active Directory
- After a successful mapping IIS impersonates the user account, allowing Web Interface to deduce the groups to which the user belongs
- That list of groups (actually a list of group SIDs) is sent to the Presentation Server XML service instead of a username and password
- The XML service returns the list of published applications that are available to those groups
As you can see, the process depends entirely on IIS for doing the authentication and mapping the user’s certificate to their domain account. This only works when the IIS server is a domain member, and since nobody wants to put a domain member server in their DMZ we’ve always said that this is a solution for internal (or VPN) users only.
But what if there were another way?
What if we could validate the client certificate without having to talk to Active Directory? That’s possible using an IIS feature called the Certificate Trust List. Using this feature of IIS, you can specify exactly which Certificate Authorities whose client certificates should be trusted for connection to the website. During the SSL handshake, if a user presents a client certificate from any other CA, IIS will refuse access to the site.
The problem though is that there’s no way to tie the user certificate to a domain user. So here’s a solution that will work for the DMZ while still requiring valid client certificates: Configure Web Interface for normal (explicit) authentication, but then configure IIS to require a trusted client certificate in order to reach that explicit site. Users will be prompted for their certificate and then they’ll have to type in their username and password in order to log into Web Interface.
To do this, open IIS Manager and edit the properties of the web site or virtual directory that hosts the Web Interface pages. On the Directory Security tab, edit the "Secure Communications" properties. Select Require secure channel (SSL) and the choose to Require client certificates.
So far all we've done is get Web Interface to show us the icons of the applications. The next phase is for the user to click an icon and receive a dynamically generated ICA file that connects them to a Presentation Server. On normal (unmodified) Web Interface sites that are configured for explicit authentication, the ICA file will contain a username and a ticket that logs the user in without requiring them to re-type their password. For sites configured to use smart card authentication, the ICA file will contain no logon ticket or credentials. Instead of credentials, the ICA file will include this obscure little command:
DisableCtrlAltDel=Off
Next time you’re bored you should try adding that parameter to an ICA file and watch what happens. Instead of logging you in with a ticket or showing you the Windows GINA where you can type your username and password, you will see the Windows logo from the Presentation Server as though you had walked up to the server but not touched the keyboard yet:
This GINA will be floating seamlessly on your desktop and you’ll have to type Ctrl-F1 to simulate the Ctrl-Alt-Del command on the server.
When a smart card CSP is installed on the server though, an ICA virtual channel lights up and reads your client-side smart card to log you into the server.
So to use the smart card for Presentation Server authentication too, we need to modify the ICA files that Web Interface generates so that the credentials (username plus logon ticket) are removed and the DisableCtrlAltDel=False line is added. Web Interface 4.x makes this a trivial task by just adding some lines into the ICA override file located at conf/default.ica.
Locate the physical path for your web interface site, such as C:\Inetpub\wwwroot\Citrix\Metaframe. There you should find a conf directory with several ICA override files inside. Edit default.ica with notepad and add these lines to the [Application] section:
Username=
Domain=
ClearPassword=
DisableCtrlAltDel=False
This has the effect of blanking out any explicit logon information that would have been included in the ICA file, and triggers smart card authentication through an ICA virtual channel instead.
This can be made to work with Access Gateway or Secure Gateway, but you will need to allow direct HTTPS access to the IIS server that is hosting Web Interface. If the HTTPS traffic is relayed through the Secure Gateway service or an Access Gateway appliance before reaching the WI server, then the SSL termination at the gateway will filter out client certificates before traffic reaches the web server.
It should go without saying that this is not an official tested or supported deployment, but it could suffice in some instances to provide smart card authentication to users who are not on the Presentation Server network.
Jay
