Earlier this summer Citrix announced support for Citrix FAS Multi Resource location in Public Tech preview.
If you’re new to Citrix FAS and what it’s all about or how to deploy it – there’s plenty of excellent knowledge base articles already covering the topic in detail.
With a live use case for implementing Citrix FAS single sign-on to multiple resource locations under the same Citrix Cloud tenant – I was eager to try this out.
This Tech Preview allows customers to add a FAS server to be leveraged in multiple resource locations. Customers can then share a highly available set of FAS servers across multiple RLs when their architecture allows. This greatly reduces the need for additional on-premises infrastructure and greatly reduces the deployment/ management costs for these customers. When a FAS server is set for multiple RLs, admins can also set a priority (Primary/Secondary) such that when the primary FAS servers in an RL are down, traffic will failover to the secondary set of FAS servers.
In a typical FAS deployment – you need 2 x Citrix FAS servers deployed in your resource location for high availability, as well as an internal Microsoft Certification Authority server to publish the Citrix SmartLogon templates that Citrix FAS requires to operate successfully. With FAS multi resource location – you no longer need to deploy additional FAS servers or build / utilize an internal CA in the secondary resource location. You can simply point your secondary resource location at your FAS servers deployed in your primary resource location and away you go. Done and dusted. SSO to your published apps in your secondary resource location works as soon as you add the FAS servers to the resource location configuration as per below.
Well, not quite. There’s a little more to it as I’ll delve into below. To date the Citrix KB article detailing how to implement is pretty light on the additional configuration steps that will be required.
First, what are the pre-requisites for FAS mutli resource location to work in an environment:
- Network connectivity between your resource locations
- Multiple domains allowed if they reside within a single AD forest
- DNS resolution between your resource locations (i.e., FAS servers in the primary resource location must be reachable via DNS from the secondary resource location)
Implementation Steps
Step 1 – Configure FAS servers for secondary resource location
Locate the FAS server you want to manage, click the ellipsis (…) at the right side of the entry, and then select Manage Server.
Select Add to a resource location and then select the resource locations that you want.
Select Primary or Secondary for the FAS server’s failover priority in each selected resource location.
Select Save Changes.
Step 2 – Deploy Citrix FAS GPO to Citrix Workloads OU
The first additional and obvious configuration step which Citrix have not yet documented is pointing your Citrix Workloads in the secondary resource location at the FAS servers.
This is done via Group policy. If your secondary resource location is a separate domain – you may need to deploy the Citrix FAS ADMX/ADML templates to your SYSVOL in that domain to make them available for use.
Then create a GPO linked to your workloads OU with the below configuration:
From experience with multiple FAS deployments, I’ve also noticed that despite group policy refreshing successfully – the workloads generally need a full restart for FAS single sign-on to work successfully.
Step 3 – Update permissions in Citrix FAS Administration console for secondary RL users
After completing the first two steps above and rebooting the Citrix Session host servers in the secondary resource location, I was hopeful that that the SSO through Citrix FAS would now work for published resources in that resource location. However, when launching a published application I still received the Windows server logon window, demonstrating that SSO was not yet working.
Thankfully the event logging on the Citrix FAS server is pretty informative, so I was able to see pretty quickly why the attempted FAS operation was failing:
Note: the event will most likely be generated on whichever FAS server you have defined as the Primary for the secondary resource location.
As we can see from above error – the user attempting the SSO to a published resource in the secondary resource location does not have the required permissions to the Default rule configured on the FAS authentication server.
To resolve this issue you need to add the domain users from the secondary resource location / domain with User Authentication permissions on the Default role. On the Citrix FAS Administration console – edit the Default rule and choose Manage User Permissions:
Add Domain Users from your secondary domain – giving them the required permissions to run this rule:
Step 4 – Update permissions in the FAS Administration console for VDA permissions
You also need to add the Domain Computers from the secondary resource location in the Manage VDA permissions for the Default Rule.
Add Domain Computers from your secondary domain and give them Allow permissions as per below screenshot:
Note: It is important to remember that you need to complete Steps 3 & 4 on all FAS servers in your environment, as each FAS server is configured independently of each other.
You can now re-test launching published resources in your secondary location and observe if SSO works. If not – there may be some Domain trust issues stopping the service from working as I’ve detailed below.
Domain Trust Considerations
Having completed the above implementation steps on my use case site, I retested if the FAS multi resource location was now working for my secondary site. Unfortunately I was still getting the Windows server logon window pop up when launching published resources. This time however, the event logs on the Citrix FAS server didn’t indicate the source of the issue.
Upon checking the CA (Certificate Authority) server to where the SmartLogon templates were published to and authorized from – I observed the following event in the event logs:
There is a two way domain trust already in place but it appears that enabling Cross Forest Certificate enrollment between domains is a relatively complex configuration. So much for FAS multi resource location simplifying my infrastructure configuration. At this stage in my specific example, it will be quicker to build and configure FAS servers in the secondary resource location specifically for SSO in that RL.
Summary
There is a definite use case for utilizing FAS multi resource location support if you infrastructure architecture supports the required prerequisites. But if the architecture involves multiple domains within a single root forest, it would appear that unless Cross Forest Certificate Enrollment is already configured and working you’re going to run into issues as demonstrated above.
If you’ve had success or failure in trying FAS multi resource location yourself – please let me know in the comments below. I’d love to hear others experience of this feature.