Deployment Guide: Multi-Domain FAS Architecture - External Electronic Health Records
Electronic health records (EHRs) are essential for healthcare professionals to provide critical care tasks to patients. Nearly9 out of 10 cliniciansuse 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 reports97 customersare 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.
Ourprevious documentationcovers 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 authenticationover 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, theFAS GPOmust 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 tohandle SAML authentication. If a NetScaler is in use this step does not need to occur. TheNetScaler handles the SAML authenticationand pass the user through to StoreFront.
Also, by default, theFAS default ruleonly includes VDAs in the customer domain - the rule needs to be updated to include hosted VDAs.
Citrix云方面的考虑
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 | Requiresmapping 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. |
Prerequisites
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. TheCVAD site settingof-TrustRequestsSentToTheXmlServicePort
is set to true. If using DaaS, instructions to configure this setting can be foundhere.
#run these commands on the Delivery Controller #add Citrix snap-in asnp Citrix* #see brokersite information get-brokersite #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
- Update the existing one-way trust to a two-way trust, either via theGUIorPowerShell.
Domain Local Groups and Selective Authentication
Note:
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.
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.
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.
In the customer domain, the hosted VDAs need permissions to authenticate against the FAS servers and Domain Controllers.
Note:
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.
In ‘Active Directory Users and Computers, navigate to the OU which contains the FAS servers. Right-click on the server, and select ‘Properties’.
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.
Click the ‘Advanced’ button and select ‘Add.’
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’.
Repeat steps 5–8 for the Domain Controllers OU.
VDA Certificates
- Distribute customer root and intermediate certificates to the hosted VDA golden images viaGPO. The hosted VDAs need the full customer certificate chain installed.
Validate that the root/intermediate certificates appear in theTrusted Root Certification Authority > Certificatesfolder of the VDA.
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 anMMC console > Add/Remove Snap-in > Enterprise PKI.
Right-click on the ‘Enterprise PKI’ and select ‘Manage AD Containers…’.
Go to the “NTAuthContainers’ tab, click ‘Add’ to add the customer root certificate from a location on the local machine.
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.Note:
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 theregular FAS configuration.
When creating thedefault FAS rule, under permissions for VDAs include the Hosted-AllowedAuth group to allow the hosted VDAs also to use FAS.
- Install theFAS .admx and .adml templateson the customer and hosted domain controllers.
On the customer domain, implement the Federated Authentication Service policy setting in theAdministrative Templates > Citrix Components > Authentication OU. This policy should point towards the FAS server and be applied to the folder containing the StoreFront servers.
Note:
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.On the hosted domain, implement the Federated Authentication Service policy setting in theAdministrative Templates > Citrix Components > Authentication OU. This policy should point towards the FAS server and be applied to the folder containing VDAs.
- Consider implementingFAS hardening recommendationsto improve FAS security.
- Validate that the application launch is working and that users can SSO to their resources.
Refer to thisblogto troubleshoot FAS issues.
References
FAS Authentication fails with an error “The username or password is incorrect”