In Part 1 of this series, we discussed different options of configuring NetScaler Gateway authentication policies for XenApp and XenDesktop in a multi-domain environment. In this article, we will focus on multi-domain configuration options for NetScaler Gateway session policies. The same list of topics that will not be covered in the series mentioned in Part 1 apply to this article, so if you haven’t done so already, please take a moment to read and familiarize yourself with the first article of this series. Otherwise, let’s get to it.

NetScaler Gateway Session Policies

Now that we have covered authentication options, let’s discuss how we map different users, user groups, or domains to different (or the same) StoreFront stores. Within NetScaler Gateway, session policies are used to direct users to a specific StoreFront store. Since we are talking about different domains, there are different considerations depending on if we want to use the same StoreFront store for all users and domains, or different StoreFront stores. Generally, deploying as few stores as possible is preferred to simplify management. Therefore, if the requirements for these settings are the same across domains, a single store should be configured. The main reasons why you would create different StoreFront stores for different users or domains are if any of the following requirements are different for each domain:

  • StoreFront branding
  • Workspace Control settings
  • Optimal Gateway Routing (OGR)
  • Session timeouts
  • Whether subscriptions will be enabled or disabled
  • Authentication requirements (or if StoreFront has to delegate authentication to XML in order to authenticate users in each domain)
  • Other advanced settings

In any case, either with a single store or multiple stores, NetScaler Gateway Session policies include two important settings:

  • The “Web Interface Address” setting, which is the StoreFront store to send users to
  • The “Single Sign-on (SSO) Domain” setting to tell StoreFront which domain to authenticate the user against. Unlike NSG, StoreFront does not cascade authentication requests amongst a list of domains; therefore, the user domain must be provided as part of the authentication request.

There are several options for configuring Gateway Session Policies in multi-domain scenarios depending on whether a single or multiple StoreFront stores are configured:

Session Policies Single StoreFront Store Multiple StoreFront Stores
Single Session Policy Option 1:
  • LDAP Profile SSO Name Attribute: userPrincipalName
  • Session Policy Web Interface Address: <single Store address>
  • Session Policy Single Sign-on Domain: Blank
N/A (different “Web Interface Address” values must be applied)
Multiple Session Policies Option 1:
  • LDAP Profile SSO Name Attribute: sAMAccountName
  • LDAP Profile Group Attribute: memberOf
  • AAA Group defined matching <domain Citrix users group>
  • Session Policy Single Sign-on Domain: <domain name>
  • Session Policy bound to AAA group
  • Session Policy Web Interface Address: <single Store address>
  • Session Policy Web Interface Address: <per-domain Store address>
Option 2:
  • LDAP Profile SSO Name Attribute: sAMAccountName
  • LDAP Profile Default Authentication Group: <domain group>
  • AAA Group defined matching Default Authentication Group
  • Session Policy Web Interface Address: <per-domain Store address>
  • Session Policy Single Sign-on Domain: <domain name>
  • Session Policy bound to AAA group
  • Session Policy Web Interface Address: <single Store address>
  • Session Policy Web Interface Address: <per-domain Store address>
 N/A Option 3:
  • LDAP Profile SSO Name Attribute: userPrincipalName
  • Session Policy Web Interface Address: <per-domain Store address>
  • Session Policy Single Sign-on Domain: Blank

These options are explored in greater detail below.

  • Single Session Policy: With a single StoreFront store for all users, we can get away with a single Gateway Session Policy for all users in a multi-domain architecture so long as the SSO Domain is not specified. This requires another means of informing StoreFront of the user domain, which we accomplish by passing the UPN instead of the sAMAccountName as the SSO Name Attribute within the LDAP authentication profiles. Although this configuration is simpler, as it requires only one session policy, it relies on UPNs being configured correctly within Active Directory. If UPNs across all domains are not configured correctly, this is not a viable option. This option also requires adding the FQDN of the domain in StoreFront as a “Trusted Domain” (so not just contoso, but contoso.com).
  • Multiple Session Policies: If using UPN for StoreFront is not an option, we must configure different session policies for each domain, with the SSO Domain field populated in the Session Policy and sAMAccountName configured as the SSO Attribute in the LDAP profiles. The SSO Domain in the Session Policy name must match the name configured in StoreFront Trusted Domains list (if configured). The challenge becomes how do we map the correct domain session policies to a user? This can be done by binding our session policies to different AAA Groups created within NetScaler. Two methods are:
    • AD Group Extraction: This option requires having a security group configured in AD that contains all Citrix users within the domain (e.g. “CitrixUsersDomainA”, “CitrixUsersDomainB”, etc.). This user group name must be unique in each domain.
      • You would then configure the authentication policies to perform group extraction by adding the appropriate Group Attribute in the LDAP authentication profile as described here. Optionally, the group can be configured as the search filter (using the CN notation) to only allow users within that group to authenticate.
      • Lastly, you would create a AAA group under the NetScaler Gateway configurations for each AD group configured for Citrix users within each domain (the AAA group name must match exactly the group name in AD), and then bind the appropriate domain session policy to the appropriate domain AAA group configured in NetScaler.
      • One important note is that, as described here, the group configured as the primary group in AD is not used for group extraction. Therefore, in most cases, the Domain Users group cannot be used as a nested group under the “Citrix Users” group (not to mention that Domain Users cannot be used as the “Citrix Users” group, given that this would match the AD group name for all domains). Thus, if we want to provide access to all domain users and we don’t have such a group that contains all the Citrix users, using the Default Authentication Group is the option.
    • Default Authentication Group: This option allows mapping the session policy to any user that can authenticate within the domain instead of having to define a custom user group.
      • To configure this, a Default Authentication Group that identifies the domain would be added within the LDAP authentication profile of each domain. This Default Authentication Group is known only to NetScaler and does not have to exist in Active Directory. After a user successfully authenticates with that authentication profile, NetScaler adds the configured Default Authentication Group to the list of user groups for that user during the user’s session.
      • As before, AAA groups would then be configured to match the name of the Default Authentication Group, and the appropriate session policies would be mapped to each AAA group.

Key Takeaways

Below are some key takeaways from the session policy options discussed.

  • To simplify session policy configurations for multi-domain environments, a single session policy can be configured to pass the UPN attribute to StoreFront instead of sAMAccountName. However, this option relies on UPNs being configured correctly across domains.
  • If using UPN for StoreFront is not an option, multiple session policies can be configured with distinct SSO Domains to pass to StoreFront based on either AD groups or the domain against which users authenticated.

That’s all for Part 2. In Part 3 of this series (coming soon), we will be covering configuration options for direct connections to StoreFront in multi-domain environments.