Product Documentation

Supported smart card deployments

Mar 23, 2015

The following types of smart card deployments are supported by this release and by mixed environments involving this release and Citrix XenDesktop 5.6 Feature Pack 1. The deployments are described in detail in other documents in this section. Other configurations may work but are not supported.

Type StoreFront connectivity
Local domain-joined computers Directly connected
Remote access from domain-joined computers Connected through NetScaler Gateway
Non-domain-joined computers Directly connected
Remote access from non-domain-joined computers Connected through NetScaler Gateway
Non-domain-joined computers and thin clients accessing the Desktop Appliance site Connected through Desktop Appliance sites
Domain-joined computers and thin clients accessing StoreFront through the XenApp Services URL Connected through XenApp Services URLs

The deployment types are defined by these characteristics of the user device to which the smart card reader is connected:

  • Whether the device is domain-joined or non-domain-joined.
  • How the device is connected to StoreFront.
  • What software is used to view virtual desktops and applications.

In addition, smart card-enabled applications, such as Microsoft Word, and Microsoft Excel, can also be used in these deployments. These applications allow users to digitally sign or encrypt documents.

Bimodal authentication

Where possible in each of these deployments, Receiver supports bimodal authentication by offering the user a choice between using a smart card and entering their user name and password. This is useful if the smart card cannot be used (for example, the user has left it at home or the logon certificate has expired).

Because users of non-domain-joined devices log on to Receiver for Windows directly, you can enable users to fall back to explicit authentication. If you configure bimodal authentication, users are initially prompted to log on using their smart cards and PINs but have the option to select explicit authentication if they experience any issues with their smart cards.

If you deploy NetScaler Gateway, users log on to their devices and are prompted by Receiver for Windows to authenticate to NetScaler Gateway. This applies to both domain-joined and non-domain-joined devices. Users can log on to NetScaler Gateway using either their smart cards and PINs, or with explicit credentials. This enables you to provide users with bimodal authentication for NetScaler Gateway logons. Configure pass-through authentication from NetScaler Gateway to StoreFront and delegate credential validation to NetScaler Gateway for smart card users so that users are silently authenticated to StoreFront.

Multiple Active Directory forest considerations

In a Citrix environment, smart cards are supported within a single forest. Smart card logons across forests require a direct two-way forest trust to all user accounts. More complex multi-forest deployments involving smart cards (that is, where trusts are only one-way or of different types) are not supported.

You can use smart cards in a Citrix environment that includes remote desktops. This feature can be installed locally (on the user device that the smart card is connected to) or remotely (on the remote desktop that the user device connects to).

Smart card removal policy

The smart card removal policy set on XenDesktop determines what happens if you remove the smart card from the reader during a session. The smart card removal policy is configured through and handled by the Windows operating system.

Policy setting Desktop behavior

No action

No action.

Lock workstation

The desktop session is disconnected and the virtual desktop is locked.

Force logoff

The user is forced to log off. If the network connection is lost and this setting is enabled, the session may be logged off and the user may lose data.

Disconnect if a remote Terminal Services session

The session is disconnected and the virtual desktop is locked.

Certificate revocation checking

If certificate revocation checking is enabled and a user inserts a smart card with an invalid certificate into a card reader, the user cannot authenticate or access the desktop or application related to the certificate. For example, if the invalid certificate is used for email decryption, the email remains encrypted. If other certificates on the card, such as ones used for authentication, are still valid, those functions remain active.