Smart Cards and NetScaler Gateway are a common XenApp/XenDesktop access scenario for many of our customers – especially in the U.S. Federal space where smart card usage has been mandated for most government agencies. One of the most common requests that we get when implementing Smart Cards is to reduce the number of PIN prompts that a user receives before they can get to their Windows applications or desktops.  In this article I’m going to outline what configurations result in different PIN prompts, primarily in the context of Windows-based client devices accessing the NetScaler Gateway through a web browser.

Let’s go through the different places where we expect to see a PIN prompt in a non-optimized NetScaler Gateway + Smart Card configuration:

  1. Authentication to NetScaler.  We need to authenticate the user with their PIN + Certificate before we can do anything else on the system.  This is accomplished by requiring a client certificate to make the initial SSL connection to NetScaler Gateway.
  2. ICA Connection to NetScaler.  After a user selects a published application or desktop to launch, Citrix Receiver will connect them to the NetScaler Gateway over SSL to begin the ICA session.  If the Gateway vServer asks for a client certificate, the user will receive a PIN prompt.
  3. Windows Authentication to Desktop or XenApp Server.  If single sign-on hasn’t been configured, or isn’t available, the Windows machine hosting the application or desktop that we want to connect to will also ask for the user’s PIN to logon.

Some would say that’s a lot of prompts, and I would tend to agree.  Most users expect that they authenticate only once with their PIN as this is what they are used to on their traditional local Windows devices.

The good news is…it can be done!

Based on the three PIN prompts above let’s talk about how each one can be handled:

  1. Authentication to NetScaler. This prompt is normally needed as it allows us to authenticate the user at the NetScaler before allowing them access to internal resources.  At a minimum the user will need to select their certificate if their Smart Card is configured with multiple certs.  If their PIN is cached by a middleware application from their Windows client logon (like ActivClient), then they won’t need to enter a PIN here.  Otherwise we expect both a certificate selection and PIN entry here.

    1st Prompt – Removable!

    If the client device has middleware that supports and is configured for PIN caching, the user can bypass the PIN prompt for the initial NetScaler Gateway connection.

  2. ICA connection to NetScaler.  This is the easiest prompt to get rid of completely, and just requires that you setup a second NetScaler Gateway vServer that only handles ICA proxy.  This NetScaler Gateway will not be configured to prompt for Client Certificate Check, meaning the SSL ICA connection doesn’t need to prompt the user again.  At Web Interface we would setup Secure Access to point to this vServer instead of the initial authentication NetScaler Gateway.  For information on how to do this in StoreFront using Optimal Gateway Routing, check out Bill Hackley’s blog post : How to reduce SmartCard PIN prompts while using Netscaler Gateway with StoreFront 2.5.If we also create a third NetScaler Gateway vServer we can ensure Web Interface and StoreFront don’t have issues with their HTTPS Authentication Call-Back, allowing us to set Client Certificate Check to Mandatory on the front-end vServer.  The Mandatory setting ensures that we enforce the need for Smart Cards by disallowing any SSL-handshake that does not include a client certificate.Note: The reason I’m separating out the ICA Proxy and the Authentication Call-Back vServer is for customers with requirements to separate internal vs external NetScaler traffic through their firewalls.  This facilitates communication between internal StoreFront or Web Interface servers.  These could technically be combined into a single vServer.Here’s how it looks:

    2nd Prompt – Removable!

    By creating a secondary external NetScaler Gateway vServer without checking for client certificates, we can bypass the second PIN prompt.

  3. Windows Authentication. This one is a little trickier so let’s talk about some different scenarios.Domain Joined Clients.  If the user’s device is joined to the domain (and they authenticated with their Smart Card to Windows), we can simply pass their PIN into the ICA session using our Receiver PIN Pass-through feature.  Our ssonsvr.exe process grabs the PIN from the Windows logon process and will pass it through into the ICA session if it is configured to do so.  Check out http://support.citrix.com/article/CTX130265 for information on setting this up using the icaclient.adm, as well as http://support.citrix.com/article/CTX131223for an additional configuration on Vista/Win 7.Non-Domain Joined Clients.  This is where things are more interesting.  In this case, the user either has a device that is not on the corporate domain, or they log on their Windows client using something besides their Smart Card.  In a standard configuration there is no way for us to pass the PIN through to the ICA Windows session.  At this point you have a couple options:
    1. The user must enter their PIN again.  This results in a total of 2 prompts for them to access their ICA session…one at NetScaler Gateway, and one at Windows.
    2. Use a middleware that supports our Receiver FastConnect technology.  Some Smart Card vendors support our FastConnect API which allows us to store the PIN in Receiver and pass it to the Windows session Using API’s from our SDK, located here.
    3. Use Kerberos Constrained Delegation through Web Interface to impersonate the user to Windows for their logon.  This is described in more detail here: http://support.citrix.com/article/CTX124603. The benefit is that this will get rid of the Windows PIN prompt entirely as the user will be authenticated using a Kerberos Ticket instead.  The downside is that it only currently works with XenApp 6.5 and that Kerberos Constrained Delegation can get complex on the backend depending on what services the user must be impersonated to.  This option is only recommended if reduction of PIN prompts is absolutely necessary and none of the other options are feasible.
    4. Utilize “zero” clients or thin OS devices instead of full Windows-based devices.  It varies per manufacturer and OS, but some are able to natively pass the users PIN directly into the ICA session.  Check with your client vendor for support of this capability.

    3rd Prompt – Removable! 

    If using a domain-joined Windows client with middleware installed and SSO configured, or a zero client that supports PIN passing, this prompt can be bypassed.

As seen above, reducing PIN prompts is much easier when the user is utilizing a client device that is either joined to the AD domain, or has a thin OS that is able to natively pass a PIN through ICA to the Windows authentication process.  If you’re utilizing Smart Card middleware PIN caching, a separate NetScaler Gateway for ICA Proxy, and a domain-joined Windows client, you can potentially get down to zero PIN prompts for access to Citrix!  However, with any client device, your users should see at most 2 prompts if you setup your NetScaler Gateway vServers correctly.

Hopefully this has helped clear up any confusion about utilizing Smart Card for XenApp/XenDesktop access.  Feel free to post any questions in the comments and I’ll respond as soon as possible.