You can secure XenApp by using network protocols, ciphersuites, authentication, and authentication methods. You can find information about several security options in this article.
If user devices in your environment communicate with your farm across the Internet, Citrix recommends enabling Secure Sockets Layer (SSL) 3.0 or Transport Layer Security (TLS) 1.0 encryption when you publish a resource. These protocols are collectively referred to SSL/TLS.
SSL 3.0 and TLS 1.0 are not interoperable. However, because there are only minor differences between them, the server certificates in your installation can be used for both SSL and TLS implementations.
When configured properly, deployments using TLS 1.0 can use FIPS 140-validated cryptographic modules in a manner that is compliant with FIPS 140-2; SSL 3.0 is not FIPS compliant. For more information, refer to the Guidelines for the Selection and Use of the Transport Layer Security (TLS) implementations at http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf.
If you want to use SSL/TLS encryption, you must either use the SSL Relay feature or the Secure Gateway or both to relay ICA traffic to the computer running XenApp. For more information, see the information in Installing and Configuring the SSL Relay Tool or XenApp and Secure Gateway.
You can configure XenApp, the Web Interface, and Secure Gateway to use government-approved cryptography to protect "sensitive but unclassified" data by using the applicable ciphersuite:
IP Security (IPSec) is a set of standard extensions to the Internet Protocol (IP) that provides authenticated and encrypted communications with data integrity and replay protection. IPSec is described in Internet RFC 2401.
IPSec is a network-layer protocol set, so higher level protocols such as Citrix Independent Computing Architecture (ICA) can use it without modification. Microsoft Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2, Windows Server 2008, and Windows Server 2003 have built-in support for IPSec.
Although not illustrated in the sample deployments, you can use IPSec to secure a XenApp deployment within a virtual private network (VPN) environment.
Citrix Single Sign-on increases application security for all XenApp applications, allowing organizations to centralize password management while providing users with fast sign-on access to Web, Windows, and host-based applications.
For more information, see the Citrix Single Sign-on documentation.
You can use smart cards with XenApp, supported XenApp plug-ins, the Web Interface, and Single Sign-on to provide secure access to applications and data. Using smart cards simplifies the authentication process while enhancing logon security. XenApp supports smart card authentication to published applications, including “smart card-enabled” applications such as Microsoft Outlook.
In a business network, smart cards are an effective implementation of public key technology and can be used for the following purposes:
If you are using smart cards for secure network authentication, your users can authenticate to applications and content published on your server farms. In addition, smart card functionality within these published applications is also supported.
For example, a published Microsoft Outlook application can be configured to require that users insert a smart card into a smart card reader attached to the client device in order to log on to a XenApp server. After users are authenticated to the application, they can digitally sign email using certificates stored on their smart cards.
Your organization may have specific security policies concerning the use of smart cards. These policies may, for example, state how smart cards are issued and how users should safeguard them. Some aspects of these policies may need to be reassessed in a XenApp environment:
You can reset PINs from the desktop using Microsoft Identity Lifecycle Manager (ILM) and Certificate Lifecycle Manager (CLM) smart card management systems, or using any smart card vendor's reset utilities that use the Windows smart card PC/SC (WinSCard) API.
Citrix supports the use of Personal Computer Smart Card (PC/SC)-based cryptographic smart cards. These cards include support for cryptographic operations such as digital signatures and encryption. Cryptographic cards are designed to allow secure storage of private keys such as those used in Public Key Infrastructure (PKI) security systems. These cards perform the actual cryptographic functions on the smart card itself, meaning that the private key and digital certificates never leave the card. In addition, you can use two-factor authentication for increased security. Instead of merely presenting the smart card (one factor) to conduct a transaction, a user-defined PIN (a second factor) known only to the user, is used to prove that the cardholder is the rightful owner of the smart card.
XenApp supports various smart cards, including the Common Access Card in a deployment that includes the Citrix Receiver for Windows. Contact your Common Access Card vendor or Citrix representative for more information about supported versions of Common Access Card hardware and software.
Citrix continues to test smart cards to address compatibility with XenApp, using certificates from common certificate authorities such as those supported by Microsoft. If you have any concerns regarding your certificate authority and compatibility with XenApp, contact your local Citrix representative.
Kerberos is an authentication protocol. Version 5 of this protocol was first standardized as Internet RFC 1510. Many operating systems, including Microsoft Windows 2000 and later, support Kerberos as a standard feature.
XenApp extends the use of Kerberos. When users log on to a client device, they can connect to XenApp without needing to authenticate again. The user’s password is not transmitted to XenApp; instead, authentication tokens are exchanged using the Generic Security Services API (GSSAPI), which was first standardized in Internet RFC 1509.
This authentication exchange is performed within a Citrix Independent Computing Architecture (ICA) virtual channel and does not require any additional protocols or ports. The authentication exchange is independent of the logon method, so it can be used with passwords, smart cards, or biometrics.
To use Kerberos authentication with XenApp, both the client and server must be appropriately configured. You can also use Microsoft Active Directory Group Policy to selectively disable Kerberos authentication for specific users and servers.
For information on implementing Kerberos Authentication in a XenApp environment, see Knowledge Center article CTX121918.