HowTo: Active-Active Multi-Datacenter Citrix FAS

January 31st, 2019

Purpose

This article’s intent is to illustrate an ideal config of FAS in order to accommodate FAS being deployed in a multi-site scenario, while optimizing communication flows for Citrix Federated Authentication Service (FAS).

This article is NOT a how-to guide on installing and configuring FAS or Azure MFA integration to Citrix ADC. For those steps, hit up these useful links:

https://www.carlstalhood.com/citrix-federated-authentication-service-saml/

https://www.antonvanpelt.com/use-azure-ad-idp-citrix-federated-authentication-service/

Context

Citrix FAS is becoming more prevalent among customers looking to provide a unified authentication solution across web apps. Shoehorning it into more complex Citrix deployments however may be a little challenging and introduces several considerations in architecture such as CA security, HSMs, deployment architecture, and so on.

What is FAS? My dear colleague Zeljko Macanovic; an Architect with Citrix Consulting here in Canada summed it up succinctly as “Federating between non-LDAP authentication (SAML, OAuth, etc.) and LDAP authentication using certificates as virtual smart cards.” Poetic isn’t it? I thought so.

In a more recent use case we’ve been dealing with a multi-national client deploying a greenfield Citrix platform with the following high-level architecture:

  • Two physical locations in close proximity to each other
  • Access tier configured in an Active-Active manner (URL via GTM and Citrix Sites via StoreFront load balancing aggregation)
  • Azure MFA via SAML (no on-prem NPS proxy) via Citrix Gateway
  • Citrix FAS servers local to each datacenter – we had the customer deploy a dedicated Issuing CA for use by FAS for security reasons, with the new CA’s cert auto-deployed to all domain members.
  • Citrix StoreFront server group local to each datacenter
  • Citrix ADC 12.1 b50.31 & Citrix virtualization stack running on CR 1811

The customer’s desired use case is to operate both the access tier and resource tier in an active-active manner. No Site preference is configured for users in StoreFront, any user may launch via StoreFront which may launch from either Citrix Site as intended in their HA architecture.

The following diagram provides a conceptual overview of the deployed platform and component integration:

The Challenge

We could easily configure StoreFront, FAS, and VDAs of both datacenters to leverage all FAS servers via the FAS ADMX templates. To optimize authentication flows however, the Citrix Gateways are configured to interface only with the local StoreFront VIP for their datacenter. We also ideally want to localize StoreFront and FAS communication, vs. allowing StoreFront to interface with FAS servers across datacenters. In our scenario this isn’t that significant a latency concern, but for those in scenarios wherein datacenters are geographically distant from each other, this desire to localize may be more relevant.

From the VDA standpoint however, they need to be able to interface with ALL FAS servers as connections may be established from either Citrix Gateway and StoreFront servers of the respective datacenters. Even if there was a StoreFront user farm mapping setup in place and the datacenters more remote from each other, this would still be a necessity.

FAS server associations are set via ADMX templates, to StoreFront, FAS, and VDAs. The easy route in this scenario would be to apply the same GPO settings (all FAS server) to all of these components, and in our case that probably would have been fine, but that prevents localization of StoreFront and FAS intercommunication at each datacenter as is our intent.

To further complicate things, setting FAS servers via ADMX templates is a little unforgiving. The order in which FAS servers are set when applying the settings to VDAs and StoreFront\FAS servers must be identical otherwise you’ll encounter SSO not occurring to some VDAs at session launch.

For example, take for instance the following server orders set in a GPO applying to VDAs of both datacenters.

  1. fas1-dc1.domain.com
  2. fas2-dc1.domain.com
  3. fas1-dc2.domain.com
  4. fas2-dc2.domain.com

Then FAS and StoreFront servers must have their FAS server GPO settings configured in the same order. I.E. DC1 FAS\StoreFront servers having FAS1-DC1 and FAS2-DC1 servers specified in lines 1 and 2, and for DC2, the FAS servers specified in lines 3 and 4.

This requires 3 different sets of FAS ADMX GPO configs; one for DC1 SF\FAS servers, one for DC2 SF\FAS servers, and one for VDAs of both DC1 and DC2 listing all FAS servers.

The challenge is the way in which the FAS ADMX file accepts line item entries, it auto-removes blank lines when applying the config in GPMC.

Solution

Injecting spaces into the blank lines of the FAS server order will retain the blank lines when applying the GPO settings. For DC1’s FAS GPO we put a space in lines 3 and 4, and for DC2’s FAS GPO, we do the same in lines 1 and 2. The alternative would be forgoing the ADMX entirely and setting the servers via GPP but what’s the fun in that.

Once applied, we validated that from either Citrix Gateway, we could successfully log in via Azure MFA and launch Citrix resources from either datacenter, from either Gateway, and SSO occurs successfully.

Shout out to Citrix Consulting Sr. Enterprise Architect Ryan McClure for the suggestion.

1
Leave a Reply

avatar
1 Comment threads
0 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
1 Comment authors
Arun Recent comment authors
  Subscribe  
newest oldest most voted
Notify of
Arun
Guest
Arun

Wow, this is so cool!! Thank you for thinking of this solution, tested it and posted it in here!! Appreciate it!!