Security and network configuration
Federated Authentication Service (FAS) is tightly integrated with Microsoft Active Directory and the Microsoft certification authority. It is essential to ensure that the system is managed and secured appropriately, developing a security policy as you would for a domain controller or other critical infrastructure.
This document provides an overview of security issues to consider when deploying FAS. It also provides an overview of features available that may assist in securing your infrastructure.
The following diagram shows the main components and security boundaries used in a FAS deployment.
The FAS server should be treated as part of the security-critical infrastructure, along with the certificate authority and domain controller. In a federated environment, Citrix Gateway and Citrix StoreFront are components that are trusted to perform user authentication; other Citrix Virtual Apps and Desktops components are unaffected by introducing FAS.
Firewall and network security
Communication between Citrix Gateway, StoreFront and the Delivery Controller components should be protected by TLS over port 443. The StoreFront server performs only outgoing connections, and the Citrix Gateway should accept only connections over the Internet using HTTPS port 443.
The StoreFront server contacts the FAS server over port 80 using mutually authenticated Kerberos. Authentication uses the Kerberos HOST/fqdn identity of the FAS server, and the Kerberos machine account identity of the StoreFront server. This generates a single use “credential handle” needed by the Citrix Virtual Delivery Agent (VDA) to log on the user.
When an HDX session is connected to the VDA, the VDA also contacts the FAS server over port 80. Authentication uses the Kerberos HOST/fqdn identity of the FAS server, and the Kerberos machine identity of the VDA. Additionally, the VDA must supply the “credential handle” to access the certificate and private key.
The Microsoft certificate authority accepts communication using Kerberos authenticated DCOM, which can be configured to use a fixed TCP port. The certificate authority additionally requires that the FAS server supply a CMC packet signed by a trusted enrollment agent certificate.
|Federated Authentication Service||[in] Kerberos over HTTP from StoreFront and VDAs, [out] DCOM to Microsoft certificate authority|
|Citrix Gateway||[in] HTTPS from client machines, [in/out] HTTPS to/from StoreFront server, [out] HDX to VDA|
|StoreFront||[in] HTTPS from Citrix Gateway, [out] HTTPS to Delivery Controller, [out] Kerberos HTTP to FAS|
|Delivery Controller||[in] HTTPS from StoreFront server, [in/out] Kerberos over HTTP from VDAs|
|VDA||[in/out] Kerberos over HTTP from Delivery Controller, [in] HDX from Citrix Gateway, [out] Kerberos HTTP to FAS|
|Microsoft certificate authority||[in] DCOM & signed from FAS|
Connections between Citrix Federated Authentication Service and Citrix Cloud
The console and FAS access the following addresses using the user’s account and the Network Service account, respectively.
- FAS administration console, under the user’s account
- Addresses required by a third party identity provider, if one is used in your environment
- FAS service, under the Network Service account:
If your environment includes proxy servers, configure the user proxy with the addresses for the FAS administration console. Also, ensure that the address for the Network Service account is configured using netsh or a similar tool.
FAS has a registration authority certificate that allows it to issue certificates autonomously on behalf of your domain users. As such, it is important to develop and implement a security policy to protect FAS servers, and to constrain their permissions.
FAS issues user certificates by acting as an enrollment agent. The Microsoft Certification Authority allows you to restrict enrollment agents, certificate templates, and users which enrollment agents can issue certificates for.
You can use this dialog to ensure that:
- The Enrollment agents list contains only FAS servers.
- The Certificate Templates list contains only the FAS templates.
- The Permissions list contains only users who are permitted to use FAS. For example, it is good practice to prevent FAS from issuing certificates to users in an Administration or Protected Users group.
As described in the Configure rules section, you must configure a list of StoreFront servers that are trusted to assert user identities to FAS when certificates are issued. Similarly, you can restrict which users will be issued certificates, and which VDA machines they can authenticate to. This is in addition to any standard Active Directory or certificate authority security features you configure.
All communication to FAS servers uses mutually authenticated Windows Communication Foundation (WCF) Kerberos network connections over port 80.
FAS and the VDA write information to the Windows Event Log. This can be used for monitoring and auditing information. The Event logs section lists event log entries that may be generated.
All private keys, including those of user certificates issued by FAS, are stored as non-exportable private keys by the Network Service account. FAS supports the use of a cryptographic hardware security module, if your security policy requires it.
Low-level cryptographic configuration is available in the FederatedAuthenticationService.exe.config file. These settings apply when private keys are first created. Therefore, different settings can be used for registration authority private keys (for example, 4096 bit, TPM protected) and runtime user certificates.
|ProviderLegacyCsp||When set to true, FAS uses the Microsoft CryptoAPI (CAPI). Otherwise, FAS uses the Microsoft Cryptography Next Generation API (CNG).|
|ProviderName||Name of the CAPI or CNG provider to use.|
|ProviderType||Refers to Microsoft KeyContainerPermissionAccessEntry.ProviderType Property PROV_RSA_AES 24. Should always be 24 unless you are using an HSM with CAPI and the HSM vendor specifies otherwise.|
|KeyProtection||Controls the “Exportable” flag of private keys. Also allows the use of Trusted Platform Module (TPM) key storage, if supported by the hardware.|
|KeyLength||Key length for RSA private keys. Supported values are 1024, 2048 and 4096 (default: 2048).|
Administration of the environment can be divided into the following groups:
|Enterprise administrator||Install and secure certificate templates in the forest|
|Domain administrator||Configure Group Policy settings|
|Certificate authority administrator||Configure the certificate authority|
|FAS administrator||Install and configure the FAS server|
|StoreFront/Citrix Gateway administrator||Configure user authentication|
|Citrix Virtual Desktops administrator||Configure VDAs and Controllers|
Each administrator controls different aspects of the overall security model, allowing a defense-in-depth approach to securing the system.
Group Policy settings
Trusted FAS machines are identified by a lookup table of “index number -> FQDN” configured through Group Policy. When contacting a FAS server, clients verify the FAS server’s
HOST\<fqdn> Kerberos identity. All servers that access the FAS server must have identical FQDN configurations for the same index; otherwise, StoreFront and VDAs may contact different FAS servers.
To avoid misconfiguration, Citrix recommends that a single policy be applied to all machines in the environment. Take care when modifying the list of FAS servers, especially when removing or reordering entries.
Control of this GPO should be limited to FAS administrators (and/or domain administrators) who install and decommission FAS servers. Take care to avoid reusing a machine FQDN name shortly after decommissioning a FAS server.
If you do not want to use the Citrix_SmartcardLogon certificate template supplied with FAS, you can modify a copy of it. The following modifications are supported.
If you want to rename the Citrix_SmartcardLogon to match your organizational template naming standard, you must:
- Create a copy of the certificate template and rename it to match your organizational template naming standard.
- Use FAS PowerShell commands to administer FAS, rather than the administrative user interface. (The administrative user interface is only intended for use with the Citrix default template names.)
- Either use the Microsoft MMC Certificate Templates snap-in or the Publish-FasMsTemplate command to publish your template, and
- Use the New-FasCertificateDefinition command to configure FAS with the name of your template.
You can modify the Validity period in the certificate template.
Do not modify the Renewal period. FAS ignores this setting in the certificate template. FAS automatically renews the certificate halfway through its validity period.
Do not modify these properties. FAS ignores these settings in the certificate template. FAS always deselects Allow private key to be exported and deselects Renew with same key.
Do not modify these properties. FAS ignores these settings in the certificate template.
Refer to Private key protection for equivalent settings that FAS provides.
Do not modify these properties. FAS does not support key attestation.
Do not modify these properties. FAS does not support superseding templates.
You can modify these settings to match your organizational policy.
Note: Inappropriate Extension settings may cause security issues, or result in unusable certificates.
Citrix recommends that you modify these settings to Allow the Read and Enroll permissions for only the machine accounts of the FAS servers. No other permissions are required by the FAS service. However, as with other certificate templates, you may want to:
- allow administrators to Read or Write the template
- allow authenticated users to Read the template
Citrix recommends that you don’t modify these properties.
The template has Build from this Active Directory information selected, causing the certificate authority to include the user’s SID in a certificate extension. Which provides a strong mapping to the user’s Active Directory account.
Although Citrix does not recommend it, you can modify these settings to match your organizational policy, if needed.
Do not modify these settings. These settings should be as shown:
You can modify these settings. The setting must be at least Windows Server 2003 CAs (schema version 2). However, FAS supports only Windows Server 2008 and later CAs. Also, as explained above, FAS ignores the additional settings available by selecting Windows Server 2008 CAs (schema version 3) or Windows Server 2012 CAs (schema version 4).
Certificate authority administration
The certificate authority administrator is responsible for the configuration of the certificate authority server and the issuing certificate private key that it uses.
For a certificate authority to issue certificates based on a template supplied by the enterprise administrator, the certificate authority administrator must choose to publish that template.
A simple security practice is to publish only the registration authority certificate templates when FAS servers are being installed, or to insist on a completely offline issuance process. In either case, the certificate authority administrator should maintain complete control over authorizing registration authority certificate requests, and have a policy for authorizing FAS servers.
Generally, the certificate authority administrator will also have control of the network firewall settings of the certificate authority, allowing control over incoming connections. The certificate authority administrator can configure DCOM TCP and firewall rules so that only FAS servers can request certificates.
By default any holder of an registration authority certificate can issue certificates to any user, using any certificate template that allows access. This should be restricted to a group of non-privileged users using the “Restrict enrollment agents” certificate authority property.
For advanced deployments, custom security modules can be used to track and veto certificate issuance.
FAS has several security features.
At the center of the FAS security model is the control for which Kerberos accounts can access functionality:
|StoreFront [IdP]||These Kerberos accounts are trusted to declare that a user has been correctly authenticated. If one of these accounts is compromised, then certificates can be created and used for users allowed by the configuration of FAS.|
|VDAs [Relying party]||These are the machines that are allowed to access the certificates and private keys. A credential handle retrieved by the IdP is also needed, so a compromised VDA account in this group has limited scope to attack the system.|
|Users||This controls which users can be asserted by the IdP. Note that there is overlap with the “Restricted Enrollment Agent” configuration options at the certificate authority. In general, it is advisable to include only non-privileged accounts in this list. This prevents a compromised StoreFront account from escalating privileges to a higher administrative level. In particular, domain administrator accounts should not be allowed by this ACL.|
Rules are useful if multiple independent Citrix Virtual Apps or Citrix Virtual Desktops deployments use the same FAS server infrastructure. Each rule has a separate set of configuration options; in particular, the Kerberos access control lists (ACLs) can be configured independently.
Different certificate templates and CAs can be configured for different access rights. Advanced configurations may choose to use less or more powerful certificates, depending on the environment. For example, users identified as “external” may have a certificate with fewer privileges than “internal” users.
The FAS administrator can control whether the certificate used to authenticate is available for use in the user’s session. For example, this could be used to have only “signing” certificates available in-session, with the more powerful “logon” certificate being used only at logon.
The FAS administrator can configure FAS to store private keys in a Hardware Security Module (HSM) or Trusted Platform Module (TPM). Citrix recommends that at least the registration authority certificate private key is protected by storing it in a TPM; this option is provided as part of the “offline” certificate request process.
Similarly, user certificate private keys can be stored in a TPM or HSM. All keys should be generated as “non-exportable” and be at least 2048 bits in length.
The FAS server provides detailed configuration and runtime event logs, which can be used for auditing and intrusion detection.
FAS includes remote administration features (mutually authenticated Kerberos) and tools. Members of the “Local Administrators Group” have full control over FAS configuration. This list should be carefully maintained.
Citrix Virtual Apps, Citrix Virtual Desktops, and VDA administrators
In general, the use of FAS does not change the security model of the Delivery Controller and VDA administrators, as the FAS “credential handle” simply replaces the “Active Directory password.” Controller and VDA administration groups should contain only trusted users. Auditing and event logs should be maintained.
General Windows server security
All servers should be fully patched and have standard firewall and anti-virus software available. Security-critical infrastructure servers should be kept in a physically secure location, with care taken over disk encryption and virtual machine maintenance options.
Auditing and event logs should be stored securely on a remote machine.
RDP access should be limited to authorized administrators. Where possible, user accounts should require smart card logon, especially for certificate authority and domain administrator accounts.
In this article
- Network architecture
- Firewall and network security
- Connections between Citrix Federated Authentication Service and Citrix Cloud
- Security considerations
- Administration responsibilities
- Group Policy settings
- Certificate templates
- Certificate authority administration
- FAS administration
- Citrix Virtual Apps, Citrix Virtual Desktops, and VDA administrators
- General Windows server security
- Related information