Product Documentation

Security Considerations in a XenApp Deployment

May 08, 2015

Security standards as they apply to Citrix XenApp 6.5 for Microsoft Windows Server 2008 R2 are discussed here. These topics provide an overview of the standards that apply to XenApp deployments and describe the issues involved in securing communications across a set of sample XenApp deployments. For more information about the details of the individual security features, refer to the relevant product or component documentation.

When deploying XenApp within large organizations, particularly in government environments, security standards are an important consideration. For example, many government bodies in the United States and elsewhere specify a preference or requirement for applications to be compliant with Federal Information Processing Standards (FIPS) 140. These topics address common issues related to such environments.

What's New in XenApp 6.5 Security Standards

The 6.5 release modifies several XenApp features in order to comply with the new FIPS 140 guidelines for 2010.

  • SHA-256 hashing -
    • The Citrix Streaming Profiler now creates SHA-256 hashes of each file in a profile. When enabled for backwards compatibility with the legacy Offline Plug-in 6.0.x, the Offline Plug-in can verify the integrity of profiles that contain SHA-256 and SHA-1 hashes.
    • SmartAuditor now creates SHA-256 hashes of saved sessions. For backwards compatibility, the SmartAuditor Player can verify the integrity of sessions whose integrity checksum is computed using SHA-256 or SHA-1.
  • 2048-bit RSA keys -
    • IMA Encryption now creates 2048-bit RSA keys.
    • The keys contain both size and algorithm information, and can be imported by any version of XenApp that supports IMA Encryption.
    • IMA Encryption RSA keys are generated only during a new install or when manually changed. If the key is replaced on one server, it must be replaced on all servers. Therefore, there are no issues arising from mixed farms.
    • Application streaming supports certificates containing 2048-bit RSA keys.

Server Farms

A server farm is a collection of XenApp servers that you can manage (from the Delivery Services Console) as a single entity. A server can belong to only one farm, but a farm can include servers from more than one domain. The design of server farms must balance two goals:
  • Providing users with the fastest possible application access
  • Achieving the required degree of centralized administration and network security

Independent Computing Architecture (ICA)

XenApp provides server-based computing to local and remote users through the Independent Computing Architecture (ICA) protocol developed by Citrix. ICA is the communication protocol by which servers and client devices exchange data in a XenApp environment. ICA is optimized to enhance the delivery and performance of this exchange, even on low bandwidth connections.

As an application runs on the server, XenApp intercepts the application’s display data and uses the ICA protocol to send this data (on standard network protocols) to the Citrix Receiver software running on the user’s client device. When the user types on the keyboard or moves and clicks the mouse, the Citrix Receiver software sends the generated data to the application running on the server for processing.

ICA requires minimal client workstation capabilities, and includes error detection and recovery, encryption, and data compression.

Note: The HDX Flash redirection technology may stream Flash content outside of the ICA protocol in separate TCP connections. For more information, see Configuring HDX MediaStream Flash Redirection

Web Interface

In XenApp deployments that include the Web Interface, use HTTPS for communication between the server running the Web Interface and the client devices running Web browsers (and Citrix Receiver software).

SSL Relay and Secure Gateway

In a XenApp deployment, administrators can configure encryption using:

  • SSL Relay, a component that is integrated into XenApp
  • Secure Gateway, a separate component provided on the XenApp installation media

For more information, see SSL/TLS Protocols.

Virtual Channels

The following table shows which Citrix Independent Computing Architecture (ICA) virtual channels or combination of virtual channels can be used with XenApp for authentication, or for and application signing and encryption methods.

Note: This table applies only to XenApp, not to Citrix Single Sign-on.
  Core ICA protocol (no virtual channel) Smart card virtual channel Kerberos virtual channel
Smart card authentication   * *
Biometric1 authentication     *
Password authentication *   *
Application signing/encryption   *  
1 Third-party equipment is required for biometric authentication.

Additional Security Features

The following products can be used with XenApp to provide additional security. These additional security measures are not included in the sample deployments.

ICA Encryption Using SecureICA

ICA encryption with SecureICA is integrated into XenApp. With SecureICA, you can use up to 128-bit encryption to protect the information sent between a XenApp server and users’ client devices. However, it is important to note that SecureICA does not use FIPS 140-compliant algorithms. If this is an issue, configure XenApp servers and plug-ins to avoid using SecureICA.

Authentication for the Web Interface Using RSA SecurID

You can use the third-party product RSA SecurID as an authentication method for the Web Interface running on Internet Information Services. If RSA SecurID is enabled, users must log on using their credentials (user name, password, and domain) plus their SecurID PASSCODE. The PASSCODE is made up of a PIN followed by a tokencode (the number displayed on the user’s RSA SecurID token).

RSA SecurID supports authentication on both XenApp and Citrix Single Sign-on.

Authentication for the Web Interface Using SafeWord

You can use the third-party product Aladdin SafeWord as an authentication method for the Web Interface running on Internet Information Services. If SafeWord is enabled, users must log on using their credentials (user name, password, and domain) plus their SafeWord passcode. The passcode is made up of the code displayed on the user’s SafeWord token, optionally followed by a PIN.

SafeWord supports authentication on XenApp, but not on Single Sign-on.