Secure your StoreFront deployment
This article highlights areas that may have an impact on system security when deploying and configuring StoreFront.
Configure Microsoft Internet Information Services (IIS)
You can configure StoreFront with a restricted IIS configuration. Note that this is not the default IIS configuration.
Filename extensions You can disallow unlisted file name extensions.
StoreFront requires these file name extensions in Request Filtering:
- . (blank extension)
If download or upgrade of Citrix Receiver is enabled for Citrix Receiver for Web, StoreFront also requires these file name extensions:
If Citrix Receiver for HTML5 is enabled, StoreFront also requires these file name extensions:
You can remove MIME Types corresponding to the following file types:
StoreFront requires the following HTTP verbs in Request Filtering. You can disallow unlisted verbs.
Other Microsoft IIS settings
StoreFront does not require:
- CGI programs
- FastCGI programs
- Do not configure IIS Authorization Rules. StoreFront supports authentication directly, and does not use or support IIS authentication.
- Do not select Client certificates: Require, in the SSL Settings for the StoreFront site. StoreFront installation configures the appropriate pages of the StoreFront site with this setting.
- StoreFront requires Full Trust. Do not set the global .NET trust level to High or lower.
- StoreFront does not support a separate application pool for each site. Do not modify these site settings.
Configure user rights
When you install StoreFront, its application pools 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. This is normal installation behavior when application pools are created.
You do not need to change these user rights. These privileges are not used by StoreFront and are automatically disabled.
StoreFront installation creates the following Windows services:
- Citrix Configuration Replication (NT SERVICE\CitrixConfigurationReplication)
- Citrix Cluster Join (NT SERVICE\CitrixClusterService)
- Citrix Peer Resolution (NT SERVICE\Citrix Peer Resolution Service)
- Citrix Credential Wallet (NT SERVICE\CitrixCredentialWallet)
- Citrix Subscriptions Store (NT SERVICE\CitrixSubscriptionsStore)
- Citrix Default Domain Services (NT SERVICE\CitrixDefaultDomainService)
If you configure StoreFront Kerberos constrained delegation for XenApp 6.5, this creates the Citrix StoreFront Protocol Transition service (NT SERVICE\SYSTEM). This service requires a privilege not normally granted to Windows services.
Configure service settings
The StoreFront Windows services listed above in the “Configure user rights” section are configured to log on as the NETWORK SERVICE identity. The Citrix StoreFront Protocol Transition service logs on as SYSTEM. Do not change this configuration.
Configure group memberships
StoreFront installation adds the following services to the Administrators security group:
- Citrix Configuration Replication (NT SERVICE\CitrixConfigurationReplication)
- Citrix Cluster Join (NT SERVICE\CitrixClusterService)
These group memberships are required for StoreFront to operate correctly, to:
- Create, export, import and delete certificates, and set access permissions on them
- Read and write the Windows registry
- Add and remove Microsoft .NET Framework assemblies in the Global Assembly Cache (GAC)
- Access the folder Program Files\Citrix\<StoreFrontLocation>
- Add, modify, and remove IIS app pool identities and IIS web applications
- Add, modify, and remove local security groups and firewall rules
- Add and remove Windows services and PowerShell snap-ins
- Register Microsoft Windows Communication Framework (WCF) endpoints
In updates to StoreFront, this list of operations might change without notice.
StoreFront installation also creates the following local security groups:
- CitrixStoreFrontAdministrators (from StoreFront 3.12.6000 onwards)
StoreFront maintains the membership of these security groups. They are used for access control within StoreFront, and are not applied to Windows resources such as files and folders. Do not modify these group memberships.
Certificates in StoreFront
Server certificates are used for machine identification and Transport Layer Security (TLS) transport security in StoreFront. If you decide to enable ICA file signing, StoreFront can also use certificates to digitally sign ICA files.
To enable email-based account discovery for users installing Citrix Receiver on a device for the first time, you must install a valid server certificate on the StoreFront server. The full chain to the root certificate must also be valid. For the best user experience, install a certificate with a Subject or Subject Alternative Name entry of discoverReceiver.domain, where domain is the Microsoft Active Directory domain containing your users’ email accounts. Although you can use a wildcard certificate for the domain containing your users’ email accounts, you must first ensure that the deployment of such certificates is permitted by your corporate security policy. Other certificates for the domain containing your users’ email accounts can also be used, but users will see a certificate warning dialog box when Citrix Receiver first connects to the StoreFront server. Email-based account discovery cannot be used with any other certificate identities. For more information, see Configure email-based account discovery.
If your users configure their accounts by entering store URLs directly into Citrix Receiver and do not use email-based account discovery, the certificate on the StoreFront server need only be valid for that server and have a valid chain to the root certificate.
Token management certificates
Authentication services and stores each require certificates for token management. StoreFront generates a self-signed certificate when an authentication service or store is created. Self-signed certificates generated by StoreFront should not be used for any other purpose.
Citrix Delivery Services certificates
StoreFront holds a number of certificates in a custom Windows certificate store (Citrix Delivery Services). The Citrix Configuration Replication service, Citrix Credential Wallet service, and Citrix Subscriptions Store service use these certificates. Each StoreFront server in a cluster has a copy of these certificates. These services do not rely on TLS for secure communications, and these certificates are not used as TLS server certificates. These certificates are created when a StoreFront store is created or StoreFront is installed. Do not modify the contents of this Windows certificate store.
Code signing certificates
StoreFront installs various PowerShell scripts (.ps1) in the folder in
<InstallDirectory>\Scripts. The default StoreFront installation does not use these scripts, but you can use them to simplify specific and infrequent configuration tasks. These scripts are signed, allowing StoreFront to support PowerShell execution policy. We recommend the AllSigned policy. (The Restricted policy is not supported, as it prevents PowerShell scripts from running.) StoreFront does not alter the PowerShell execution policy.
Add a code signing certificate to the Trusted Publishers store, because StoreFront does not add it automatically. Without a certificate added the StoreFront management console Snap-in does not load when you enable the Turn on Script Execution policy setting and set Allow only signed script.
If you run the scripts in a PowerShell session, Windows automatically adds the code signing certificate in the Trusted Publishers store when the PowerShell script is run with the Always run option in the AllSigned execution policy. (If you select the Never run option, the certificate is added to the Untrusted Certificates store, and StoreFront PowerShell scripts do not run.)
Once the code signing certificate is added to the Trusted Publishers store, its expiration is no longer checked by Windows. You can remove this certificate from the Trusted Publishers store after the StoreFront tasks have been completed.
In a production environment, Citrix recommends using the Internet Protocol security (IPsec) or HTTPS protocols to secure data passing between StoreFront and your servers. IPsec is a set of standard extensions to the Internet Protocol that provides authenticated and encrypted communications with data integrity and replay protection. Because IPsec is a network-layer protocol set, higher level protocols can use it without modification. HTTPS uses the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols to provide strong data encryption.
The SSL Relay can be used to secure data traffic between StoreFront and XenApp servers. The SSL Relay is a default component of XenApp that performs host authentication and data encryption.
Citrix recommends securing communications between StoreFront and users’ devices using NetScaler Gateway and HTTPS. To use HTTPS, StoreFront requires that the Microsoft Internet Information Services (IIS) instance hosting the authentication service and associated stores is configured for HTTPS. In the absence of the appropriate IIS configuration, StoreFront uses HTTP for communications. Citrix strongly recommends that you do not enable unsecured user connections to StoreFront in a production environment.
StoreFront security separation
If you deploy any web applications in the same web domain (domain name and port) as StoreFront, then any security risks in those web applications could potentially reduce the security of your StoreFront deployment. Where a greater degree of security separation is required, Citrix recommends that you deploy StoreFront in a separate web domain.
ICA file signing
StoreFront provides the option to digitally sign ICA files using a specified certificate on the server so that versions of Citrix Receiver that support this feature can verify that the file originates from a trusted source. ICA files can be signed using any hash algorithm supported by the operating system running on the StoreFront server, including SHA-1 and SHA-256. For more information, see Enable ICA file signing.
User change password
You can enable Receiver for Web site users logging on with Active Directory domain credentials to change their passwords, either at any time or only when they have expired. However, this exposes sensitive security functions to anyone who can access any of the stores that use the authentication service. If your organization has a security policy that reserves user password change functions for internal use only, ensure that none of the stores are accessible from outside your corporate network. When you create the authentication service, the default configuration prevents Receiver for Web site users from changing their passwords, even if they have expired. For more information, see Optimize the user experience.
To strengthen security, do not write customizations that load content or scripts from servers not under your control. Copy the content or script into the Citrix Receiver for Web site custom folder where you are making the customizations. If StoreFront is configured for HTTPS connections, ensure that any links to custom content or scripts also use HTTPS.
Additional security information
This information may change at any time, without notice.
Your organization may want to perform security scans of StoreFront for regulatory reasons. The preceding configuration options can help to eliminate some findings in security scan reports.
If there is a gateway between the security scanner and StoreFront, particular findings may relate to the gateway rather than to StoreFront itself. Security scan reports usually do not distinguish these findings (for example, TLS configuration). Because of this, technical descriptions in security scan reports can be misleading.
When interpreting security scan reports, note the following:
HTML pages in StoreFront may not include clickjacking protection (by Content Security Policy or X-Frame-Options response headers). However, these HTML pages consist only of static content, and therefore clickjacking attacks are not relevant.
The version of Microsoft IIS and the use of ASP.NET are visible in HTTP headers. However, this information is already apparent from the presence of StoreFront itself, because it relies on these technologies.
When launching applications and desktops, StoreFront uses a token to protect against cross-site request forgery (CSRF). This token is sent as a cookie in a response without being marked as Secure or HttpOnly. When later sent in a request, the token is included in the query string of a URL. However, StoreFront does not rely on this mechanism to authenticate HTTP requests.
StoreFront uses the open source component jQuery. According to the jQuery open source project, a change was made in jQuery 1.12.0 to mitigate potential vulnerabilities in a specific form of cross-domain request. This change was not a mitigation to a vulnerability in jQuery itself; it was a mitigation to potential misuse by application logic. The relevant Citrix application logic, in the Receiver for Web feature shared by NetScaler and StoreFront, does not use this specific form of cross-domain request, is not affected by this vulnerability, and did not benefit from this mitigation.
This mitigation was later removed in jQuery 1.12.3 for compatibility reasons. Since the Citrix application logic did not benefit from this mitigation, this removal has no material impact in the versions of NetScaler and StoreFront using jQuery 1.12.4.
In this article
- Configure Microsoft Internet Information Services (IIS)
- Configure user rights
- Configure service settings
- Configure group memberships
- Certificates in StoreFront
- StoreFront communications
- StoreFront security separation
- ICA file signing
- User change password
- Additional security information