You can secure XenApp by using network protocols, ciphersuites, authentication, and authentication methods. You can find information about several security options in this article.
You can secure communications between client devices and servers using either the Transport Layer Security (TLS) 1.0 or Secure Sockets Layer (SSL) 3.0 protocols. These protocols are collectively referred to TLS/SSL.
Both TLS and SSL are open protocols that provide data encryption, server authentication, message integrity, and optional client authentication for a TCP/IP connection. Note that both the SSL Relay and Secure Gateway support TLS and SSL.
SSL is an open, nonproprietary security protocol for TCP/IP connections. If you want to use the SSL Relay to secure communications between client devices and servers within the server farm, you must install the SSL Relay on each server in the farm. Alternatively, you can use Secure Gateway. Both the SSL Relay and Secure Gateway implementations are discussed in this documentation.
TLS, which is also an open standard, is the latest, standardized version of the SSL protocol. The SSL Relay also supports TLS; you can configure the SSL Relay, Secure Gateway, and the Web Interface to use TLS. Support for TLS Version 1.0 is included in XenApp 6.0 and Single sign-on 4.8.
Because there are only minor differences between TLS and SSL, the server certificates in your installation can be used for both TLS and SSL implementations.
You can configure XenApp, the Web Interface, and Secure Gateway to use government-approved cryptography to protect “sensitive but unclassified” data.
For RSA key exchange and TripleDES encryption, the government ciphersuite is RSA_WITH_3DES_EDE_CBC_SHA.
Alternatively, for TLS connections, you can use Advanced Encryption Standard (AES) as defined in FIPS 197. The government ciphersuites are RSA_WITH_AES_128_CBC_SHA for 128-bit keys and RSA_WITH_AES_256_CBC_SHA for 256-bit keys.
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 a network-layer protocol set, so higher level protocols such as Citrix ICA can use it without modification.
Although such sample deployments are outside the scope of this document, you can use IPSec to secure a XenApp deployment within a virtual private network (VPN) environment.
IPSec is described in Internet RFC 2401.
Microsoft Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2, Windows Server 2008, and Windows Server 2003 have built-in support for IPSec.
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.
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.
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.
Citrix continues testing various smart cards to address smart card usage and compatibility issues with XenApp.
XenApp supports the Common Access Card in a deployment that includes the Citrix online plug-in 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 tests smart cards 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 is 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) standardized in Internet RFC 1509.
This authentication exchange is performed within an 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 selectively to disable Kerberos authentication for specific users and servers.