Introduction

Over the past few months, I have worked in several multi-domain customer environments. As you can imagine, there are many considerations when designing the access layer in a multi-domain environment and different design options based on the requirements. Therefore, I want to share some multi-domain design options and considerations regarding NetScaler Gateway and StoreFront in a XenApp and XenDesktop environment.

Since there is a lot to cover, the design considerations will be split into a three-part blog series, which will focus on NetScaler and StoreFront configurations in multi-domain environments in which there are two-way trusts already established and domain credentials are used for authentication. The following topics will not be covered:

  • Federated authentication scenarios
  • Non-domain credentials being used for authentication, such as certificates, SAML tokens, RADIUS, or other MFA solutions
  • NetScaler AAA policies for services other than XenApp/XenDesktop. In other words, we are only looking at NetScaler Gateway in ICA Proxy mode.
  • XenApp/XenDesktop configurations required in multi-forest or otherwise complex Active Directory environments. More information about multiple forest environment considerations for XenApp and XenDesktop can be found here.

In this article, we will focus on NetScaler Gateway multi-domain authentication options. Parts 2 and 3 will cover session policy configurations and internal StoreFront authentication. Let’s get to it.

NetScaler Gateway Authentication

The first consideration with NetScaler Gateway (NSG) for multi-domain environments is how we configure authentication. The end goal is to configure a single NSG vServer for all domains to minimize the number of URLs that have to be communicated to users. With this in mind, we need to have our NSG vServer be aware of all domains (i.e. have authentication policies from all domains bound to it). This can be performed in the following ways:

  • Cascade Authentication: Per-domain authentication policies are bound to the NSG vServer each with policy expressions of “ns_true.” NetScaler will cascade through the authentication policies based on priority or listed order if priorities are the same. The cascade authentication process continues evaluating policies until a successful authentication is made, or until all authentication policies have been evaluated. Therefore, a successful authentication is made with the first authentication policy in the cascade order that returns an authentication success. Authentication fails when none of the authentication policies return an authentication success
  • Specifying a Domain: Contrary to cascade authentication, specifying a domain involves providing some logic to the authentication policy evaluation process such that, instead of cascading through all policies and attempting to authenticate against all domains, only the correct authentication policy (and therefore, domain) is evaluated. This is achieved by changing the policy expressions from “ns_true” to some logic that looks for a unique identifier for each domain, such as:
    • Different URLs: Different URLs can be configured for each domain, each URL with a unique identifier for the domain, all resolving to the same NSG VIP. The policy expressions can then be configured to find the unique identifier within the “Host” header of the HTTP request.
    • Domain Dropdown: A domain dropdown can be added to the NSG Logon Page so that users can choose which domain to authenticate against. This can be accomplished with either:
      • Rewrite Policy: This applies to versions NetScaler 11.0 64.x and later, and involves creating a rewrite policy and storing the domain identifiers in a cookie. The authentication policy expressions are then modified to find the unique identifier for each domain within the “Cookie” header of the HTTP request. Instructions for this method can be found here. (For NetScaler 10.0 through 10.5, instructions for a different configuration to achieve the same goal can be found here).
      • nFactor Authentication: This applies to NetScaler versions 11.0 62.x and later, and involves moving your authentication policies from “Basic Policies” to “Advanced Policies” via the AAA feature. More information regarding nFactor Authentication can be found here. I will not go into much configuration detail, but the idea would be to create a login schema that contains a domain dropdown (the domain dropdown login schema template can be used) and, similarly to the previous “Rewrite Policy” option, configure the authentication policy expressions to find an identifier based on the domain dropdown selection (more information on how to configure this can be found here).

Let’s look at the pros and cons of each of these options:

Authentication Policy Bind Method Advantages Considerations
Cascade Authentication Simpler configuration: the authentication policies can simply be bound to the NSG vServer using “ns_true” as the expression.

Less user input: the user does not need to provide the domain.

 Authentication duration: the amount of time it takes a user to login has the potential to increase as more authentication policies are required.

Account lockouts: if two or more domains have different user accounts configured with the same usernames, but different passwords, the domain that is higher in the list might experience account lockouts due to repeated, failed authentication attempts. Having users log in with userPrincipalName (UPN) can mitigate this risk.
Specifying a domain: different URLs Simpler configuration: does not require adding a domain drop down menu.

Less user input: The user does not need to provide the domain during authentication

 Additional URLs: managing multiple DNS records and providing users from different domains with different URLs can result in additional management overhead. Note that in this configuration each NSG URL would have to be added to StoreFront as a separate NSG object.

Incompatible with Receiver client: since Native Receiver uses the URL of the default NSG appliance configured in the StoreFront store (as described in this article), this configuration would not work if using Native Receiver to authenticate and connect externally.
Specifying a domain: drop down menu with rewrite policies Fewer URLs: eliminates the need for multiple URLs.

Simpler configuration than nFactor: requires adding a rewrite policy and modifying the authentication policy expressions.

 Incompatible with Receiver client: since Receiver does not support Rewrites, this configuration would not work if using Native Receiver to authenticate and connect externally.

Additional user input: this configuration requires another input from the user upon logon.
Specifying a domain: drop down menu with nFactor Fewer URLs: eliminates the need for multiple URLs.

More flexibility: provides much more flexibility to address different authentication requirements.

 Incompatible with Receiver client: since Receiver does not support nFactor authentication, this configuration would not work if using Native Receiver to authenticate and connect externally.

Additional user input: this configuration requires another input from the user upon logon.

Key Takeaways

Below are some key takeaways from the different authentication options discussed.

  • For the moment, the only compatible authentication policy bind method for Citrix Receiver is cascade authentication.
  • For connections via web browser:
    • Cascade authentication can be considered if:
      • the amount of domains and the authentication performance of the domains do not impact authentication times significantly
      • there are no common user names (or respective user logon attribute being used) across two or more domains
    • A domain drop down menu can be added via rewrite policies or using nFactor authentication to optimize the authentication policy evaluation process for multiple domains.

I hope this was helpful. In Part 2 of this series (coming soon), we will be covering session policy configurations for multi-domain environments.

Citrix TechBytes – Created by Citrix Experts, made for Citrix Technologists! Learn from passionate Citrix Experts and gain technical insights into the latest Citrix Technologies.

Click here for more TechBytes and subscribe.

Want specific TechBytes? Let us know! tech-content-feedback@citrix.com