In Part 1 and Part 2 of this series, we discussed authentication and session policy options for NetScaler Gateway in multi-domain environments. In this final installment of the series we will cover multi-domain configuration options for direct connections to StoreFront. As in Part 2, the same list of topics mentioned in Part 1 that will not be covered in the series apply to this article.
Direct StoreFront Authentication
For internal connections to StoreFront, the design considerations are similar to those with NetScaler Gateway: Single store vs. multiple stores, how to map domains to specific stores, how to tell StoreFront the domain to which it should authenticate, etc.
The primary choice when it comes to authentication is whether or not StoreFront will be performing authentication directly against the various user domains or whether authentication will be delegated to XML.
If StoreFront will be performing user authentication directly against Active Directory, which is always preferred as a better security model if possible (if StoreFront has a domain trust relationship with all user domains), then administrators should determine whether a list of defined Trusted Domains will be configured or not.
If no Trusted Domains are configured, users from any domain with which StoreFront has a trust relationship will be able to authenticate. In this scenario, users will have to enter their domain as part of their credentials, either using “domain\username” or UPN.
If Trusted Domains are configured, only users from the listed domains can authenticate into StoreFront. With this option, you can either still have users enter their domain (or UPN) as part of their credentials, or you can add a domain dropdown menu by checking the “Show domains list in logon page” checkbox as shown below.
Note that the pre-populated domain drop-down list is not possible without configuring a list of Trusted Domains. Also note that if Trusted Domains are configured with no dropdown list, the trusted domain specified should match the format in which users will enter their username (i.e. if users will enter <domain>\<username>, the <domain> must be listed, whereas if users will enter UPN, the FQDN of the domain must be listed).
If StoreFront resides in a domain that does not have a trust relationship with all user domains, or if StoreFront is not joined to a domain, then authentication must be delegated to XML. When this option is configured, StoreFront does not attempt to authenticate the user against Active Directory. Instead, StoreFront delegates the authentication request to a configured list of Delivery Controllers. This option is available via PowerShell in StoreFront 3.0 and newer, and via the GUI in StoreFront 3.5 and newer with the following considerations:
- For StoreFront 3.0 and 3.1, this option is only configurable via PowerShell and applies to an entire Server Group (i.e. only one list of XML servers for authentication applies to all Stores).
- For StoreFront 3.5 and newer, this option is configurable via the GUI and at a per-Store level (i.e. a different set of XML servers for authentication can be configured for each Store).
- The list of Controllers configured for authentication is independent from the list of Controllers configured for XML.
- If multiple Controllers are added to the list of Controllers for authentication, StoreFront picks a Controller in a round robin manner (i.e. if adding Controllers from multiple domains, StoreFront does not intelligently pick a Controller from the domain where the user belongs to).
- Once a list of Controllers is configured for authentication within a Store, this setting applies to all password-based authentication methods (username and password, pass-through from NetScaler Gateway, and HTTP Basic).
- If XML authentication is configured, the username within the Receiver for Web page will appear as <domain>\<username> instead of the user’s full name.
From the list above, the key factors that may impact a multi-domain design are the facts that the Controllers for XML authentication are configured at a per-Store level and that StoreFront picks one Controller from the list in a round robin fashion. Therefore, if you have XenApp or XenDesktop Sites configured in different, untrusted domains (where not all domains have a trust relationship with all user domains), a separate StoreFront Store (which can reside within the same Server Group if using StoreFront 3.5+) is required for each domain. Note that for StoreFront 3.0 and 3.1, a separate Server Group would be required for this, since the XML authentication settings apply to the entire Server Group.
With this design, each Store authenticates users against one specific domain, and users can be directed to the respective Store based on their domain. There are several ways to this without users having to remember the entire Store path, but we will save that discussion for another blog.
- If StoreFront has a trust relationship with all user domains, authentication against Active Directory is the way to go. Administrators then have the option to configure a list of Trusted Domains, in which case a domain dropdown list can be configured in the StoreFront logon webpage to avoid users having to manually enter their domain.
- If StoreFront cannot be domain-joined or if it resides in a domain that does not have a trust relationship with all user domains, authentication must be delegated to XML. If this is the case and you have Sites in different untrusted domains, a separate Store is required for each domain.
That concludes this blog and series. I hope it helped clarify the different options for those of you out there with multi-domain environments. Until next time!