Product Documentation

Securing Server Farms

Oct 09, 2015

Consult with your organization’s security experts for a comprehensive security strategy that best fits your needs.

The Citrix XenApp plug-ins are compatible with and function in environments where the Microsoft Specialized Security - Limited Functionality (SSLF) desktop security template is used. These templates are supported in the Microsoft Windows XP and Vista platforms. Refer to the Windows XP and Windows Vista security guides available at http://technet.microsoft.com for more information about the template and related settings.

Securing Access to Your Servers

Updated: 2015-04-29

An important first step in securing your server farm is securing access to the servers.

Securing the Delivery Services Console

You can use the Delivery Services Console to connect to any server in your farm. Use it only in environments where packet sniffing cannot occur. Also, ensure that only administrators can access it. You can set NTFS permissions so that non-administrators do not have Execute permission for the console executable.

Using NTFS partitions

To ensure that appropriate access control can be enforced on all files installed by XenApp, install XenApp only on NTFS-formatted disk partitions.

Trusted Server Configuration

This feature identifies and enforces trust relations involved in client connections. This can be used to increase the confidence of client administrators and users in the integrity of data on client devices and to prevent the malicious use of client connections. When this feature is enabled, clients can specify the requirements for trust and determine whether or not they trust a connection to the server.

Securing the Data Store

Protecting the data store involves not only protecting the data in the data store database but also restricting who can access it. In general:
  • Users who access your farm’s servers do not require and should not be granted any access to the data store.
  • All farm servers share a single user account and password for accessing the data store. Select a password that is not easy to deduce. Keep the user name and password secure and give it to administrators only to install XenApp.
Caution: If the user account for accessing the database is changed at a later time, the Citrix IMA Service fails to start on all servers configured with that account. To reconfigure the Citrix IMA Service password, use the dsmaint config command on each affected server. Be sure to create a backup of your data store before changing the password on your data store.

Consult the database vendor documentation for more information.

Microsoft SQL Server

The user account that is used to access the data store on Microsoft SQL Server has public and db_owner roles on the server and database. System administrator account credentials are not needed for data store access; do not use a system administrator account because this poses an additional security risk.

If the Microsoft SQL Server is configured for mixed mode security, meaning that you can use either Microsoft SQL Server authentication or Windows authentication, you may want to create a Microsoft SQL Server user account for the sole purpose of accessing the data store. Because this Microsoft SQL Server user account would access only the data store, there is no risk of compromising a Windows domain if the user’s password is compromised. For high-security environments, Citrix recommends using only Windows authentication.
Important: For improved security, you can change the user account’s permission to db_reader and db_writer after the initial installation of the database with db_owner permission. Changing the user account’s permission from db_owner may cause problems installing future service packs or feature releases for XenApp. Be sure to change the account permission back to db_owner before installing a XenApp service pack or feature release.

Microsoft SQL Server Express

Windows authentication is supported for the Microsoft SQL Server Express database. For security reasons, Microsoft SQL Server authentication is not supported. The user name and password typically are those for the local system administrator account. If users have access to the data store server, change the password with the dsmaint config command and keep the information in a safe place.

Oracle

Give the Oracle user account employed for the server farm "connect" and "resource" permissions only. System administrator (system or sys) account permissions are not needed for data store access.

Using the Secure Gateway

Use the Secure Gateway to provide SSL/TLS encryption between a secure Internet gateway server and an SSL-enabled client, combined with encryption of the HTTP communication between the Web browser and the Web server. Using the Secure Gateway makes firewall traversal easier and improves security by providing a single point of entry and secure access to your server farms.

In general, use the Secure Gateway when:
  • You want to hide internal IP addresses
  • You want to secure public access to your farm’s servers
  • You need two-factor authentication (in conjunction with the Web Interface)
Using the Secure Gateway provides the following benefits:
  • Secure Internet access
  • Removes the need to publish the addresses of every server running XenApp
  • Simplifies server certificate management
  • Allows a single point of encryption and access to the servers

Use the Secure Gateway to create a gateway that is separate from the computers running XenApp. Establishing the gateway simplifies firewall traversal because ICA traffic is routed through a widely accepted port for passage in and out of firewalls. The Secure Gateway provides increased scalability.

However, because ICA communication is encrypted only between the client and the gateway, you may want to use SSL Relay to secure the traffic between the gateway and the servers running XenApp, including the servers hosting the Citrix XML Service.

For more information, see the Secure Gateway for Windows administrator documentation.

Using the Secure Ticket Authority

The Secure Ticket Authority (STA) is responsible for issuing session tickets in response to connection requests for published resources on XenApp. These session tickets form the basis of authentication and authorization for access to published resources.

When you install XenApp, you also install the STA. The STA is embedded within the Citrix XML Service.
Important: If you are securing communications between the Secure Gateway and the STA, ensure that you install a server certificate on the server running the STA and implement SSL Relay. In most cases, internally generated certificates are used for this purpose.

To display STA performance statistics

  1. Access the Performance Monitor.
  2. Right-click in the right pane and click Add Counters.
  3. For the location of the performance counters, select Use local computer counters.
  4. From the Performance Object drop-down list, select Secure Ticket Authority.
  5. Select the performance counters you want to monitor and click Add.
  6. Click Close.
  7. Use the Windows Performance Console controls that appear at the top of the right pane to switch views and add counters.

Identifying Entries in the STA Log

The STA logs fatal errors to its application log, which is located in the \inetpub\scripts directory. When creating a log, the STA uses the following format for naming log files:

  stayyyymmdd-xxx.log  

where yyyy is the year, mm is the month, and dd is the day of the log file creation.

The first time the STA is loaded, it creates a log file.

To view entries in the STA log, use a plain-text editor to open the log file.

If the STA does not create a log file, it may be due to lack of write privileges to the \inetpub\scripts directory.