Welcome to my second blog about global server load balancing, in what now looks set to become a series. Here I present to you “how to direct remote XenApp/XenDesktop users to the correct datacenter based on active directory group membership”.
This is a follow-on article to “Accurately direct XenApp/XenDesktop users to a correct location based datacenter” and although I would ordinarily expect users to be routed to the datacenter geographically closest to them and from there across the business’s MPLS network to wherever their applications or desktops are being provided (Fig. 1.), I appreciate this may not be appropriate for everyone and some of you wish to have control via AD group (Fig. 2.).
It’s worth mentioning from the outset that HDX optimal routing will already allow you to preference gateways on a per farm or site basis. This solution is intended for those of you with a central XenDesktop site running globally dispersed VDAs and a NetScaler Gateway in each location, or a single globally distributed XenApp farm (which I know an awful lot of you still have). If that’s you then read on!
Two separate TCP/IP conversations
First a quick recap of some key points from my last GSLB article
- A connection to NetScaler Gateway is established after DNS-based-GSLB has taken place and involves two separate TCP/IP conversations between the endpoint and the NetScaler. The first authenticates the user and carries StoreFront traffic, and the second contains ICA traffic (Fig. 3.).
- It is possible to introduce logic within the first conversation to performing a secondary level of load balancing (beyond that of NetScaler’s DNS-based-GSLB alone) and thereby redirect the second conversation to a different gateway than the first.
- Global STAs are required if the two conversations go via different NetScaler Gateways, this is so that a user who has authenticated on the first will be known to have authenticated when arriving unannounced at the second.
Directing users based on Active Directory Group Membership
Now that’s out of the way, lets focus on our goal – today we want to introduce logic which directs the second TCP/IP conversation (containing the ICA traffic) to a different NetScaler Gateway based on the user’s active directory group membership. As the destination of that second conversation is a FQDN defined by StoreFront within an .ICA file, which the endpoint will download, we will need to cause StoreFront to populate the file with a different FQDN and unfortunately that’s not an “out-of-the-box” option.
We could of course create this functionality with another StoreFront extension using the excellent SDK but wherever possible I like to do interesting things with the tools already available, and in this case it’s actually possible (though a little complicated) to achieve our goal using NetScaler and StoreFront configuration alone, let me explain further.
StoreFront configuration
Recent releases of StoreFront can identify the NetScaler Gateway that’s connecting to them based on the SNIP (subnet IP) of the incoming connection, and having determined the gateway can populate the .ICA file with that gateway’s FQDN. The two StoreFront servers shown in Fig. 4 would be able to differentiate between the three NetScaler Gateways through which clients can connect, and based on the SNIP of each gateway it would be possible for StoreFront to correctly populate the .ICA file with the FQDN of the relevant gateway.
Using the same logic, if one NetScaler Gateway were to connect to a StoreFront server and originate connections from a number of different SNIPs, for example one per Active Directory group, it would appear to the StoreFront server as if clients were connecting through multiple gateways. This logic could then be used to populate an .ICA file with a different gateway FQDNs based on Active Directory group membership and thereby route the second TCP/IP conversation elsewhere.
Such a setup can be achieved by configuring NetScaler with multiple load balancers each with separate NetProfiles (Fig. 5.).
Causing NetScaler to make decisions based on group membership
Having established that our goal is possible, by using multiple load balancers each with a separate NetProfile, we must now consider how we will cause NetScaler Gateway to use these load balancers based on the Active Directory group membership of the user.
During logon NetScaler Gateway enumerates the Active Directory group membership of the user and we can use this information for policy decisions by creating AAA groups with identical names to those of the AD group. Using a unique session policy and action for each AAA group, with these policies having a lower numerical priority than the vServer’s session policy so that they will take precedence, we can specify a different StoreFront load balancer be used for each AAA group.
Illustrating the expected behavior with a highly simplified diagram
In the diagram (Fig. 6.) we see a client connecting to NetScaler Gateway for the first conversation, an authentication process including group enumeration being run against Active Directory, the process of checking for AAA group membership occuring and in this example “Users in the USA” matching the case-sensitive name.
Session policies bound within the AAA group called “Users in the USA” will now be considered alongside session policies bound to the NetScaler Gateway vServer. A session policy with a lower numeric priority called “Users in the USA policy” will apply and trigger a session action called “Users in the USA action”. The action will direct NetScaler Gateway to a specific load balancing vServer with NetProfile bound causing traffic to originate from a unique SNIP.
With all users within the “Users in the USA” Active Directory group coming from a specific and unique SNIP, the StoreFront servers, seeing a connection from a SNIP defined within their configuration as a unique NetScaler Gateway would populate the FQDN within the .ICA file with the text string entered for that gateway. In our example this might be the FQDN for the New York NetScaler Gateway and not the one the user is actually connected to.
With the .ICA file populated with an alternative FQDN based on AD group membership we have successfully redirected the remote user to an alternative datacenter and it is to that destination the second TCP/IP connection containing his ICA traffic will be sent.
We can also see from the diagram and accompanying policy of tables that users who do not match any AAA / Active Directory group name would hit the “Default / Users in the UK policy” and could receive a default response from StoreFront, for this reason only those users who require special datacenter routing rules would need the configuration described here.
For reference this simplified diagram uses one VIP for NetScaler Gateway, three VIPs for load balancing vServers, and three SNIPs for the outbound traffic to StoreFront. The SNIPs are assigned one per load balancing vServer using NetProfiles.
We have now seen how StoreFront can be configured to return different gateways within the .ICA file based on the incoming SNIP, and how the incoming SNIP can be changed within NetScaler based on Active Directory group membership. This combined configuration allowing the direction of remote users based on Active Directory group membership.