Product documentation
Citrix Virtual Apps and Desktops
Service Current Release 2402 LTSR 2311 2308 2305 2303 2212 2209 2206 2203 LTSR 1912 LTSR
View PDF

Security considerations and best practices

October 7, 2024
Contributed by: 
C C

Note:

Your organization may need to meet specific security standards to satisfy regulatory requirements. This document does not cover this subject, because such security standards change over time. For up-to-date information on security standards and Citrix products, consult Citrix Trust Center.

Firewalls

Protect all machines in your environment with perimeter firewalls, including at enclave boundaries as appropriate.

All machines in your environment should be protected by a personal firewall. When you install core components and VDAs, you can choose to have the ports required for component and feature communication opened automatically if the Windows Firewall Service is detected (even if the firewall is not enabled). You can also choose to manually configure those firewall ports. If you use a different firewall, you must manually configure it. For more information on required ports, see Tech Paper: Communication Ports Used by Citrix Technologies.

If you are migrating a conventional environment to this release, you may need to reposition an existing perimeter firewall or add new perimeter firewalls. For example, suppose there is a perimeter firewall between a conventional client and database server in the data center. When this release is used, that perimeter firewall must be placed so that the virtual desktop and user device are on one side, and the database servers and Delivery Controllers in the data center are on the other side. Therefore, consider creating an enclave within your data center to contain the database servers and Controllers. Also consider having protection between the user device and the virtual desktop.

Note:

TCP ports 1494 and 2598 are used for ICA and CGP and are therefore likely to be open at firewalls so that users outside the data center can access them. Citrix recommends that you do not use these ports for anything else, to avoid the possibility of inadvertently leaving administrative interfaces open to attack. Ports 1494 and 2598 are officially registered with the Internet Assigned Number Authority (http://www.iana.org/).

Secure communications with Delivery Controller

Encrypting communication using HTTPS

StoreFront and NetScaler gateway communicate with the XML service running on the delivery controller over HTTP or HTTPS. Depending on configuration, VDAs may communicate with the delivery controller using WebSocket. It is recommended that you enable HTTPS and disable HTTP. This requires that you have enabled Enable HTTPS on Delivery Controllers.

Alternatively you can configure Windows to secure communication between the servers using IPSec.

Security Keys

You can use Security Keys to ensure that only authorized StoreFront and NetScaler servers are able to connect to DaaS via the cloud connectors. This is especially important if you have enabled XML trust.

XML trust

By default, when StoreFront connects to the delivery controller for actions such as enumeration and launch, StoreFront must pass through the user’s Active Directory credentials so that DaaS can authenticate the user and check the user’s group membership. However when using other authentication methods such as domain pass-through, smart cards or SAML, StoreFront does not have the active directory password. In this case you must enable “XML Trust”. With XML trust enabled, CVAD allows StoreFront to perform actions on behalf of a user such as enumerating and launching applications without validating the user’s password. Before enabling XML trust, use Security Keys or another mechanism such as firewalls or IPsec to ensure that only trusted StoreFront servers are able to connect to the Delivery Controllers.

Use the Citrix Virtual Apps and Desktops PowerShell SDK to check, enable, or disable the XML trust setting.

  • To check the XML trust setting’s current value, run Get-BrokerSite and inspect the value of TrustRequestsSentToTheXMLServicePort.
  • To enable or disable XML trust, run Set-BrokerSite with parameter TrustRequestsSentToTheXmlServicePort.

Communication between VDA and Delivery Controller

There are two mechanisms for VDAs communicating with controllers.

  • Windows Communication Foundation

    Windows Communication Foundation (WCF) message-level protection secures communication between the Controller and the VDA. Extra transport-level protection using TLS is not required. The WCF configuration uses Kerberos for mutual authentication between the Controller and VDA. Encryption uses AES in CBC mode with a 256-bit key. Message integrity uses SHA-1.

    According to Microsoft, the Security protocols used by WCF conform to standards from OASIS (Organization for the Advancement of Structured Information Standards), including WS-SecurityPolicy 1.2. Additionally, Microsoft states that WCF supports all algorithm suites listed in Security Policy 1.2.

    Communication between the Controller and VDA uses the basic256 algorithm suite, whose algorithms are as stated above.

  • WebSockets

    This is the modern replacement for WCF. It provides the benefit that only the TLS port 443 for communication from the VDA to the Delivery Controller. It is currently only available for MCS provisioned machines. For more information, see WebSocket communication between VDA and Delivery Controller.

Securing ICA communications

Citrix CVAD provides several options for securing ICA traffic between the client and the VDA. The following are the options available:

  • Basic encryption: The default setting.
  • SecureICA: Allows encrypting session data using RC5 (128-bit) encryption.
  • VDA TLS/DTLS: Allows using network-level encryption using TLS/DTLS.

Basic encryption

When using basic encryption, traffic is encrypted as shown in the following graphic.

Traffic encryption when using basic encryption

SecureICA

When using SecureICA, traffic is encrypted as shown in the following graphic.

Traffic encryption when using SecureICA

For more information see Security policy settings

Note 1:

SecureICA is not supported when using Workspace app for HTML5.

Note 2:

Citrix SecureICA forms part of the ICA/HDX protocol but it is not a standards-compliant network security protocol like Transport Layer Security (TLS).

VDA TLS/DTLS

When using VDA TLS/DTLS encryption, traffic is encrypted as shown in the following graphic.

Traffic encryption when using TLS/DTLS

To configure VDA TLS/DTLS, see TLS settings on VDAs.

Virtual channels

Use the virtual channel allow list to control which non-Citrix virtual channels are allowed in your environment.

Secure communications with print server

You can enable TLS for TCP-based connections between the Virtual Delivery Agent (VDA) and the Universal Print Server. For more information, see Transport Layer Security (TLS) on Universal Print Server.

Secure communication with the site database

For information about enabling TLS to the Site database, see CTX137556.

VDA machine security

General recommendations

Ensure that your VDAs are kept up to date with the latest operating security updates and anti-virus.

Application security

To prevent non-admin users from performing malicious actions, Citrix recommends that you configure Windows AppLocker rules for installers, applications, executables and scripts on the VDA host.

8.3 file names

You can disable 8.3 file names on VDAs. See Microsoft fsutil documentation.

Data storage considerations

Your desktop environment may consist of various types of desktops, such as pooled and dedicated desktops. Users should never store data on desktops that are shared amongst users, such as pooled desktops. If users store data on dedicated desktops, that data should be removed if the desktop is later made available to other users.

User account management

Apply Windows best practice for account management. Do not create an account on a template or image before it is duplicated by Machine Creation Services or Provisioning Services. Do not schedule tasks using stored privileged domain accounts. Do not manually create shared Active Directory machine accounts. These practices will help prevent a machine attack from obtaining local persistent account passwords and then using them to log on to MCS/PVS shared images belonging to others.

Grant users only the capabilities they require. Microsoft Windows privileges continue to be applied to desktops in the usual way: configure privileges through User Rights Assignment and group memberships through Group Policy. One advantage of this release is that it is possible to grant a user administrative rights to a desktop without also granting physical control over the computer on which the desktop is stored.

Note the following when planning for desktop privileges:

  • By default, when non-privileged users connect to a desktop, they see the time zone of the system running the desktop instead of the time zone of their own user device. For information on how to allow users to see their local time when using desktops, see the Manage Delivery Groups article.
  • A user who is an administrator on a desktop has full control over that desktop. If a desktop is a pooled desktop rather than a dedicated desktop, the user must be trusted in respect of all other users of that desktop, including future users. All users of the desktop need to be aware of the potential permanent risk to their data security posed by this situation. This consideration does not apply to dedicated desktops, which have only a single user; that user should not be an administrator on any other desktop.
  • A user who is an administrator on a desktop can generally install software on that desktop, including potentially malicious software. The user can also potentially monitor or control traffic on any network connected to the desktop.

Manage logon rights

Logon rights are required for both user accounts and computer accounts. As with Microsoft Windows privileges, logon rights continue to be applied to desktops in the usual way: configure logon rights through User Rights Assignment and group memberships through Group Policy.

The Windows logon rights are: log on locally, log on through Remote Desktop Services, log on over the network (access this computer from the network), log on as a batch job, and log on as a service.

For computer accounts, grant computers only the logon rights they require. The logon right “Access this computer from the network” is required for the computer accounts of Delivery Controllers.

For user accounts, grant users only the logon rights they require.

According to Microsoft, by default the group Remote Desktop Users is granted the logon right “Allow log on through Remote Desktop Services” (except on domain controllers).

Your organization’s security policy may state explicitly that this group should be removed from that logon right. Consider the following approach:

  • The Virtual Delivery Agent (VDA) for Multi-session OS uses Microsoft Remote Desktop Services. You can configure the Remote Desktop Users group as a restricted group, and control membership of the group via Active Directory group policies. Refer to Microsoft documentation for more information.
  • For other components of Citrix Virtual Apps and Desktops, including the VDA for Single-session OS, the group Remote Desktop Users is not required. So, for those components, the group Remote Desktop Users does not require the logon right “Allow log on through Remote Desktop Services”; you can remove it. Additionally:
    • If you administer those computers via Remote Desktop Services, ensure that all such administrators are already members of the Administrators group.
    • If you do not administer those computers via Remote Desktop Services, consider disabling Remote Desktop Services itself on those computers.

Although it is possible to add users and groups to the login right “Deny logon through Remote Desktop Services”, the use of deny logon rights is not generally recommended. Refer to Microsoft documentation for more information.

Delivery Controller security

Windows services on Delivery Controller

Delivery Controller installation creates the following Windows services:

  • Citrix AD Identity Service (NT SERVICE\CitrixADIdentityService): Manages Microsoft Active Directory computer accounts for VMs.
  • Citrix Analytics (NT SERVICE\CitrixAnalytics): Collects site configuration usage information for use by Citrix, if this collection been approved by the site administrator. It then submits this information to Citrix, to help improve the product.
  • Citrix App Library (NT SERVICE\CitrixAppLibrary): Supports management and provisioning of AppDisks, AppDNA integration, and management of App-V.
  • Citrix Broker Service (NT SERVICE\CitrixBrokerService): Selects the virtual desktops or applications that are available to users.
  • Citrix Configuration Logging Service (NT SERVICE\CitrixConfigurationLogging): Records all configuration changes and other state changes made by administrators to the site.
  • Citrix Configuration Service (NT SERVICE\CitrixConfigurationService): Site-wide repository for shared configuration.
  • Citrix Delegated Administration Service (NT SERVICE\CitrixDelegatedAdmin): Manages the permissions granted to administrators.
  • Citrix Environment Test Service (NT SERVICE\CitrixEnvTest): Manages self-tests of the other Delivery Controller services.
  • Citrix Host Service (NT SERVICE\CitrixHostService): Stores information about the hypervisor infrastructures used in a Citrix Virtual Apps or Citrix Virtual Desktops deployment, and also offers functionality used by the console to enumerate resources in a hypervisor pool.
  • Citrix Machine Creation Services (NT SERVICE\CitrixMachineCreationService): Orchestrates the creation of desktop VMs.
  • Citrix Monitor Service (NT SERVICE\CitrixMonitor): Collects metrics for Citrix Virtual Apps or Citrix Virtual Desktops, stores historical information, and provides a query interface for troubleshooting and reporting tools.
  • Citrix Storefront Service (NT SERVICE\ CitrixStorefront): Supports management of StoreFront. (It is not part of the StoreFront component itself.)
  • Citrix Storefront Privileged Administration Service (NT SERVICE\CitrixPrivilegedService): Supports privileged management operations of StoreFront. (It is not part of the StoreFront component itself.)
  • Citrix Config Synchronizer Service (NT SERVICE\CitrixConfigSyncService): Propagates configuration data from the main site database to the Local Host Cache.
  • Citrix High Availability Service (NT SERVICE\CitrixHighAvailabilityService): Selects the virtual desktops or applications that are available to users, when the main site database is unavailable.

Delivery Controller installation also creates the following Windows services. These are also created when installed with other Citrix components:

  • Citrix Diagnostic Facility COM Server (NT SERVICE\CdfSvc): Supports the collection of diagnostic information for use by Citrix Support.
  • Citrix Telemetry Service (NT SERVICE\CitrixTelemetryService): Collects diagnostic information for analysis by Citrix, such that the analysis results and recommendations can be viewed by administrators to help diagnose issues with the site.

Delivery Controller installation also creates the following Windows service. This is not currently used. If it has been enabled, disable it.

  • Citrix Remote Broker Provider (NT SERVICE\XaXdCloudProxy)

Delivery Controller installation also creates these following Windows services. These are not currently used, but must be enabled. Do not disable them.

  • Citrix Orchestration Service (NT SERVICE\CitrixOrchestration)
  • Citrix Trust Service (NT SERVICE\CitrixTrust)

Except for the Citrix Storefront Privileged Administration Service, these services are granted the logon right Log on as a service and the privileges Adjust memory quotas for a process, Generate security audits, and Replace a process level token. You do not need to change these user rights. These privileges are not used by the Delivery Controller and are automatically disabled.

Except for the Citrix Storefront Privileged Administration service and the Citrix Telemetry Service, the Delivery Controller Windows services listed above are configured to log on as the NETWORK SERVICE identity. Do not alter these service settings.

The Citrix Config Synchronizer Service needs the NETWORK SERVICE account to belong to the Local Administrator group on the Delivery Controller. This allows Local Host Cache to work correctly.

The Citrix Storefront Privileged Administration service is configured to log on Local System (NT AUTHORITY\SYSTEM). This is required for Delivery Controller StoreFront operations that are not normally available to services (including creating Microsoft IIS sites). Do not alter its service settings.

The Citrix Telemetry Service is configured to log on as its own service-specific identity.

You can disable the Citrix Telemetry Service. Apart from this service, and services that are already disabled, do not disable any other of these Delivery Controller Windows services.

Manage logon rights

The computer accounts of VDAs must have login right “Access this computer from the network”. See Active Directory OU-based Controller discovery.

Client access

Client access is normally provided by deploying Citrix StoreFront. For more information on securing StoreFront, see StoreFront documentation.

To allow remote users to security connect to StoreFront and the VDAs, deploy a NetScaler gateway.

Citrix recommends that clients connect to StoreFront using Citrix Workspace app. For more more information, see the security sections of the documentation for Citrix Workspace app for each operating system. Alternatively users may use a web browser to access StoreFront.

Consider providing users with thin clients where users have limited ability to run applications other than Citrix Workspace app. Where devices are managed by your organization you should put in policies to ensure deployment of operating system security updates and anti-virus software. However in many cases users need to be able to connect from un-managed device outside of the control of your organization. Consider using the following features:

  • Endpoint Analysis to scan endpoints for security information such as operating system and anti-virus and denies access to clients that do not meet your security requirements.
  • App Protection blocks key loggers and screen capture.

Mixed-version environments

Mixed-version environments, for instance where the VDAs have a different version to the Delivery Controller, are inevitable during some upgrades. Follow best-practice and minimize the time that Citrix components of different versions co-exist. In mixed-version environments, security policy, for example, may not be uniformly enforced.

Note:

This is typical of other software products; the use of an earlier version of Active Directory only partially enforces Group Policy with later versions of Windows.

The following scenario describes a security issue that can occur in a specific mixed-version Citrix environment. When Citrix Receiver 1.7 is used to connect to a virtual desktop running the VDA in XenApp and XenDesktop 7.6 Feature Pack 2, the policy setting Allow file transfer between desktop and client is enabled in the Site but cannot be disabled by a Delivery Controller running XenApp and XenDesktop 7.1. It does not recognize the policy setting, which was released in the later version of the product. This policy setting allows users to upload and download files to their virtual desktop, which is the security issue. To work around this, upgrade the Delivery Controller (or a standalone instance of Studio) to version 7.6 Feature Pack 2 and then use Group Policy to disable the policy setting. Alternatively, use local policy on all affected virtual desktops.

Remote PC Access security considerations

Remote PC Access implements the following security features:

  • Smart card use is supported.
  • When a remote session connects, the office PC’s monitor appears as blank.
  • Remote PC Access redirects all keyboard and mouse input to the remote session, except CTRL+ALT+DEL and USB-enabled smart cards and biometric devices.
  • SmoothRoaming is supported for a single user only.
  • When a user has a remote session connected to an office PC, only that user can resume local access of the office PC. To resume local access, the user presses Ctrl-Alt-Del on the local PC and then logs on with the same credentials used by the remote session. The user can also resume local access by inserting a smart card or leveraging biometrics, if your system has appropriate third-party Credential Provider integration. This default behavior can be overridden by enabling Fast User Switching via Group Policy Objects (GPOs) or by editing the registry.

Note:

Citrix recommends that you do not assign VDA administrator privileges to general session users.

Automatic assignments

By default, Remote PC Access supports automatic assignment of multiple users to a VDA. In XenDesktop 5.6 Feature Pack 1, administrators could override this behavior using the RemotePCAccess.ps1 PowerShell script. This release uses a registry entry to allow or prohibit multiple automatic remote PC assignments; this setting applies to the entire Site.

Caution:

Editing the registry incorrectly can cause serious problems that may require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it.

To restrict automatic assignments to a single user:

On each Controller in the Site, set the following registry entry:

HKEY\_LOCAL\_MACHINE\Software\Citrix|DesktopServer
Name: AllowMultipleRemotePCAssignments
Type: REG_DWORD
Data: 0 = Disable multiple user assignment, 1 = (Default) Enable multiple user assignment.

If there are any existing user assignments, remove them using SDK commands for the VDA to subsequently be eligible for a single automatic assignment.

  • Remove all assigned users from the VDA: $machine.AssociatedUserNames | %{ Remove-BrokerUser-Name $_ -Machine $machine
  • Remove the VDA from the Delivery Group: $machine | Remove-BrokerMachine -DesktopGroup $desktopGroup

Restart the physical office PC.

Security considerations and best practices
October 7, 2024
Contributed by: 
C C
October 7, 2024
Contributed by: 
C C

In this article

Site feedback | Your privacy choices footer linkYour Privacy Choices | Privacy and legal terms | Cookie preferences | Consent settings | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.