Jump to content

Deployment Guide: Multi-Domain FAS Architecture - External Electronic Health Records

  • Contributed By: Emma Bland, PJ Calderon Special Thanks To: Rob Zylowski, Steve Beals, Mallory Guarisco

Electronic health records (EHRs) are essential for healthcare professionals to provide critical care tasks to patients. Nearly 9 out of 10 clinicians use an EHR as of 2021. Because of the work effort required to host and deploy EHRs, many healthcare businesses use third party hosted solutions. Epic reports 97 customers are using Epic’s own privately hosted cloud.

Alongside these external deployments, many healthcare companies are moving towards SAML-based authentication to enhance security as it provides more flexibility and granular policies around authentication. SAML provides a challenge for deployments using internal and third party hosted Citrix environments: how to enable a consistent SSO to the VDAs without LDAP authentication? This challenge can be solved by implementing the Citrix Federated Authentication Service (FAS) with the external vendor via Active Directory (AD) two-way trusts. The trust can either be a two-way forest trust or a two-way external trust between the specific domains.

Our previous documentation covers the configuration when the users and the computer objects are in two separate domains. This deployment guide covers the configuration when the Citrix infrastructure is split between two domains, which is common for third-party hosted EHRs. A future deployment guide is planned for alternate domain configurations.

Active Directory Trusts Refresher

Most end users need access to multiple domains for shared resources, and trusts enable users to access those domains. When there's a trust between domains, the authentication processes in each domain trust the authentication coming from the other domain. Trusts can be one-way trusts - providing access to resources in a trusting domain to users in the trusted domain. Trusts can also be two-way - providing access from each domain to resources in the other.

There's also the scope of the trust to consider. Trusts have two options: forest-wide authentication or selective authentication. Forest-wide authentication allows users from the trusting domain to authenticate against all resources in the trusted domain. Selective authentication does not automatically allow users to access resources in the trusted domain. Administrators need to grant individual access to the specific resources they want end users to use. Forest-wide trusts are preferred when both forests belong to the same organization. Selective authentication trusts are preferred if the forests belong to different organizations. Organizations can also have both types of scopes in separate directions (selective outbound and full inbound or the opposite).

To configure FAS with third-party hosted VDAs, a two-way trust is required. The third-party hosted forest must trust the customer forest for a customer account to log on to a VDA in that hosted forest.

The customer forest must also trust the hosted forest, as the hosted VDAs must communicate with customer FAS servers and Certificate Authorities. For security purposes, as in this case a third-party organization hosts the VDAs, Citrix recommends configuring selective authentication over forest-wide authentication.

Conceptual Architecture


High-Level Configuration Summary

For an organization to enable FAS SAML authentication against external resources, a two-way trust needs to be enabled for reasons discussed in the previous section. Customer users must be able to authenticate against the Citrix resources in the hosted domain. This includes both Delivery Controllers or Cloud Connectors and VDA computer objects. To authenticate against FAS, hosted VDAs must be able to authenticate against the customer FAS server and Domain Controller.

Also, to allow hosted VDAs to authenticate against the customer Certificate Authority, any root/intermediate certificates from the customer's domain must be added to the VDA. The certificates must be added to the NTAuth and Trusted Root Certificate Authorities stores on the VDAs. The hosted VDA reaches out to the customer domain and as such needs the customer certificate chain.

On the FAS side, the FAS GPO must be configured in both domains to point the hosted VDAs and customer StoreFront towards the FAS server. If users are authenticating directly at StoreFront, the relevant StoreFront stores must be configured to handle SAML authentication. If a NetScaler is in use this step does not need to occur. The NetScaler handles the SAML authentication and pass the user through to StoreFront.

Also, by default, the FAS default rule only includes VDAs in the customer domain - the rule needs to be updated to include hosted VDAs.

Citrix Cloud Considerations

This article details the configurations required when the customer and hosting environments are entirely on-premises. The table lists the configuration changes required when implementing the solution with the various Citrix Cloud solutions.

Customer\Hosting CVAD DaaS
CVAD + StoreFront Covered in this article. No configuration change is needed. Anything referencing hosted Delivery Controllers should be applied to hosted Cloud Connectors.
DaaS + StoreFront No configuration change is needed. Anything referencing hosted Delivery Controllers should be applied to hosted Cloud Connectors. No configuration change is needed. Anything referencing hosted Delivery Controllers should be applied to hosted Cloud Connectors.
DaaS + Workspace Requires mapping the on-premises hosting CVAD site into the Workspace UI. It's not currently possible to map multiple DaaS tenants into the Workspace UI. This feature is in public tech preview. Contact your Account Technology Specialist if you want to enable this feature.


This deployment guide assumes that end users are already accessing externally hosted VDAs. The only configuration changes needed are to enable SAML authentication with FAS. In this scenario, there's already a one-way trust between the customer and the hosting domain to allow users to authenticate. Customer users have been configured to authenticate against hosted Delivery Controllers and VDAs. The CVAD site setting of -TrustRequestsSentToTheXmlServicePort is set to true. If using DaaS, instructions to configure this setting can be found here.

#run these commands on the Delivery Controller
#add Citrix snap-in
asnp Citrix*
#see brokersite information
#set XML trust requests to true
set-brokersite -TrustRequestsSentToTheXmlServicePort $true

If the environment isn't currently configured for externally hosted VDAs, a one-way trust does not need to be configured. A two-way trust can be deployed from the start. The additional prerequisites need to be configured for successful resource access.

Deployment Steps

AD Trust Configuration

  1. Update the existing one-way trust to a two-way trust, either via the GUI or PowerShell.

Domain Local Groups and Selective Authentication


If you use forest-wide authentication (instead of the recommended selective authentication), you can skip these steps as permissions don't have to be explicitly defined.

  1. Citrix recommends creating a domain local Active Directory group for the hosted VDAs in the customer domain. These groups make it easier to apply authentication permissions. In this example, the domain local group is called ‘Hosted-AllowedAuth.’ All VDAs in the hosted domain should be added to this group. In this example, a security group of all the VDAs is used.


  2. If a one-way trust is already in place, then customer users should already have a domain local group with permission to authenticate against the hosted Delivery Controller and VDAs. If this configuration wasn't previously used, create a domain local group with the customer Citrix users in the hosted domain.


  3. In the customer domain, the hosted VDAs need permissions to authenticate against the FAS servers and Domain Controllers.


    If you haven’t done an external deployment before, you must allow customer users to authenticate against the hosted Delivery Controllers and VDAs. The same process shown applies to those permissions as well.

  4. In ‘Active Directory Users and Computers, navigate to the OU which contains the FAS servers. Right-click on the server, and select ‘Properties’.


  5. Click the ‘Security’ tab to view permissions. Note, if you do not see the ‘Security’ tab, you must enable ‘Advanced Features’, found under the ‘View’ menu.



  6. Click the ‘Advanced’ button and select ‘Add.’


  7. For the principal, select the Hosted-AllowedAuth group created previously. This permission should apply to ‘Descendant Computer objects’. Grant ‘Allowed to authenticate’ permissions. ‘Read’ permissions are added automatically. Click ‘OK’.


  8. Repeat steps 5–8 for the Domain Controllers OU.

VDA Certificates

  1. Distribute customer root and intermediate certificates to the hosted VDA golden images via GPO. The hosted VDAs need the full customer certificate chain installed.

  2. Validate that the root/intermediate certificates appear in the Trusted Root Certification Authority > Certificates folder of the VDA.


  3. This guide walks through how to add certificates to the NTAuth AD container. This method pushes the customer root CA to all computers NTAuth stores in the domain. If you only want to install the certificates on the VDAs, skip to step 6. In the hosted environment, navigate to the hosted Certificate Authority and open an MMC console > Add/Remove Snap-in > Enterprise PKI.


  4. Right-click on the ‘Enterprise PKI’ and select ‘Manage AD Containers...’.


  5. Go to the “NTAuthContainers’ tab, click ‘Add’ to add the customer root certificate from a location on the local machine.


  6. In PowerShell on the VDA golden image, use the command certutil -viewstore -enterprise NTAuth. Validate that the customer certificates have been installed in the NTAuth store.



    PowerShell commands can be used to add the certificate to the NTAuth store locally on the VDA image.

    #add certificate:
    certutil -addstore- enterprise NTAuth “C:\filepath\certname.cer”
    #delete certificate:
    certutil -viewdelstore -enterprise NTAuth
    #view NTAuth Store:
    certutil -viewstore -enterprise NTAuth

FAS Configuration

This configuration requires slight modifications from the regular FAS configuration.

  1. When creating the default FAS rule, under permissions for VDAs include the Hosted-AllowedAuth group to allow the hosted VDAs also to use FAS.


  2. Install the FAS .admx and .adml templates on the customer and hosted domain controllers.

  3. On the customer domain, implement the Federated Authentication Service policy setting in the Administrative Templates > Citrix Components > Authentication OU. This policy should point towards the FAS server and be applied to the folder containing the StoreFront servers.


    If you would prefer to use registry keys to implement this setting, the registry key is in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Citrix\Authentication\UserCredentialService\Addresses. The key name is Address1, and the value is the FQDN of the FAS server. If you use multiple FAS servers, you can add more keys using the name Address2, Address3, etc.


  4. On the hosted domain, implement the Federated Authentication Service policy setting in the Administrative Templates > Citrix Components > Authentication OU. This policy should point towards the FAS server and be applied to the folder containing VDAs.


  5. Consider implementing FAS hardening recommendations to improve FAS security.

  6. Validate that the application launch is working and that users can SSO to their resources.

Refer to this blog to troubleshoot FAS issues.


FAS Product Documentation

FAS Multi-Domain Blog

Troubleshooting FAS Blog

FAS Authentication fails with an error "The username or password is incorrect"

Automating FAS Blog

Windows Authentication Concepts

User Feedback

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Create New...