SECURITY ON THE ICA CLIENT

Citrix ICA clients all support integration with enterprise security standards. Some of the more typical standards supported are

• – Connecting through a SOCKS proxy server or Secure proxy server (also known as security proxy server, HTTPS proxy server, or SSL tunneling proxy server)

• – Integrating the ICA Win32 clients with the Access Gateway or Secure Gateway with Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols

• – Connecting to a server through a firewall

Connecting to a Server Through a Proxy Server

Proxy servers are used to limit access into, and out of, a network, and to handle connections between ICA clients and Presentation Server servers. The ICA Win32 Clients support SOCKS and secure proxy protocols and can automate the detection and configuration of the ICA protocol to work with the client connection. In communicating with the Presentation Server server, the Win32 Program Neighborhood Agent and the ICA Win32 Web client use proxy server settings that are configured remotely on the Presentation Server Web Interface server. Web Interface 2.0 is configured by default to autodetect the client Web browser settings and pass these to the client's ICA session. In communicating with the Web server, the ICA Win32 Program Neighborhood Agent and the ICA Win32 Web client use the proxy server settings configured through the Internet settings of the default Web browser on the client device. Obviously, the local settings of the default Web browser on the client device need to be set for the appropriate proxy settings. See Chapter 16 for information about configuring proxy server settings for these ICA clients.

Using the ICA Win32/64 Clients with Citrix Secure Gateway and Citrix Access Gateway

For external users (and some highly secure internal users), the ICA Win32/64 clients can be configured to use the Secure Gateway or Access Gateway. The clients support both SSL and TLS protocols, which are discussed at length in Chapters 8 and 16.

• – SSL provides strong encryption to increase the privacy of ICA connections and certificate-based server authentication to ensure the server you are connecting to is a genuine server.

• – TLS (Transport Layer Security) is the latest, standardized version of the SSL protocol. The Internet Engineering Taskforce (IETF) renamed it TLS when it took over responsibility for the development of SSL as an open standard. TLS secures data communications by providing server authentication, encryption of the data stream, and message integrity checks. Because there are only minor technical differences between SSL Version 3.0 and TLS Version 1.0, the certificates you use for SSL in your Presentation Server installation will also work with TLS. Some organizations, including those in the U.S. government, require the use of TLS to secure data communications. These organizations may also require the use of validated cryptography, such as FIPS 140. FIPS 140 (Federal Information Processing Standard) is a standard for cryptography. Security is covered in more depth in Chapter 8.

System Requirements for SSL/TLS In addition to the system requirements listed for each ICA client, the following must be met for SSL/TLS support:

• – The client device must support 128-bit encryption.

• – The client device must have a root certificate installed that can verify the signature of the Certificate Authority on the server certificate.

• – The ICA client must be configured to be aware of the TCP listening port number used by the SSL Relay service on the Presentation Server server.

Verifying Cipher Strength/128-Bit Encryption Internet Explorer users can determine encryption level of their system by doing the following:

1. Start Internet Explorer.

2. From the Help menu, click About Internet Explorer.

3. Check the Cipher Strength value. If it is less than 128 bits, you need to obtain and install a high-encryption upgrade from the Microsoft Web site. Go to http://www.microsoft.com/ and search for "128-bit" or "strong encryption."

4. Download and install the upgrade. If you do not have Internet Explorer installed, or if you are not certain about the encryption level of your system, visit Microsoft's Web site at http://www.microsoft.com/ to install a service pack that provides 128-bit encryption.

Note 

The ICA Win32 Clients support certificate key lengths of up to 4,096 bits. Ensure that the bit lengths of your Certificate Authority root and intermediate certificates and those of your server certificates do not exceed the bit length your ICA clients support. Otherwise, your connection may fail.

Configuring the ICA Client for Use with Citrix Secure Gateway Citrix Secure Gateway can be configured for either Normal mode or Relay mode. With Secure Gateway in Normal mode, the only ICA client configuration required is to enter the fully qualified domain name (FQDN) of the Secure Gateway server. If Secure Gateway is used in Relay mode, the Secure Gateway server functions as a proxy and the ICA client needs to be configured to use

• – The fully qualified domain name (FQDN) of the Secure Gateway server

• – The port number of the Secure Gateway server

Configuring the ICA Win32/64 Program Neighborhood Client for Citrix Secure Gateway To configure the details of your Secure Gateway server,

1. Start the Program Neighborhood Client.

2. If you are configuring an application set: right-click the application set to be configured and select Application Set Settings. The Application Set dialog box appears. If you are configuring an existing custom ICA connection: right-click the custom ICA connection you want to configure and select Properties. The Connection Properties dialog box appears. If you are configuring all future custom ICA connections: right-click in a blank area of the Custom ICA Connections window and select Custom Connection Settings. The Custom ICA Connections dialog box appears.

3. If you are configuring an application set or an existing custom ICA connection: from the Network Protocol menu, select SSL/TLS + HTTPS. If you are configuring all future custom ICA connections: from the Network Protocol menu, select HTTP/HTTPS.

4. On the Connection tab, click Firewalls.

5. Enter the fully qualified domain name (FQDN) of the Secure Gateway server in the Secure Gateway address box.

   Note 

   The fully qualified domain name (FQDN) must list, in sequence, the following three components :

   • Host name

   • – Intermediate domain

   • – Top-level domain

   For example: my_computer.my_company.com is an FQDN, because it lists, in sequence, a host name (my_computer), an intermediate domain (my_company), and a top-level domain (com). The combination of intermediate and top-level domains (my_company.com) is generally referred to as the domain name.

6. Enter the port number in the Port box.

7. Click OK twice.

Configuring and Enabling ICA Clients for SSL and TLS

SSL and TLS are configured in the same way, use the same certificates, and are enabled simultaneously .

When SSL and TLS are enabled, each time a connection is initiated the client attempts to use TLS first and then tries SSL. If it cannot connect with SSL, the connection fails and an error message appears.

Forcing TLS Connections for All ICA Win32/64 Clients To force the ICA Win32 clients (including the ICA Win32/64 Web client) to connect with TLS, the Secure Gateway server or SSL Relay service needs TLS specified in the configuration (see Chapter 16 for more details). To manually configure the ICA Win32/64 Program Neighborhood client to use SSL/TLS,

1. Open the Program Neighborhood Client.

2. If you are configuring an application set to use SSL/TLS: Right-click the application set you want to configure and select Application Set Settings. The Application Set dialog box appears. If you are configuring an existing custom ICA connection to use SSL/TLS: right-click the custom ICA connection you want to configure and select Properties. The Connection Properties dialog box appears. If you are configuring all future custom ICA connection to use SSL/TLS: right-click in a blank area of the Custom ICA Connections window and select Custom Connection Settings. The Custom ICA Connections dialog box appears.

3. If you are configuring an application set or an existing custom ICA connection: From the Network Protocol menu, select SSL/TLS + HTTPS. If you are configuring all future custom ICA connections: from the Network Protocol menu, select HTTP/HTTPS.

4. Add the fully qualified domain name of the SSL/TLS-enabled Presentation Server server(s) to the Address List.

5. Click OK.

To configure the ICA Win32 Program Neighborhood Agent to use SSL/TLS, do the following:

1. To use SSL/TLS to encrypt application enumeration and launch data passed between the Program Neighborhood Agent and the Presentation Server Web Interface server, configure the appropriate settings in the configuration file on the Web server (see Chapter 16 for more details). The configuration file must also include the machine name of the Citrix server hosting the SSL certificate.

2. To use secure HTTP (HTTPS) to encrypt the configuration information passed between the Program Neighborhood Agent and the Web Interface server, enter the URL of the server hosting the configuration file in the format https://www.< servername > on the Server tab of the Program Neighborhood Agent Properties dialog box.

To configure the Appsrv.ini file to use TLS,

1. Exit the Program Neighborhood Agent if it is running. Make sure all Program Neighborhood components, including the Connection Center, are closed.

2. Open the individual's user-level Appsrv.ini file (default directory: % User Profile%\Application Data\ICAClient) in a text editor.

3. Locate the section named [WFClient]. Set the values of these two parameters as follows :

   • – SSLCIPHERS={GOV All}

   • – SECURECHANNELPROTOCOL={TLS Detect}. Set the value to TLS, or Detect to enable TLS. If Detect is selected, the Program Neighborhood Agent tries to connect using TLS encryption. If a connection using TLS fails, the client tries to connect using SSL.

4. Save your changes.

Certificate Revocation List Checking

New with Feature Release 3, Citrix released certificate revocation list checking. When certificate revocation list checking is enabled, the ICA Win32 clients check whether or not the server's certificate has been revoked . This feature improves the cryptographic authentication of the Presentation Server server and improves the overall security of the SSL/TLS connections between an ICA Win32 Client and a Presentation Server server.

Several levels of certificate revocation list checking can be enabled. For example, the client can be configured to check only its local certificate list, or to check the local and network certificate lists. In addition, the certificate can be configured for certificate checking to allow users to log on only if all Certificate Revocation Lists are verified .

To enable certificate revocation list checking,

In the Template.ica file, configure the SSLCertificateRevocationCheckPolicy setting to one of the following options:

• – NoCheck No certificate revocation list checking is performed.

• – CheckWithNoNetworkAccess The local list is checked.

• – FullAccessCheck The local list and any network lists are checked.

• – FullAccessCheckAndCRLRequired The local list and any network lists are checked; users can log on if all lists are verified.

Meeting FIPS 140 Security Requirements

To meet FIPS 140 security requirements, the following parameters listed in the following subsections must be included in the Template.ica file on the Web Interface server, or in the user-level Appsrv.ini file of the local client device.

Configuring the Appsrv.ini file to Meet FIPS 140 Security Requirements To configure the Appsrv. ini file to meet FIPS 140 security requirements,

1. Exit the Program Neighborhood Agent if it is running. Make sure all Program Neighborhood components, including the Connection Center, are closed.

2. Open the individual's user-level Appsrv.ini file (default directory: %User Profile%\Application Data\ICAClient) in a text editor.

3. Locate the section named [WFClient].

4. Set the values of these three parameters as follows:

   • – SSLENABLE=On

   • – SSLCIPHER=GOV

   • – SECURECHANNELPROTOCOL=TLS

5. Save your changes.

Installing Root Certificates on the ICA Win32/64 Clients To use SSL/TLS to secure communications between SSL/TLS-enabled ICA clients and the Presentation Server server, a root certificate is needed on the client device that can verify the signature of the Certificate Authority on the server certificate.

The Citrix ICA Win32 clients support the Certificate Authorities supported by the Windows operating system. The root certificates for these Certificate Authorities are installed with Windows and managed using Windows utilities. They are the same root certificates used by Microsoft Internet Explorer. One exception to this is the Java client. Since this is a server-deployed client, the administrator of the Web Interface server must update the Java configuration files to include the Certificate Authority information and path .

If you use your own Certificate Authority, you must obtain a root certificate path from that Certificate Authority and install it on each client device. This root certificate path is then used and trusted by both Microsoft Internet Explorer and the Citrix ICA Win32 client.

Depending on an organization's policies and procedures, an administrator may prefer to install the root certificate on each client device instead of directing users to install it. In most cases, if an organization is using Windows 2000 Server or Windows Server 2003 with Active Directory, the root certificate can be deployed and installed using Windows 2000 Group Profiles.

Note 

The following steps assume that your organization has a procedure in place that allows users to check the root certificate as they install it. It is important to verify the authenticity of a root certificate before installing it.

To install a root certificate on the Win32 client device,

1. Double-click the root certificate file. The root certificate file has the extension .cer, .crt, or .der.

2. Verify that you are installing the correct root certificate.

3. Click Install Certificate.

4. The Certificate Import Wizard starts. Click Next .

5. Choose the Place All Certificates in the Following Store option and then click Browse.

6. On the Select Certificate Store screen, select Show physical stores.

7. Expand the Trusted Root Certification Authorities store and then select Local Computer. Click OK.

8. Click Next and then click Finish. The root certificate is installed in the store you selected.

For more details about certificates, and the server-side configuration, please see Chapter 16.

Enabling Smart Card Logon

This section assumes that smart card support is enabled on the Presentation Server server, and that the client device is properly set up and configured with third-party smart card hardware and software. Refer to the documentation that came with your smart card equipment for instructions about deploying smart cards within your network.

The smart card removal policy set on the Presentation Server server determines what happens if the smart card is removed from the reader during an ICA session. The smart card removal policy is configured through, and handled by, the Windows operating system.

To enable smart card logon with Passthrough authentication requires a smart card to be present or inserted in the smart card reader at logon time. With this logon mode selected, the Program Neighborhood Agent prompts the user for a smart card personal identification number (PIN) when it starts up. Passthrough authentication then caches the PIN and passes it to the server every time the user requests a published resource. The user does not have to subsequently reenter a PIN to access published resources. If authentication based on the cached PIN fails or if a published resource itself requires user authentication, the user continues to be prompted for a PIN.

Perform the following to enable smart card logon with Passthrough authentication:

1. From the Program Neighborhood Agent Admin tool, select Logon Method from the Configuration Settings menu.

2. Click Smart Card Passthrough Authentication to select the option.

3. Save your changes.

To enable smart card logon without Passthrough authentication requires a smart card to be present or inserted in the smart card reader when the user tries to log on. With this logon mode selected, the Program Neighborhood Agent prompts the user for a smart card PIN (personal identification number) when it starts up and every time the user requests a published resource.

To enable smart card logon without passthrough authentication, do the following:

1. From the Program Neighborhood Agent Admin tool, select Logon Method from the Configuration settings menu.

2. Click Smart Card Logon to select the option.

3. Verify that Passthrough Authentication is not selected.

4. Save your changes.

Enabling NDS Logon Support

To enable NDS Logon Support, perform the following:

1. From the Program Neighborhood Agent Admin Tool, select Logon Method from the Configuration settings menu.

2. Click Use NDS Credentials for Prompt User and Passthrough authentication to select the option.

3. Enter the default tree name.

4. Save your changes.

Locking Down the ICA Client

As discussed in Chapters 7, 11, 13, and 15, the lockdown of the desktop device, regardless of the device, is an important aspect to maintaining a minimal maintenance client environment. If a configuration can be changed on the client machine, there is a risk that it can be broken, and of course, if the device fails, any configurations will have to be re-input. Thus, if the device can be fully locked such that user configurations and software (including client access software) cannot be changed, the environment will require significantly less support.

We introduced three applications for this purpose: RES PowerFuse, AppSense, and triCerat, each of which does a good job of efficiently and effectively locking down the desktop.

ICA and RDP Client Drive, Printer, and COM Port Mapping

Both ICA and RDP clients now support local drive, printer, and COM port mapping. Local Mapping allows the client to force the server to map a local device so that a user is able to employ a local device from within the remote server session.

Although local mapping can be very useful for remote, home, and traveling users, it is important to selectively apply local mappings in remote office and LAN environments, since the data stream created from sending data back and forth from the server to the client can be very intensive and cause other ICA/RDP sessions to fail.

All three items can be enabled or disabled from the server in the Citrix Management Console (for ICA) or the Terminal Services Configuration utility (for RDP). The server can also be configured to default to the client settings. The client local mapping settings can be configured for the RDP Client from the Local Resources tab.

Thin-Client Configuration

As discussed in Chapter 7, most thin-client vendors have management software to remotely flash updates and configurations to their thin clients. Although we prefer the simplest thin clients that just run ICA and RDP client software, we still recommend purchasing the enterprise versions of these management suites, to aid in the mass setup and configuration of thin clients. Generally, this management software requires a server running TFTP to put the management software and updated images on. Wyse, for example, provides an application called Rapport Enterprise for this purpose.

Publishing the Full Desktop vs. Seamless Windows

Prior to the advent of lockdown software it was often necessary to limit a user to a specific application or small group of applications in order to ensure that users didn't maliciously or accidentally change server settings in ways that could cause instability (such as installing printers). By choosing to publish an application in a "desktop window," that application appears to take up the entire screen when a user logs in. The Seamless Windows feature of the Win32 ICA client was created in order to make access to individual published applications transparent to the user. These application icons appear just as any other icons on the user's PC desktop. The user doesn't necessarily know that the application is actually running on a server. With Presentation Server, all applications using Seamless Windows on a user's desktop share a connection, so it is not necessary to log on again each time one of these applications is executed.

The significant downside that we have seen in using Seamless Windows with a large number of applications is that users don't understand when and where applications are coming from, and thus they struggle with understanding where their printers, files, and utilities are. In addition, if something doesn't work, they immediately blame the server farm, propagating the user community perception that the on-demand access solution doesn't work. Because of this user perception problem, if we are publishing more than one or two applications, we utilize a locked-down , full-desktop environment. Although it isn't as slick, when users can recognize which environment they are in, it is easier to set and meet their expectations of application access and performance.

Autoupdate

Presentation Server includes the ICA Client Update Configuration utility, which allows an administrator to manage the ICA client versions in use on the network. The database of the various ICA client versions is created when Presentation Server is installed and is located in the \ %SystemRoot% \ICA\ClientDB directory. When a new client version for a particular type of client is placed in this directory, users with that client will see a notice the next time they log on. This notice informs them that a new client is available. Depending on the settings in the Client Update Configuration utility, the user can choose to skip the update, or update at that time.