Federated Authentication Service security and network configuration
The Citrix Federated Authentication Service (FAS) is tightly integrated with Microsoft Active Directory and the Microsoft certification authority (CA). 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 the 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 an FAS deployment.
The FAS server should be treated as part of the security-critical infrastructure, along with the CA and domain controller. In a federated environment, Citrix NetScaler and Citrix StoreFront are components that are trusted to perform user authentication; other XenApp and XenDesktop components are unaffected by introducing the FAS.
Firewall and network security
Communication between NetScaler, StoreFront and the Delivery Controller components should be protected by TLS over port 443. The StoreFront server performs only outgoing connections, and the NetScaler 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 CA accepts communication using Kerberos authenticated DCOM, which can be configured to use a fixed TCP port. The CA 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 CA|
|Netscaler||[in] HTTPS from client machines, [in/out] HTTPS to/from StoreFront server, [out] HDX to VDA|
|StoreFront||[in] HTTPS from NetScaler, [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 NetScaler Gateway, [out] Kerberos HTTP to FAS|
|Microsoft CA||[in] DCOM & signed from FAS|
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|
|CA Administrator||Configure the certificate authority|
|FAS Administrator||Install and configure the FAS server|
|StoreFront/Netscaler Admin||Configure user authentication|
|XenDesktop 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 an 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 an FAS server.
If you do not want to use the Citrix_SmartcardLogon certificate template supplied with the 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 Federated Authentication Service 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
You can modify these settings to match your organizational policy, if needed.
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 CA administrator is responsible for the configuration of the CA 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 CA administrator must choose to publish that template.
A simple security practice is to publish only the RA certificate templates when the FAS servers are being installed, or to insist on a completely offline issuance process. In either case, the CA administrator should maintain complete control over authorizing RA certificate requests, and have a policy for authorizing FAS servers.
Generally, the CA administrator will also have control of the network firewall settings of the CA, allowing control over incoming connections. The CA administrator can configure DCOM TCP and firewall rules so that only FAS servers can request certificates.
By default any holder of an RA 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” CA property.
For advanced deployments, custom security modules can be used to track and veto certificate issuance.
The 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 the 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 CA. 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 XenApp or XenDesktop deployments use the same FAS server infrastructure. Each rule has a separate set of configuration options; in particular, the 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 RA 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.
The 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.
XenApp, XenDesktop, and VDA administrators
In general, the use of the FAS doesn’t 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 CA and domain administrator accounts.
- The Federated Authentication Service article is the primary reference for FAS installation and configuration.
- FAS architectures are introduced in the Federated Authentication Service architectures overview article.
- Other “how-to” articles are introduced in the Federated Authentication Service configuration and management article.