There’s an old proverb that says, “All roads lead to Rome.” With it in mind, let’s consider a valued Citrix Service Provider (CSP) enterprise partner who asked us to assist in designing an environment that would allow for multiple, disparate customers (or roads) to be integrated into a single Citrix Virtual Apps and Desktops environment with Citrix Gateway (Rome). This all had to happen while ensuring an easy way to onboard future customers, and most importantly, avoid the creation of domain trusts.
When working with our CSPs, we constantly must be creative in helping deliver solutions for each unique use case. This case was no exception. Enter Citrix ADC and the Citrix Federated Authentication Service (FAS).
Before we get into the actual configuration, let’s dive deeper into the requirement. This CSP needed to onboard customers to their Citrix Virtual Apps and Desktops environment frequently, and their solution required Citrix Gateway to selectively provide a different SAML identity provider based on the user’s UPN suffix. In other words, customer A would use Azure AD, customer B would use Active Directory Federation Services, and so on. Additionally, the environment needed to provide single sign-on all the way to the Citrix VDAs through Citrix FAS, for which they would provide an internal Microsoft certificate authority and active directory environment to host the FAS shadow accounts.
Now, onto the actual configuration. I’m not going to focus on the Citrix StoreFront and FAS configuration because it’s standard. You can find FAS documentation at Citrix Docs. The real magic happens with the Citrix ADC, with the utilization of AAA, nFactor, and Citrix Gateway. We’ll briefly discuss the components and at the end of the post, you’ll find a video showing the actual configuration steps in the GUI and the CLI commands.
Considerations
Before completing the Citrix ADC configuration, you must do the following:
- Citrix ADC IPs are defined.
- CA Certificate is installed on the ADC, to be used by Citrix Gateway.
- SAML IDP is configured, and you have the SAML login and logout URLs and IDP certificate.
- Alternate UPN suffixes have been configured through Active Directory Domains and Trusts.
- Shadow accounts have been configured on Active Directory Users and Computers
- Active Directory Certificate Services has been configured.
- Citrix FAS and StoreFront are configured.
Please keep in mind that you cannot have duplicate user names across different UPN suffixes. Even though the UPN suffix will be different, the pre-Windows 2000 login name will be the same for all suffixes. For example, user1@domain-a.com and user1@domain-b.com could not exist under the same AD environment, even if they have a different UPN suffix.
SAML Authentication Servers (actions)
A SAML server (action) defines the specific configuration for a specific SAML IDP, whether it’s Azure AD, Okta, ADFS, or something else. In this specific scenario, we create a SAML action for both Azure AD and ADFS. There, we define the SAML IDP URLs, certificates, and more.
SAML Authentication Policies
The SAML authentication policies have a 1:1 relationship to the previously created actions, so an action is bound to a specific policy. In this case, each user’s UPN suffix is matched to the SAML policy through an expression. This is how Citrix ADC knows which IDP to use for that specific user.
Login Schemas
The login schema is a logical representation of the logon form written in XML. It’s an entity that defines what the user sees and specifies how to extract the data from the user. In this case we’ll define a “schema-less” schema for our second factor, and a username-only schema for our first factor. That way, the users will not be automatically redirected to a SAML IDP (as they would in a simpler SAML deployment on Citrix ADC). Instead, they will enter their UPN to allow for Citrix ADC to decide which IDP they need to authenticate against.
Policy Labels
A policy label specifies the authentication policies for a particular factor, and each policy label corresponds to a single factor. In our deployment we are creating a policy label that is attached to our “schema-less” schema. Each SAML authentication policy will be bound to this policy label.
No-Auth Policy
This is a special kind of policy that always returns success as the authentication result. This policy will be bound to our authentication virtual server as the first factor and will use the policy label as its next factor (thus forwarding user’s to their specific SAML IDPs).
Authentication Virtual Server
This authentication virtual server processes the associated authentication policies and provides access to the environment. This authentication virtual server will be bound to the authentication policy label we previously created and the username-only login schema. We will also bind it to an authentication profile.
Authentication Profile
The authentication profile lets you leverage nFactor on Citrix Gateway. You will bind this object to the Citrix Gateway virtual server. Review the Citrix ADC nFactor Basics Cheat Sheet in the Citrix Tech Zone for more information on the components of nFactor authentication.
The video below provides step-by-step guidance on this configuration and a demo of the user experience. I’ve also added the CLI commands for those of you who prefer it.
At this point you might be asking, how does our CSP add new customers to their environment? It’s actually easy and not disruptive. All they have to do is:
- Configure the end-customer’s SAML IDP
- Add the customer’s UPN suffix through Active Directory Domains and Trusts
- Add the shadow accounts to Active Directory Users and Computers
- Configure the SAML authentication server and advanced authentication policy
- Bind the new SAML authentication policy to the “schema-less” policy label
As you can see, Citrix ADC is a very powerful tool that helps our CSPs deploy their hybrid multi-cloud virtualization environments. If you are a CSP and have any question, or need help from your CSP team, please contact csp@citrix.com.
