En.xenapp.ps Sec Node Wrapper Xa65
-
Upload
emailurashok -
Category
Documents
-
view
216 -
download
0
Transcript of En.xenapp.ps Sec Node Wrapper Xa65
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
1/53
XenApp 6.5 Security Standards andDeployment Scenarios
2011 Citrix Systems, Inc. All rights reserved. Terms of Use | Trademarks | Privacy Statement
http://www.citrix.com/legalhttp://www.citrix.com/trademarkhttp://www.citrix.com/legal -
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
2/53
Contents
XenApp 6.5 Security Standards and Deployment Scenarios 4
XenApp 6.5 Security Standards and Deployment Scenarios 6
Security Considerations in a XenApp Deployment 8
Country-Specific Government Information 10
FIPS 140 and XenApp 11
SSL/TLS Protocols 14
Government Ciphersuites 16
IP Security 17
Citrix Single Sign-on 18
Smart Cards 19
Kerberos Authentication 21
Citrix Receiver and Plug-ins 22
Virtual Channels 25
Additional Security Features 26
Deployment Samples 27
Sample A Using the SSL Relay 28
How the Components in Sample Deployment A Interact 29
Security Considerations in Sample Deployment A 30
Sample B Using Secure Gateway (Single-Hop) 32
How the Components in Sample Deployment B Interact 34
Security Considerations for Sample Deployment B 36
Sample C Using Secure Gateway (Double-Hop) 38
How the Components in Sample Deployment C Interact 40
Security Considerations in Sample Deployment C 41
Sample D Using the SSL Relay and the Web Interface 43
How the Components in Sample Deployment D Interact 45
Security Considerations for Sample Deployment D 46
Sample E Using Citrix Single Sign-on and Secure Gateway (Single-Hop) 48
How the Components in Sample Deployment E Interact 50
2
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
3/53
Security Considerations for Deployment Sample E 52
3
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
4/53
4
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, manygovernment 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 140guidelines for 2010.
q 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.
q 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.q 2048-bit RSA keys -
q IMA Encryption now creates 2048-bit RSA keys.
q The keys contain both size and algorithm information, and can be imported by any
version of XenApp that supports IMA Encryption.
q 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.
http://support.citrix.com/proddocs/index.jsp?lang=en&topic=/xenapp65-publishing/ps-stream-profile-task-legacy.html -
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
5/53
q Application streaming supports certificates containing 2048-bit RSA keys.
In This Section
Security Considerations in a XenApp Deployment
Deployment Samples
Quick LinksApplication Streaming
SmartAuditor
IMA Encryption
Single Sign-On
XenApp 6.5 Security Standards and Deployment Scenarios
5
http://support.citrix.com/proddocs/index.jsp?lang=en&topic=/passwordmanager-5-0/pm-landing-page-version-50.htmlhttp://support.citrix.com/proddocs/index.jsp?lang=en&topic=/xenapp65-planning/ps-planning-config-log-ima-encrypt-v2.htmlhttp://support.citrix.com/proddocs/index.jsp?lang=en&topic=/xenapp65-w2k8/ps-sa-library-wrapper-v2.htmlhttp://support.citrix.com/proddocs/index.jsp?lang=en&topic=/xenapp65-planning/ps-planning-streaming-v2.html -
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
6/53
6
Security Considerations in a XenApp
Deployment
Server FarmsA 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
q
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 CitrixReceiver 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.
q 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 InterfaceIn 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).
http://support.citrix.com/proddocs/index.jsp?lang=en&topic=/xenapp65-admin/hd-flash-wrapper-ad.htmlhttp://support.citrix.com/proddocs/index.jsp?lang=en&topic=/xenapp65-admin/hd-flash-wrapper-ad.htmlhttp://support.citrix.com/proddocs/index.jsp?lang=en&topic=/xenapp65-admin/hd-audio-settings-ad.html -
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
7/53
SSL Relay and Secure GatewayIn a XenApp deployment, administrators can configure encryption using:
q
SSL Relay, a component that is integrated into XenApp
q Secure Gateway, a separate component provided on the XenApp installation media
For more information, see SSL/TLS Protocols.
XenApp 6.5 Security Standards and Deployment Scenarios
7
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
8/53
8
Security Considerations in a XenApp
Deployment
Server FarmsA 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
q
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 CitrixReceiver 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.
q 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 InterfaceIn 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).
http://support.citrix.com/proddocs/index.jsp?lang=en&topic=/xenapp65-admin/hd-flash-wrapper-ad.htmlhttp://support.citrix.com/proddocs/index.jsp?lang=en&topic=/xenapp65-admin/hd-flash-wrapper-ad.htmlhttp://support.citrix.com/proddocs/index.jsp?lang=en&topic=/xenapp65-admin/hd-audio-settings-ad.html -
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
9/53
SSL Relay and Secure GatewayIn a XenApp deployment, administrators can configure encryption using:
q
SSL Relay, a component that is integrated into XenApp
q Secure Gateway, a separate component provided on the XenApp installation media
For more information, see SSL/TLS Protocols.
Security Considerations in a XenApp Deployment
9
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
10/53
10
Country-Specific Government Information
The following topics are of particular relevance to XenApp installations in Australia, theUnited Kingdom, and the United States:
q FIPS 140 and XenApp
q SSL/TLS Protocols
q Smart Cards - includes information on Common Access Cards (of particular relevance to
installations in the United States)
q Kerberos Authentication
For more information about issues specific to your country, contact your local Citrix
representative.
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
11/53
11
FIPS 140 and XenApp
Federal Information Processing Standard 140 (FIPS 140) is a U.S. Federal Governmentstandard 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 Versionsq 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.
q FIPS 140-2, which superseded FIPS 140-1 in 2002, incorporated changes in standards and
technology since 1994.
q 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 ina manner that is compliant with FIPS 140-2.
Market for FIPS 140-Validated ModulesThe 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.
http://csrc.nist.gov/cryptval/140-1/1401val.htmhttp://csrc.nist.gov/cryptval/ -
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
12/53
XenApp and Cryptographic ModulesTo 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
q Citrix Receiver and Citrix online plug-in
q Web Interface
q SSL Relay
q Secure Gateway for Windows
q Single Sign-on
q Offline applications (streaming)
q SmartAuditor
q Power and Capacity Management
q Configuration Logging
q 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 ProgrammingInterface (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 ComplianceFIPS 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.
q 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.
FIPS 140 and XenApp
12
http://technet.microsoft.com/en-us/library/cc750357.aspxhttp://support.microsoft.com/kb/954059 -
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
13/53
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]
q
RSA_WITH_AES_128_CBC_SHA [FIPS 197, RFC 3268]
q 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.
FIPS 140 and XenApp
13
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
14/53
14
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.
q 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 minordifferences between them, the server certificates in your installation can be used for both
SSL and TLS implementations.
SSL/TLS and FIPS ComplianceWhen 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 GatewayIf 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 youuse 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.
q 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.
http://support.citrix.com/proddocs/index.jsp?lang=en&topic=/xenapp65-w2k8/sg-node-wrapper-v65.htmlhttp://support.citrix.com/proddocs/index.jsp?lang=en&topic=/xenapp65-admin/ps-securing-using-ctx-ssl-relay.htmlhttp://csrc.nist.gov/publications/nistpubs/800-52/SP800-52.pdf -
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
15/53
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.
q 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.
q To use SSL with the Secure Gateway or SSL Relay, you must select the Enable SSL andTLS protocols setting when you publish an application.
q If you are using Web Interface with the Secure Gateway, see the information about SSL
in the Secure Gateway and Web Interface administrator documentation.
SSL/TLS Protocols
15
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
16/53
16
Government Ciphersuites
You can configure XenApp, the Web Interface, and Secure Gateway to usegovernment-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).
q 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.pdfand Internet RFC 3268
(http://www.ietf.org/rfc/rfc3268.txt). For more information about AES, see
http://csrc.nist.gov/cryptval/des.htm.
q RSA_WITH_AES_256_CBC_SHA supports RSA key exchange with AES and 256-bit keys forTLS connections, as defined in FIPS 197 and RFC 3268.
http://csrc.nist.gov/cryptval/des.htmhttp://www.ietf.org/rfc/rfc3268.txthttp://csrc.nist.gov/publications/fips/fips197/fips-197.pdfhttp://www.ietf.org/rfc/rfc2246.txt -
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
17/53
17
IP Security
IP Security (IPSec) is a set of standard extensions to the Internet Protocol (IP) that providesauthenticated 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.
http://www.apps.ietf.org/rfc/rfc2401.html -
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
18/53
18
Citrix Single Sign-on
Citrix Single Sign-on increases application security for all XenApp applications, allowingorganizations 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.
http://support.citrix.com/proddocs/index.jsp?lang=en&topic=/passwordmanager-5-0/pm-landing-page-version-50.html -
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
19/53
19
Smart Cards
You can use smart cards with XenApp, supported XenApp plug-ins, the Web Interface, andSingle 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
q Securing channel communications over a network
q 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 CardsYour 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.
q 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.
q 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.
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
20/53
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 SupportCitrix 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 deploymentthat 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.
Smart Cards
20
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
21/53
21
Kerberos Authentication
Kerberos is an authentication protocol. Version 5 of this protocol was first standardized asInternet 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.
http://support.citrix.com/article/CTX121918http://www.ietf.org/rfc/rfc1509.txthttp://www.apps.ietf.org/rfc/rfc1510.html -
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
22/53
22
Citrix Receiver and Plug-ins
With Citrix Receiver or the Citrix online plug-in installed on their client devices, users canwork 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 SummaryThe following table summarizes the security standards relevant to Citrix Receiver and theCitrix online plug-in:
Platform and Version FIPS
140
TLS Triple
DES
AES CRL
check
Smart
card
Kerberos
Citrix Receiver for
Windows 3.0
*1
* * * *3
* *
Citrix Receiver for
Windows CE for
Windows-Based
Terminals 11.02
*2
* * *
Citrix Receiver for
Windows CE for
Handheld and Pocket
PCs 11.02
*2
* * *
Citrix Receiver for
Macintosh 11.3
* * * * *
Citrix Receiver for Linux
12.1
* * *
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
23/53
Citrix Receiver for Sun
Solaris 8.63
* * *
Citrix Receiver for Java
10.1
* * * *3
*4
Citrix Receiver for
Android 2.1
* * * *
Citrix Receiver for
BlackBerry 2.1
* * * *5
Citrix Receiver for
Playbook 1.0
* * *
Citrix Receiver for iOS
4.2.3
Citrix online plug-in 12.1 *1
* * * *3
* *
Citrix online plug-in Web
12.1
*1
* * * *3
* *
Notes:
1These plug-ins inherit FIPS 140 compliance from the base operating system, Windows.
2These plug-ins inherit FIPS 140 compliance from the base operating system, Windows
CE.
3Certificate revocation checking is only applicable to plug-ins running on Windows XP,
Windows Vista, or Windows 7.
4Kerberos 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 SourceThe table below shows the root certificate source for each version of the Citrix Receiver or
Citrix online plug-in.
Plug-in type Root certificate source
Citrix Receiver for Windows 3.0 operating system certificate store
Citrix Receiver for Windows CE for
Windows-Based Terminals 11.02
operating system certificate store
Citrix Receiver for Windows CE for
Handheld and Pocket PCs 11.02
operating system certificate store
Citrix Receiver for Macintosh 11.3 operating system certificate store
Citrix Receiver for Linux 12.1 bundled with the plug-in
Citrix Receiver for Sun Solaris 8.63 bundled with the plug-in
Citrix Receiver and Plug-ins
23
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
24/53
Citrix Receiver for Java 10.1 Java keystore (Java 1.4.x)
Java keystore or operating system
certificate store (Java 1.5.xor later)
Citrix Receiver for Android 2.1 Android keystore
Citrix Receiver for BlackBerry 2.1 operating system certificate store
Citrix Receiver for Playbook 1.0 bundled with the plug-in
Citrix Receiver for iOS 4.2.3
Citrix online plug-in 12.1 operating system certificate store
Citrix online plug-in Web 12.1 operating system certificate store
Citrix Receiver and Plug-ins
24
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
25/53
25
Virtual Channels
The following table shows which Citrix Independent Computing Architecture (ICA) virtualchannels 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
*
1Third-party equipment is required for biometric authentication.
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
26/53
26
Additional Security Features
The following products can be used with XenApp to provide additional security. Theseadditional security measures are not included in the sample deployments.
ICA Encryption Using SecureICAICA 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 RSASecurID
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 SafeWordYou 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.
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
27/53
27
Deployment Samples
To make a XenApp deployment FIPS 140-compliant, you need to consider eachcommunication 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
q Sample B - Using Secure Gateway (Single-Hop)
q Sample C - Using Secure Gateway (Double-Hop)
q Sample D - Using the SSL Relay and the Web Interface
q 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.
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
28/53
28
Sample A Using the SSL Relay
This deployment uses the SSL Relay to provide end-to-end SSL/TLS encryption between theXenApp 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.
Components Operating systems
XenApp farm XenApp 6.5 for Microsoft WindowsServer 2008 R2
SSL Relay enabled
Secure Ticket Authority installed
on XenApp server
Windows Server 2008 R2
User devices Citrix Receiver for Windows 3.0
TLS-enabled Web browser
Windows 7
Windows Vista
Windows XP Professional
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
29/53
29
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 thisauthentication, 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.
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
30/53
30
Security Considerations in Sample
Deployment A
FIPS 140 Validation in Sample Deployment AIn 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 Operating System
XenApp 6.5 Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2
XenApp 6.0 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 AYou 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 isselected on the Connection tab.
Supported Ciphersuites for Sample Deployment AIn 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).
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
31/53
Certificates and Certificate Authorities in SampleDeployment 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 AIn 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 AIn 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.
Security Considerations in Sample Deployment A
31
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
32/53
32
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.
Components Operating systems
XenApp farm XenApp 6.5 for Microsoft WindowsServer 2008 R2
SSL Relay enabled
Secure Ticket Authority installed
on XenApp server
Windows Server 2008 R2
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
33/53
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
Gatewayserver
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
Sample B Using Secure Gateway (Single-Hop)
33
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
34/53
34
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 communicationbetween 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.
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
35/53
How the Components in Sample Deployment B Interact
35
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
36/53
36
Security Considerations for Sample
Deployment B
IPSec in Sample Deployment BTo 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 BIn 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 Operating System
XenApp 6.5 Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2
XenApp 6.0 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 BYou 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, thecomponents are configured for TLS.
Supported Ciphersuites for Sample Deployment BIn 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.
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
37/53
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 BCitrix 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 BIn this deployment, you can configure XenApp to provide smart card authentication. To do
this, you must configure authentication with Microsoft Active Directory and use theMicrosoft Certificate Authority.
Plug-ins Used in Sample Deployment BIn 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.
Security Considerations for Sample Deployment B
37
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
38/53
38
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.
Components Operating systems
XenApp farm XenApp 6.5 for Microsoft Windows
Server 2008 R2
SSL Relay enabled
Secure Ticket Authority installed
on XenApp server
Windows Server 2008 R2
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
39/53
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
GatewayService
Secure
Gateway Proxy
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
Sample C Using Secure Gateway (Double-Hop)
39
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
40/53
40
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.
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
41/53
41
Security Considerations in Sample
Deployment C
IPSec in Sample Deployment CTo 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 CIn 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 Operating System
XenApp 6.5 Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2
XenApp 6.0 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 LayerSecurity 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 CIn 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.
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
42/53
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 CCitrix 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 CSmart card authentication is not supported in sample deployment C. You cannot configuresmart 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 CIn 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.
Security Considerations in Sample Deployment C
42
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
43/53
43
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.
Components Operating systems
XenApp farm XenApp 6.5 for Microsoft WindowsServer 2008 R2
SSL Relay enabled
Secure Ticket Authority installed
on XenApp server
Windows Server 2008 R2
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
44/53
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
Sample D Using the SSL Relay and the Web Interface
44
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
45/53
45
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.
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
46/53
46
Security Considerations for Sample
Deployment D
FIPS 140 Validation in Sample Deployment DIn 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 Operating System
XenApp 6.5 Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2
XenApp 6.0 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 DYou 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 DIn this deployment, the SSL Relay and the Web Interface can be configured to use
government-approved cryptography, such as the ciphersuiteRSA_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).
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
47/53
Certificates and Certificate Authorities in SampleDeployment 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 DIn 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 DIn 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.
Security Considerations for Sample Deployment D
47
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
48/53
48
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
http://support.citrix.com/proddocs/index.jsp?lang=en&topic=/passwordmanager-5-0/pm-landing-page-version-50.html -
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
49/53
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
Windows Server 2008 R2
Java 1.4.xor later
Citrix SingleSign-onService
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 Pack1
Citrix SingleSign-on centralstore
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 InternetInformation Services
Windows Server 2008 R2
Windows Server 2008
Windows Server 2003 with ServicePack 2
.NET Framework 3.5 or 2.0 (IIS
6.0 only)
Visual J#.NET 2.0 Second Edition
Secure
Gatewayserver
Secure Gateway 3.3 for Windows Windows Server 2008 R2
Windows Server 2008
Windows Server 2003 with Service
Pack 2User devices Citrix Receiver for Windows 3.0
TLS-enabled Web browser
Windows 7
Windows Vista
Windows XP Professional
Sample E Using Citrix Single Sign-on and Secure Gateway (Single-Hop)
49
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
50/53
50
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 everyXenApp 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.
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
51/53
How the Components in Sample Deployment E Interact
51
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
52/53
52
Security Considerations for Deployment
Sample E
IPSec in Sample Deployment ETo 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 EIn 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 Operating System
XenApp 6.5 Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2
XenApp 6.0 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 EIn 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 EIn 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).
-
7/29/2019 En.xenapp.ps Sec Node Wrapper Xa65
53/53
Certificates and Certificate Authorities in SampleDeployment 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 EIn 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 EIn 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.
Security Considerations for Deployment Sample E