Jan. 12, 2017
The biggest trouble with smart card authentication is the sheer complexity of the smart card process. Smart cards live in an ecosystem between Citrix software, Microsoft software, the smart card vendor, and sometimes, a thinclient. Each component of this ecosystem needs to be configured or have middleware installed so they can communicate with one another, which sometimes means there’s no all-encompassing instruction manual to follow. Changing one variable might change the configuration of multiple pieces.
One of the biggest hurdles to overcome is that there is no standard for all smart card vendors to follow. Every vendor writes proprietary extensions for their own smart cards, so there are differences between every card depending on whom it’s made. A smart card from one company might need one set of configuration and middleware, where a smart card from another company will need totally different configurations and middleware.
Doing research on each smart card vendor is crucial to planning the next steps of setting up smart card authentication. Once the smart card is chosen, administrators must purchase middleware, which is sometimes written by a third party, so that the computer can understand the Java applet written in the card.
The two main configurations considerations for smart card in a Citrix Environment are Multiple Active Directory forests and Single Sign-on.
Smart cards are supported with both a single forest and multi-forest in a Citrix XenDesktop 7.6 environment. Appropriate forest and domain trusts are required.
Single Sign-On authentication, sometimes referred to as “pass through,” allows end-point users to enter their pin only once when accessing their operating system. But security implications as well as changes with Microsoft operating systems from Vista onward make it difficult to achieve a seamless single sign-on experience.
To achieve an end-to-end Single Sign-on session, the end point must be using Citrix Receiver, appropriate middleware, and either Windows 7 or Windows 8 (including Embedded Edition), 32-bit and 64-bit when using XenDesktop or using the double-hop method when using XenApp. For further configurations of Single Sign-On authentication, please refer to Appendix 9 of “SmartCard in a Citrix XenDesktop Environment.”
Applying a NetScaler Gateway in front of the Citrix Site also helps the network attain a truer single sign-on experience. NetScaler can take the client’s certificate and pass it through Web Interface or StoreFront to reduce the times needed to recertify.
NetScaler can also be placed in front of a native web application to perform Smart Card Authentication and leverage Kerbros Constrained Delegation to stay FIPS 140 compliant. This works well for legacy Web application that would otherwise need to be rewritten for smart card authentication and FIPS 140 compliance.