XenApp 6.

5 Security Standards and Deployment Scenarios

2011 Citrix Systems, Inc. All rights reserved. Terms of Use | Trademarks | Privacy Statement

Contents

XenApp 6.5 Security Standards and Deployment Scenarios XenApp 6.5 Security Standards and Deployment Scenarios Security Considerations in a XenApp Deployment Country-Specific Government Information FIPS 140 and XenApp SSL/TLS Protocols Government Ciphersuites IP Security Citrix Single Sign-on Smart Cards Kerberos Authentication Citrix Receiver and Plug-ins Virtual Channels Additional Security Features Deployment Samples Sample A Using the SSL Relay How the Components in Sample Deployment A Interact Security Considerations in Sample Deployment A Sample B Using Secure Gateway (Single-Hop) How the Components in Sample Deployment B Interact Security Considerations for Sample Deployment B Sample C Using Secure Gateway (Double-Hop) How the Components in Sample Deployment C Interact Security Considerations in Sample Deployment C Sample D Using the SSL Relay and the Web Interface How the Components in Sample Deployment D Interact Security Considerations for Sample Deployment D Sample E Using Citrix Single Sign-on and Secure Gateway (Single-Hop) How the Components in Sample Deployment E Interact

4 6 8 10 11 14 16 17 18 19 21 22 25 26 27 28 29 30 32 34 36 38 40 41 43 45 46 48 50

Security Considerations for Deployment Sample E

52

XenApp 6.5 Security Standards and Deployment Scenarios

Citrix products offer the security specialist a wide range of features for securing a XenApp system according to officially recognized standards. 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. These topics are designed for security specialists, systems integrators, and consultants, particularly those working with government organizations worldwide.

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 q

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. For more information, see To support legacy plug-ins.

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 q q

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.

XenApp 6.5 Security Standards and Deployment Scenarios

q

Application streaming supports certificates containing 2048-bit RSA keys.

In This Section
Security Considerations in a XenApp Deployment Deployment Samples

Quick Links
Application Streaming SmartAuditor IMA Encryption Single Sign-On

Security Considerations in a XenApp Deployment

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:
q

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 applications display data and uses the ICA protocol to send this data (on standard network protocols) to the Citrix Receiver software running on the users 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:
q

XenApp also supports sending audio via UDP in a real time protocol (RTP) stream. When this feature is enabled, audio data not transmitted in the ICA protocol, but is instead sent in a separate UDP stream. For more information, see Configuring Audio. 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). 6

XenApp 6.5 Security Standards and Deployment Scenarios

SSL Relay and Secure Gateway

In a XenApp deployment, administrators can configure encryption using:
q

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.

Security Considerations in a XenApp Deployment

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:
q

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 applications display data and uses the ICA protocol to send this data (on standard network protocols) to the Citrix Receiver software running on the users 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:
q

XenApp also supports sending audio via UDP in a real time protocol (RTP) stream. When this feature is enabled, audio data not transmitted in the ICA protocol, but is instead sent in a separate UDP stream. For more information, see Configuring Audio. 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). 8

Security Considerations in a XenApp Deployment

SSL Relay and Secure Gateway

In a XenApp deployment, administrators can configure encryption using:
q

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.

Country-Specific Government Information

The following topics are of particular relevance to XenApp installations in Australia, the United Kingdom, and the United States:
q

FIPS 140 and XenApp SSL/TLS Protocols Smart Cards - includes information on Common Access Cards (of particular relevance to installations in the United States) Kerberos Authentication

For more information about issues specific to your country, contact your local Citrix representative.

10

FIPS 140 and XenApp

Federal Information Processing Standard 140 (FIPS 140) is a U.S. Federal Government standard that specifies a benchmark for implementing cryptographic software. It provides best practices for using cryptographic algorithms, managing key elements and data buffers, and interacting with the operating system. An evaluation process that is administered by the National Institute of Standards and Technology (NIST) National Voluntary Laboratory Accreditation Program (NVLAP) allows encryption product vendors to demonstrate the extent to which they comply with the standard and, thus, the trustworthiness of their implementation. For more information about FIPS 140 and NIST, visit the NIST Web site at http://csrc.nist.gov/cryptval.

FIPS 140 Versions

q

FIPS 140-1, published in 1994, established requirements for cryptographic modules to provide four security levels that allowed cost-effective solutions appropriate for different degrees of data sensitivity and different application environments. FIPS 140-2, which superseded FIPS 140-1 in 2002, incorporated changes in standards and technology since 1994. FIPS 140-3, which is still in draft, adds an additional security level and incorporates new security features that reflect recent advances in technology.

When configured properly, XenApp 6.5 can use FIPS 140-validated cryptographic modules in a manner that is compliant with FIPS 140-2.

Market for FIPS 140-Validated Modules

The security community at large values products that follow the guidelines detailed in FIPS 140 and the use of FIPS 140-validated cryptographic modules. Some U.S. Government organizations restrict purchases of products that contain cryptography to those that use FIPS 140-validated modules. In the U.K., guidance published by the Communications-Electronics Security Group (CESG) recommends the use of FIPS 140-approved products where the required use for information is below the RESTRICTED classification, but is still sensitive (that is, data classified PROTECT). For a list of currently validated FIPS 140 modules, see http://csrc.nist.gov/cryptval/140-1/1401val.htm.

11

FIPS 140 and XenApp

XenApp and Cryptographic Modules

To implement secure access to application servers and to meet the FIPS 140 requirements, Citrix products can use cryptographic modules that are FIPS 140-validated in Windows implementations of secure TLS or SSL connections. The following XenApp components can use cryptographic modules that are FIPS 140-validated:
q

XenApp Citrix Receiver and Citrix online plug-in Web Interface SSL Relay Secure Gateway for Windows Single Sign-on Offline applications (streaming) SmartAuditor Power and Capacity Management Configuration Logging ICA File Signing

Where these client and server components communicate with the TLS or SSL connection enabled, the cryptographic modules that are used are provided by the Microsoft Windows operating system. These modules use the Microsoft Cryptography Application Programming Interface (CryptoAPI) and are FIPS 140-validated. Note: On both Windows Vista with Service Pack 1 and Windows Server 2008, you must apply Microsoft hotfix kb954059 (http://support.microsoft.com/kb/954059) to ensure that the random number generator used within CryptoAPI and, therefore the underlying operating system, is FIPS 140-compliant.

FIPS Compliance
FIPS compliance is achieved as follows:
q

According to the Microsoft documentation (http://technet.microsoft.com/en-us/library/cc750357.aspx), FIPS-compliant systems that use FIPS 140-certified cryptomodules can be deployed by following a prescribed set of steps. These steps include setting a particular FIPS local policy flag. As noted in the Microsoft documentation referenced above, not all Microsoft components and products check the FIPS local policy flag. Refer to the Microsoft documentation for instructions on how to configure these components and products to behave in a FIPS-compliant manner.

12

FIPS 140 and XenApp

q

Similarly, Citrix components do not check the FIPS local policy flag. Instead, these components must be configured to behave in a FIPS-compliant manner. Specifically, Citrix components that use TLS must be configured to use Government Ciphersuites.
q

RSA_WITH_3DES_EDE_CBC_SHA [RFC 2246] RSA_WITH_AES_128_CBC_SHA [FIPS 197, RFC 3268]

RSA_WITH_AES_256_CBC_SHA [FIPS 197, RFC 3268] Given the accuracy of the above statements, and assuming that all these steps are followed, the resulting XenApp configuration will use FIPS 140 cryptomodules in a FIPS-compliant manner.
q

13

SSL/TLS Protocols
If client 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. Both SSL and TLS are open protocols that provide data encryption, server authentication, message integrity, and optional client authentication for a TCP/IP connection:
q

SSL is an open, nonproprietary security protocol for TCP/IP connections. TLS, which is also an open standard, is the latest, standardized version of the SSL protocol.

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.

SSL/TLS and FIPS Compliance

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://csrc.nist.gov/publications/nistpubs/800-52/SP800-52.pdf.

Using SSL/TLS with SSL Relay or Secure Gateway

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 SSL Relay or Secure Gateway documentation. Deployment samples in the XenApp 6.5 Security Standards documentation include implementations of each. The nature of your environment may determine the way in which you enable SSL:
q

For client devices communicating with your farm remotely, Citrix recommends that you use the Secure Gateway to pass client communications to the computer running XenApp. The Secure Gateway can be used with SSL Relay on the computer running XenApp to secure the Secure Gateway to XenApp traffic, depending on your requirements. For client devices communicating with your farm internally, you can do one of the following to pass client communications to the computer running XenApp:
q

Use the Secure Gateway with an internal firewall and place your farm behind the firewall.

14

SSL/TLS Protocols
q

Use the SSL Relay feature to secure the traffic between client devices and servers in your farm.

Note:
q

If you use SSL Relay, you must install it on every server in the farm. Because SSL Relay requires you to store certificates on each server, it may be less convenient for larger environments. If your farm has more than five servers and you are concerned with internal threats, you may prefer to use the Secure Gateway with an internal firewall. To use SSL with the Secure Gateway or SSL Relay, you must select the Enable SSL and TLS protocols setting when you publish an application. If you are using Web Interface with the Secure Gateway, see the information about SSL in the Secure Gateway and Web Interface administrator documentation.

15

Government Ciphersuites
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:
q

RSA_WITH_3DES_EDE_CBC_SHA supports RSA key exchange and TripleDES encryption, as defined in Internet RFC 2246 (http://www.ietf.org/rfc/rfc2246.txt). RSA_WITH_AES_128_CBC_SHA supports RSA key exchange with Advanced Encryption Standard (AES) and 128-bit keys for TLS connections, as defined in FIPS 197 http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf and Internet RFC 3268 (http://www.ietf.org/rfc/rfc3268.txt). For more information about AES, see http://csrc.nist.gov/cryptval/des.htm. RSA_WITH_AES_256_CBC_SHA supports RSA key exchange with AES and 256-bit keys for TLS connections, as defined in FIPS 197 and RFC 3268.

16

IP Security
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.

17

Citrix Single Sign-on

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.

18

Smart Cards
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:
q

Authenticating users to networks and computers Securing channel communications over a network Securing content using digital signatures

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. Note: The availability of some smart card features depends on the smart card cryptographic service provider (CSP).

Secure Use of 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:
q

Tasks performed by smart card administrators (for example smart card issuance) may be inappropriate for carrying out through XenApp. Usually these functions are performed at a dedicated smart card station, and may require two smart card readers. Infrequent and sensitive tasks, such as unblocking a smart card, may also be inappropriate for carrying out through XenApp. Security policies often forbid users to perform these functions; they are carried out by the smart card administrator. Note: Citrix recommends that you carry out these tasks locally on the user device if possible, rather than using XenApp.

Highly sensitive applications that require strict separation of duties or tamper-resistant audit trails may entail additional special-purpose security control measures. These measures are outside the scope of XenApp.

19

Smart Cards 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.

Smart Card Support

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.

20

Kerberos Authentication
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 users 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.

21

Citrix Receiver and Plug-ins

With Citrix Receiver or the Citrix online plug-in installed on their client devices, users can work with applications running on XenApp servers. Users can access these applications from virtually any type of client device over many types of network connection, including LAN, WAN, dial-up, and direct asynchronous connections. Because the applications are not downloaded to the client devices (as is the case with the more traditional network architecture), application performance is not limited by bandwidth or device performance. Citrix Receiver is available for Windows, Windows CE, Macintosh, Linux, Solaris, Android, Blackberry, and iOS operating systems, as well as the Java Runtime Environment. Additionally, you can use the Citrix online plug-in Web with Web browsers that support ActiveX controls or Netscape plug-ins. Citrix Receiver for Windows and the Citrix online plug-in use cryptographic modules provided by the operating system. Other plug-ins, including Citrix Receiver for Java, contain their own cryptographic modules. Citrix Receiver for Java can, therefore, be used on older Windows operating systems that do not support strong encryption. The Standards Summary table lists the latest versions of Citrix Receiver available on various platforms and indicates whether each plug-in is FIPS 140 compliant, supports TLS, uses 3DES or AES government ciphersuites, supports certificate revocation checking, includes smart card support, or supports Kerberos authentication.

Standards Summary
The following table summarizes the security standards relevant to Citrix Receiver and the Citrix online plug-in:

Platform and Version Citrix Receiver for Windows 3.0 Citrix Receiver for Windows CE for Windows-Based Terminals 11.02 Citrix Receiver for Windows CE for Handheld and Pocket PCs 11.02 Citrix Receiver for Macintosh 11.3 Citrix Receiver for Linux 12.1

FIPS 140 *1 *2

TLS * *

Triple DES * *

AES *

CRL check *3

Smart card * *

Kerberos *

*2

* *

* *

* *

22

Citrix Receiver and Plug-ins Citrix Receiver for Sun Solaris 8.63 Citrix Receiver for Java 10.1 Citrix Receiver for Android 2.1 Citrix Receiver for BlackBerry 2.1 Citrix Receiver for Playbook 1.0 Citrix Receiver for iOS 4.2.3 Citrix online plug-in 12.1 Citrix online plug-in Web 12.1 Notes:
1 2

* * * *

* * * * *

* * * *

*3 * *5

*4

*1 *
1

* *

* *

* *

*3 *
3

* *

* *

These plug-ins inherit FIPS 140 compliance from the base operating system, Windows.

These plug-ins inherit FIPS 140 compliance from the base operating system, Windows CE.
3

Certificate revocation checking is only applicable to plug-ins running on Windows XP, Windows Vista, or Windows 7.
4

Kerberos authentication is not supported when the Citrix Receiver for Java is running on Mac OS X client devices.
5

Certificate revocation checking is subject to device configuration.

Root Certificate Source

The table below shows the root certificate source for each version of the Citrix Receiver or Citrix online plug-in.

Plug-in type Citrix Receiver for Windows 3.0 Citrix Receiver for Windows CE for Windows-Based Terminals 11.02 Citrix Receiver for Windows CE for Handheld and Pocket PCs 11.02 Citrix Receiver for Macintosh 11.3 Citrix Receiver for Linux 12.1 Citrix Receiver for Sun Solaris 8.63

Root certificate source operating system certificate store operating system certificate store operating system certificate store operating system certificate store bundled with the plug-in bundled with the plug-in

23

Citrix Receiver and Plug-ins Citrix Receiver for Java 10.1 Java keystore (Java 1.4.x) Java keystore or operating system certificate store (Java 1.5.x or later) Citrix Receiver for Android 2.1 Citrix Receiver for BlackBerry 2.1 Citrix Receiver for Playbook 1.0 Citrix Receiver for iOS 4.2.3 Citrix online plug-in 12.1 Citrix online plug-in Web 12.1 operating system certificate store operating system certificate store Android keystore operating system certificate store bundled with the plug-in

24

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.

Smart card authentication Biometric1 authentication Password authentication Application signing/encryption

1

Core ICA protocol (no virtual channel) *

Smart card virtual channel * *

Kerberos virtual channel * * *

Third-party equipment is required for biometric authentication.

25

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 users 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 users SafeWord token, optionally followed by a PIN. SafeWord supports authentication on XenApp, but not on Single Sign-on.

26

Deployment Samples
To make a XenApp deployment FIPS 140-compliant, you need to consider each communication channel within the installation. The following deployment samples show how users can connect to XenApp servers with different configurations of components and firewalls. In particular, the samples provide general guidance on how to make each communication channel secure using SSL/TLS so that the system as a whole is FIPS 140-compliant.
q

Sample A - Using the SSL Relay Sample B - Using Secure Gateway (Single-Hop) Sample C - Using Secure Gateway (Double-Hop) Sample D - Using the SSL Relay and the Web Interface Sample E - Using Citrix Single Sign-on and Secure Gateway (Single-Hop)

Note: Secure Gateway and the SSL Relay support both SSL- and TLS-based encryption. Your choice of method is largely determined by which topology best meets the needs of your organizations security policies. Refer to SSL/TLS Protocols for more information.

27

Sample A Using the SSL Relay

This deployment uses the SSL Relay to provide end-to-end SSL/TLS encryption between the XenApp server and Citrix Receiver running on the user devices. This diagram shows sample deployment A, which uses the SSL Relay.

The following table lists the components of the deployment and the operating systems required for the servers and client devices.

XenApp farm

Components XenApp 6.5 for Microsoft Windows Server 2008 R2 SSL Relay enabled Secure Ticket Authority installed on XenApp server

Operating systems Windows Server 2008 R2

User devices

Citrix Receiver for Windows 3.0 TLS-enabled Web browser

Windows 7 Windows Vista Windows XP Professional

28

How the Components in Sample Deployment A Interact

Use SSL/TLS to secure the connections between client devices and the XenApp servers. To do this, deploy SSL/TLS-enabled plug-ins to users and configure the SSL Relay on the XenApp servers. This deployment provides end-to-end encryption of the communication between the client device and the XenApp servers. Both the SSL Relay and the appropriate server certificate must be installed and configured on each server in the farm. The SSL Relay operates as an intermediary in communication between client devices and the XML Service on each server. Each client device authenticates the SSL Relay by checking the SSL Relays server certificate against a list of trusted certificate authorities. After this authentication, the client device and the SSL Relay negotiate requests in encrypted form. The SSL Relay decrypts the requests and passes them to the XenApp servers. All information sent from the servers to the client device passes through the SSL Relay, which encrypts the data and forwards it to the client device to be decrypted. Message integrity checks verify that each communication has not been tampered with. This diagram shows a detailed view of sample deployment A.

29

Security Considerations in Sample Deployment A

FIPS 140 Validation in Sample Deployment A
In this deployment, the SSL Relay uses the Microsoft cryptographic service providers (CSPs) and associated cryptographic algorithms available in the Microsoft Windows CryptoAPI to encrypt and decrypt communication between client devices and servers. For more information about the FIPS 140 validation of the CSPs, see the Microsoft documentation. SSL/TLS support and the supported ciphersuites can also be controlled using the Microsoft security option System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing for the following configurations: XenApp farm XenApp 6.5 XenApp 6.0 Operating System Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2 Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2

XenApp 5.0 Windows Server 2008, Windows Server 2003 For more information, see the documentation for your operating system.

SSL/TLS Support in Sample Deployment A

You can configure XenApp to use either the Secure Sockets Layer 3.0 protocol or the Transport Layer Security 1.0 protocol. In sample deployment A, the components are configured for TLS. When using the SSL Relay Configuration Tool, ensure that TLS is selected on the Connection tab.

Supported Ciphersuites for Sample Deployment A

In this deployment, XenApp can be configured to use government-approved cryptography, such as the ciphersuite RSA_WITH_3DES_EDE_CBC_SHA, to protect sensitive but unclassified data. When using the SSL Relay Configuration Tool, ensure that only GOV is selected on the Ciphersuite tab. For TLS connections, you can choose other Government Ciphersuites that employ RSA key exchange and the Advanced Encryption Standard (AES).

30

Security Considerations in Sample Deployment A

Certificates and Certificate Authorities in Sample Deployment A

Citrix products use standard Public Key Infrastructure (PKI) as a framework and trust infrastructure. In sample deployment A, a separate server certificate is configured for each XenApp server on which the SSL Relay is used. A root certificate is required for each client device. For information on the root certificate source for your client devices, see Citrix Receiver and Plug-ins

Smart Card Support in Sample Deployment A

In this deployment, you can configure XenApp to provide smart card authentication. To do this, you must configure authentication with Microsoft Active Directory and use the Microsoft Certificate Authority.

Plug-ins Used in Sample Deployment A

In this deployment, users access their applications using Citrix Receiver. For more information about the security features and capabilities of Citrix Receiver, see Citrix Receiver and Plug-ins.

31

Sample B Using Secure Gateway (Single-Hop)

This deployment uses the Secure Gateway in a single-hop configuration to provide SSL/TLS encryption between a secure Internet gateway server and an SSL-enabled plugin. Encrypted communication between the Web browser and the Web server is via HTTPS. Additionally, you can secure ICA traffic within the internal network using IPSec. This diagram shows sample deployment B, which uses the Secure Gateway in a single-hop configuration.

The following table lists the components of the deployment and the operating systems required for the servers and client devices.

XenApp farm

Components XenApp 6.5 for Microsoft Windows Server 2008 R2 SSL Relay enabled Secure Ticket Authority installed on XenApp server

Operating systems Windows Server 2008 R2

32

Sample B Using Secure Gateway (Single-Hop) Web server Web Interface 5.4 for Internet Information Services Windows Server 2008 R2 Windows Server 2008 Windows Server 2003 with Service Pack 2 .NET Framework 3.5 or 2.0 (IIS 6.0 only) Visual J#.NET 2.0 Second Edition Secure Gateway server Secure Gateway 3.3 for Windows Windows Server 2008 R2 Windows Server 2008 Windows Server 2003 with Service Pack 2 User devices Citrix Receiver for Windows 3.0 TLS-enabled Web browser Windows 7 Windows Vista Windows XP Professional

33

How the Components in Sample Deployment B Interact

Use TLS to secure the connections between client devices and the Secure Gateway. To do this, deploy SSL/TLS-enabled plugins and configure the Secure Gateway at the network perimeter, typically in a demilitarized zone (DMZ). Secure the connections between users Web browsers and the Web Interface using HTTPS. Additionally, secure communication between the Web Interface and the XenApp servers using TLS. This diagram shows a detailed view of sample deployment B.1.

In this deployment, the Secure Gateway removes the need to publish the address of every XenApp server in the farm and provides a single point of encryption and access to the farm. The Secure Gateway does this by providing a gateway that is separate from the XenApp servers and reduces the issues for firewall traversal to a widely-accepted port for ICA traffic in and out of the firewalls. While sample deployment B.1 is highly scalable, the trade-off is that ICA communication is encrypted only between client devices and the Secure Gateway, not between the Secure Gateway and the XenApp servers. Note: The SSL Relay in sample deployment B.1 is used to encrypt communication between the Web Interface and the XML Service running on the XenApp servers. The Secure Gateway communicates with the XenApp servers directly, so the SSL Relay is not used for communication between the Secure Gateway and the server farm. You can secure the communication between the Secure Gateway and the server farm using IPSec, as shown in sample deployment B.2. This diagram shows a detailed view of sample deployment B.2, which includes IPSec.

34

How the Components in Sample Deployment B Interact

35

Security Considerations for Sample Deployment B

IPSec in Sample Deployment B
To enable IPSec to secure communication between Secure Gateway and the XenApp server farm, you must configure IPSec on each server, including the Secure Gateway server. IPSec is configured using the local security settings (IP security policies) for each server. In sample deployment B.2, IPSec is enabled on the requisite servers and the security method is configured for Triple DES encryption and SHA-1 integrity to meet FIPS 140 requirements.

FIPS 140 Validation in Sample Deployment B

In this deployment, the SSL Relay uses the Microsoft cryptographic service providers (CSPs) and associated cryptographic algorithms available in the Microsoft Windows CryptoAPI to encrypt and decrypt communication between client devices and servers. For more information about the FIPS 140 validation of the CSPs, see the Microsoft documentation. SSL/TLS support and the supported ciphersuites can also be controlled using the Microsoft security option System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing for the following configurations: XenApp farm XenApp 6.5 XenApp 6.0 Operating System Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2 Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2

XenApp 5.0 Windows Server 2008, Windows Server 2003 For more information, see the documentation for your operating system.

SSL/TLS Support in Sample Deployment B

You can configure Secure Gateway and the Web Interface to use either the Transport Layer Security 1.0 protocol or the Secure Sockets Layer 3.0 protocol. In sample deployment B, the components are configured for TLS.

Supported Ciphersuites for Sample Deployment B

In this deployment, Secure Gateway and the Web Interface can be configured to use government-approved cryptography, such as the ciphersuite RSA_WITH_3DES_EDE_CBC_SHA, to protect sensitive but unclassified data.

36

Security Considerations for Sample Deployment B For TLS connections, you can choose other Government Ciphersuites that employ RSA key exchange and the Advanced Encryption Standard (AES).

Certificates and Certificate Authorities in Sample Deployment B

Citrix products use standard Public Key Infrastructure (PKI) as a framework and trust infrastructure. In sample deployment B, one server certificate is configured on Secure Gateway and one on the Web Interface. A certificate is also configured on each XenApp server. A root certificate is required for each client device. For information on the root certificate source for your client devices, see Citrix Receiver and Plug-ins.

Smart Card Support in Sample Deployment B

In this deployment, you can configure XenApp to provide smart card authentication. To do this, you must configure authentication with Microsoft Active Directory and use the Microsoft Certificate Authority.

Plug-ins Used in Sample Deployment B

In this deployment, users access their applications using Citrix Receiver. For more information about the security features and capabilities of Citrix Receiver, see Citrix Receiver and Plug-ins.

37

Sample C Using Secure Gateway (Double-Hop)

This deployment uses the Secure Gateway in a double-hop configuration to provide SSL/TLS encryption between a secure Internet gateway server and an SSL-enabled plugin. Encrypted communication between the Secure Gateway and the Web browser, and between the Secure Gateway and the Web interface, is via HTTPS. ICA traffic within the internal network is secured using IPSec. This diagram shows sample deployment C, which uses the Secure Gateway in a double-hop configuration.

The following table lists the components of the deployment and the operating systems required for the servers and client devices.

XenApp farm

Components XenApp 6.5 for Microsoft Windows Server 2008 R2 SSL Relay enabled Secure Ticket Authority installed on XenApp server

Operating systems Windows Server 2008 R2

38

Sample C Using Secure Gateway (Double-Hop) Web server Web Interface 5.4 for Internet Information Services Windows Server 2008 R2 Windows Server 2008 Windows Server 2003 with Service Pack 2 .NET Framework 3.5 or 2.0 (IIS 6.0 only) Visual J#.NET 2.0 Second Edition Secure Gateway Service Secure Gateway Proxy User devices Citrix Receiver for Windows 3.0 TLS-enabled Web browser Secure Gateway 3.3 for Windows Windows Server 2008 R2 Windows Server 2008 Windows Server 2003 with Service Pack 2 Windows 7 Windows Vista Windows XP Professional

39

How the Components in Sample Deployment C Interact

Use TLS to secure the connections between client devices and the Secure Gateway. To do this, deploy SSL/TLS-enabled plug-ins and configure the Secure Gateway at the network perimeter, typically in a DMZ. Here, the DMZ is divided into two sections by an additional firewall. The server running the Secure Gateway Service is located in the first section of the DMZ; the Web Interface and the Secure Gateway Proxy are located in the second section. Communication between the Secure Gateway Proxy and the server farm is secured using IPSec. This diagram shows a detailed view of sample deployment C.

In this deployment, the Secure Gateway removes the need to publish the address of every XenApp server in the farm and provides a single point of encryption and access to the farm. The Secure Gateway does this by providing a gateway that is separate from the XenApp servers and reduces the issues for firewall traversal to a widely-accepted port for ICA traffic in and out of the firewalls.

40

Security Considerations in Sample Deployment C

IPSec in Sample Deployment C
To enable IPSec to secure communication between the Secure Gateway Proxy and the XenApp server farm, you must configure IPSec on each server, including the Secure Gateway Proxy. IPSec is configured using the local security settings (IP security policies) for each server. In sample deployment C, IPSec is enabled on the requisite servers and the security method is configured for Triple DES encryption and SHA-1 integrity to meet FIPS 140 requirements.

FIPS 140 Validation in Sample Deployment C

In this deployment, the SSL Relay uses the Microsoft cryptographic service providers (CSPs) and associated cryptographic algorithms available in the Microsoft Windows CryptoAPI to encrypt and decrypt communication between client devices and servers. For more information about the FIPS 140 validation of the CSPs, see the Microsoft documentation. SSL/TLS support and the supported ciphersuites can also be controlled using the Microsoft security option System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing for the following configurations: XenApp farm XenApp 6.5 XenApp 6.0 Operating System Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2 Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2

XenApp 5.0 Windows Server 2008, Windows Server 2003 For more information, see the documentation for your operating system.

SSL/TLS Support in Sample Deployment C

You can configure Secure Gateway and the Web Interface to use either the Transport Layer Security 1.0 protocol or the Secure Sockets Layer 3.0 protocol. In sample deployment C, the components are configured for TLS.

Supported Ciphersuites for Sample Deployment C

In this deployment, Secure Gateway, the Secure Gateway Proxy, and the Web Interface can be configured to use government-approved cryptography, such as the ciphersuite RSA_WITH_3DES_EDE_CBC_SHA, to protect sensitive but unclassified data.

41

Security Considerations in Sample Deployment C For TLS connections, you can choose other Government Ciphersuites that employ RSA key exchange and the Advanced Encryption Standard (AES).

Certificates and Certificate Authorities in Sample Deployment C

Citrix products use standard Public Key Infrastructure (PKI) as a framework and trust infrastructure. In sample deployment C, one server certificate is configured on Secure Gateway, one on the Secure Gateway Proxy, and one on the Web Interface. A certificate is also configured on each XenApp server. A root certificate is required for each client device. For information on the root certificate source for your client devices, see Citrix Receiver and Plug-ins.

Smart Card Support in Sample Deployment C

Smart card authentication is not supported in sample deployment C. You cannot configure smart card support when Secure Gateway is positioned between the client devices and the Web Interface to provide a single point of access to the server farm.

Plug-ins Used in Sample Deployment C

In this deployment, users access their applications using Citrix Receiver. For more information about the security features and capabilities of Citrix Receiver, see Citrix Receiver and Plug-ins.

42

Sample D Using the SSL Relay and the Web Interface

This deployment uses the SSL Relay and the Web Interface to encrypt the ICA and HTTP communication between the XenApp server and the Web server. Encrypted communication between the Web browser and the Web server is via HTTPS. This diagram shows sample deployment D, which uses the SSL Relay and the Web Interface.

The following table lists the components of the deployment and the operating systems required for the servers and client devices.

XenApp farm

Components XenApp 6.5 for Microsoft Windows Server 2008 R2 SSL Relay enabled Secure Ticket Authority installed on XenApp server

Operating systems Windows Server 2008 R2

43

Sample D Using the SSL Relay and the Web Interface Web server Web Interface 5.4 for Internet Information Services Windows Server 2008 R2 Windows Server 2008 Windows Server 2003 with Service Pack 2 .NET Framework 3.5 or 2.0 (IIS 6.0 only) Visual J#.NET 2.0 Second Edition User devices Citrix Receiver for Windows 3.0 TLS-enabled Web browser Windows 7 Windows Vista Windows XP Professional

44

How the Components in Sample Deployment D Interact

Use HTTPS to secure the connections between users Web browsers and the Web Interface. Secure the connection between the Web Interface and the SSL Relay using TLS. Additionally, use TLS to secure the connections between client devices and the SSL Relay. The SSL Relay operates as an intermediary in communication between client devices, the Web Interface, and the XML Service on each server. Each client device authenticates the SSL Relay by checking the SSL Relays server certificate against a list of trusted certificate authorities. After this authentication, the client device and the SSL Relay negotiate requests in encrypted form. The SSL Relay decrypts the requests and passes them to the XenApp servers. All information sent from the servers to the client device passes through the SSL Relay, which encrypts the data and forwards it to the client device to be decrypted. Message integrity checks verify that each communication has not been tampered with. This diagram shows a detailed view of sample deployment D.

45

Security Considerations for Sample Deployment D

FIPS 140 Validation in Sample Deployment D
In this deployment, the SSL Relay uses the Microsoft cryptographic service providers (CSPs) and associated cryptographic algorithms available in the Microsoft Windows CryptoAPI to encrypt and decrypt communication between client devices and servers. For more information about the FIPS 140 validation of the CSPs, see the Microsoft documentation. SSL/TLS support and the supported ciphersuites can also be controlled using the Microsoft security option System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing for the following configurations: XenApp farm XenApp 6.5 XenApp 6.0 Operating System Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2 Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2

XenApp 5.0 Windows Server 2008, Windows Server 2003 For more information, see the documentation for your operating system.

SSL/TLS Support in Sample Deployment D

You can configure the SSL Relay and the Web Interface to use either the Secure Sockets Layer 3.0 protocol or the Transport Layer Security 1.0 protocol. In sample deployment D, the components are configured for TLS. When using the SSL Relay Configuration Tool, ensure that TLS is selected on the Connection tab.

Supported Ciphersuites for Sample Deployment D

In this deployment, the SSL Relay and the Web Interface can be configured to use government-approved cryptography, such as the ciphersuite RSA_WITH_3DES_EDE_CBC_SHA, to protect sensitive but unclassified data. When using the SSL Relay Configuration Tool, ensure that only GOV is selected on the Ciphersuite tab. For TLS connections, you can choose other Government Ciphersuites that employ RSA key exchange and the Advanced Encryption Standard (AES).

46

Security Considerations for Sample Deployment D

Certificates and Certificate Authorities in Sample Deployment D

Citrix products use standard Public Key Infrastructure (PKI) as a framework and trust infrastructure. In sample deployment D, a separate server certificate is configured for each XenApp server on which the SSL Relay is used. A root certificate is required for each client device. For information on the root certificate source for your client devices, see Citrix Receiver and Plug-ins.

Smart Card Support in Sample Deployment D

In this deployment, you can configure XenApp to provide smart card authentication. To do this, you must configure authentication with Microsoft Active Directory and use the Microsoft Certificate Authority.

Plug-ins Used in Sample Deployment D

In this deployment, users access their applications using Citrix Receiver. For more information about the security features and capabilities of Citrix Receiver, see Citrix Receiver and Plug-ins.

47

Sample E Using Citrix Single Sign-on and Secure Gateway (Single-Hop)

This deployment uses Citrix Single Sign-on and the Secure Gateway in a single-hop configuration to enable single sign-on and SSL/TLS encryption between a secure Internet gateway server and an SSL-enabled plug-in. Encrypted communication between the Web browser and the Web server is via HTTPS. ICA traffic within the internal network is secured using IPSec. See the Citrix Single Sign-on documentation for further information about the Citrix Single Sign-on components in this deployment. This diagram shows sample deployment E, which uses Citrix Single Sign-on and the Secure Gateway.

Note: The Citrix Single Sign-on central store is hosted on two servers (primary and secondary), both running Active Directory. The secondary server is only used to provide failover for the primary server. The following table lists the components of the deployment and the operating systems required for the servers and client devices.

Components

Operating systems

48

Sample E Using Citrix Single Sign-on and Secure Gateway (Single-Hop) XenApp farm XenApp 6.5 for Microsoft Windows Server 2008 SSL Relay not enabled Secure Ticket Authority installed on XenApp server Citrix Single Sign-on 5.0 plug-in Citrix Single Sign-on Service Citrix Single Sign-on 5.0 Service Windows Server 2008 R2 Windows Server 2008 (32-bit) Windows Server 2003 with Service Pack 2 (32-bit) Windows Server 2003 R2 (32-bit) .NET Framework 3.5 Service Pack 1 Citrix Single Sign-on central store Citrix Single Sign-on 5.0 central store Windows Server 2008 R2 Windows Server 2008 Windows Server 2003 with Service Pack 2 Web server Web Interface 5.4 for Internet Information Services Windows Server 2008 R2 Windows Server 2008 Windows Server 2003 with Service Pack 2 .NET Framework 3.5 or 2.0 (IIS 6.0 only) Visual J#.NET 2.0 Second Edition Secure Gateway server Secure Gateway 3.3 for Windows Windows Server 2008 R2 Windows Server 2008 Windows Server 2003 with Service Pack 2 User devices Citrix Receiver for Windows 3.0 TLS-enabled Web browser Windows 7 Windows Vista Windows XP Professional Windows Server 2008 R2 Java 1.4.x or later

49

How the Components in Sample Deployment E Interact

Use TLS to secure the connections between client devices and the Secure Gateway. To do this, deploy SSL/TLS-enabled plug-ins and configure the Secure Gateway at the network perimeter, typically in a demilitarized zone (DMZ). Secure the connections between users Web browsers and the Web Interface using HTTPS. Additionally, use TLS to secure communication between the Web Interface and the XenApp server farm, and between the farm and the Citrix Single Sign-on central store and Single Sign-on service. Secure the communication between the Secure Gateway and the server farm using IPSec. In this deployment, the Secure Gateway removes the need to publish the address of every XenApp server in the farm and provides a single point of encryption and access to the farm. The Secure Gateway does this by providing a gateway that is separate from the XenApp servers and reduces the issues for firewall traversal to a widely-accepted port for ICA traffic in and out of the firewalls. Sample deployment E is highly scalable. ICA communication is encrypted between client devices and Secure Gateway, as well as between the Secure Gateway and the XenApp servers. This diagram shows a detailed view of sample deployment E.

50

How the Components in Sample Deployment E Interact

51

Security Considerations for Deployment Sample E

IPSec in Sample Deployment E
To enable IPSec to secure communication between Secure Gateway and the XenApp server farm, you must configure IPSec on each server, including the Secure Gateway server. IPSec is configured using the local security settings (IP security policies) for each server. In sample deployment E, IPSec is enabled on the requisite servers and the security method is configured for Triple DES encryption and SHA-1 integrity to meet FIPS 140 requirements.

FIPS 140 Validation in Sample Deployment E

In this deployment, the SSL Relay uses the Microsoft cryptographic service providers (CSPs) and associated cryptographic algorithms available in the Microsoft Windows CryptoAPI to encrypt and decrypt communication between client devices and servers. For more information about the FIPS 140 validation of the CSPs, see the Microsoft documentation. SSL/TLS support and the supported ciphersuites can also be controlled using the Microsoft security option System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing for the following configurations: XenApp farm XenApp 6.5 XenApp 6.0 Operating System Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2 Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2

XenApp 5.0 Windows Server 2008, Windows Server 2003 For more information, see the documentation for your operating system.

SSL/TLS Support in Sample Deployment E

In this deployment, you can configure Secure Gateway and the Web Interface to use the Transport Layer Security 1.0 protocol.

Supported Ciphersuites for Sample Deployment E

In this deployment, Secure Gateway and the Web Interface can be configured to use government-approved cryptography, such as the ciphersuite RSA_WITH_3DES_EDE_CBC_SHA, to protect sensitive but unclassified data. For TLS connections, you can choose other Government Ciphersuites that employ RSA key exchange and the Advanced Encryption Standard (AES). 52

Security Considerations for Deployment Sample E

Certificates and Certificate Authorities in Sample Deployment E

Citrix products use standard Public Key Infrastructure (PKI) as a framework and trust infrastructure. In sample deployment E, one server certificate is configured on Secure Gateway and one on the Web Interface. A certificate is also configured on each XenApp server and on the server running the Password Manager service. A root certificate is required for each client device. For information on the root certificate source for your client devices, see Citrix Receiver and Plug-ins.

Smart Card Support in Sample Deployment E

In this deployment, you can configure XenApp to provide smart card authentication. To do this, you must configure authentication with Microsoft Active Directory and use the Microsoft Certificate Authority.

Plug-ins Used in Sample Deployment E

In this deployment, users access their applications using Citrix Receiver. For more information about the security features and capabilities of Citrix Receiver, see Citrix Receiver and Plug-ins.

53