Netscaler, with is Access Gateway Enterprise Edition (AGEE) functionality, allows you to publish resources to users, such as shares and access to internal web sites, when they are connecting externally to the network. These may include shares which are user specific. Publishing such items is relatively easy; simply create a bookmark that connects to \LocationOfResource%username% for later editions of AGEE or \LocationOfResources#<username> for earlier editions. However, what if the resource is held in a location that depends on the users membership of a department ? For example, finance department home drives are held on one server and sales department home drives are held on a different server ?

Similarly, that should be relatively easy. AGEE will extract the users group membership and you can simply publish the resource to that group on the basis that most administrators create Active Directory groups to represent a department in the organisation. To do this, access the policy manager in the “Access Gateway” node of AGEE.

Right click the Groups node under Configured Policies / Resources and select “Add”.

Then simply enter the name of the Active Directory Group (case sensitive).

Click on create and the group is added. You can then just create a bookmark and drag and drop it on to the group to publish that resource to that group. This works fine if the user is a direct member of the group that has the resource published to them. For example, if the group is “Sales” and the user is a member of “Sales” then they will be able to access the resource.

However, what happens if the user is not a member of the group Sales, but a member of a sub group, for example MajorAccounts ? In this case the user will not be able to access the resource. To overcome this we could just create a group for each resource and add users to each of those groups but for larger organisations that would be an administrative nightmare. Instead, we can use nested group extraction to find the ancestors of those groups which the user is a member of. That is, if the user is a member of the MajorAccounts group and this group is a member of the Sales group then they will have access to any resources published to the Sales group.

Configuring nested group extraction is quite simple. We simply amend the authentication server attached to our policy to enable nested group extraction. For Windows Active Directory the settings are as below:

NOTE: The Maximum Nesting Level setting determines how many levels “up” will be checked. The more levels checked will require more resources form the Netscaler which may have an effect on the scalability of the solution in large, busy deployments.

Now, this is all well and good when it works. But what if it doesn’t ? There is a caveat to this working which is not mentioned in the AGEE documentation. The search scope of the authentication policy must also include the location in Active Directory where the groups are held. For example, if the LDAP server object used by the authentication policy is scoped to the whole domain then all will be fine.

The issues with this is that, technically, this will allow any account within Active Directory to be authenticated, including service accounts and other accounts with Administrative privileges. If these accounts are compromised then, in the case of administrative users, they may also have applications published to them via XenApp which an attacker could utilise. One way to overcome this would be to not publish those applications if an Access Gateway connection is used which is easy enough to do by clearing the appropriate check box in the application properties in XenApp. Far better to never allow logons from those accounts in the first place.

This can be achieved by placing all of the users in a group and scoping the authentication to that group using a search filter. For example, we can create a group call Remote Access and add all the user accounts we want to be able to log in to that group. An example of a string for a search filter is given below:

Again, this is all well and good and easy to set up if you have a discrete set of users you want to grant access to. If it’s every user except administrative accounts then you have to remember to add the user account each and every time a new person joins the organization which is almost certain to fail on occasion. Even worse, if you have a tool for creating user accounts, such as when thousands of students enrol at the start of a new academic year, then this again increases administrative overhead, risks calls being raised where users aren’t added in or requires a re-write of the user creation tool. So, wouldn’t it be nice to use existing groups (departmental groups for example) and add those sub (departmental) groups into this group which grants rights to log on remotely ? That way, you can continue to use your user creation deployment tools and automatically grant these non-administrative accounts the rights to log on when working externally.

Unfortunately, that doesn’t work ! It only works where users are added directly to the group being filtered on, not where the membership of this group is other groups rather than the user accounts themselves. What can be done ?

The solution is to remove the search filter above but only allow certain user groups to log on. To do this we revert the above settings so that our authentication server will have settings as below:

This essentially grants remote logon rights to all users, including administrative accounts. We limit this behaviour by accessing the profile for the session policy applied to the authenticating users. We open the policy manager once again in the “Access Gateway” node of AGEE.

We access the session profile and choose to modify the Request Profile.

On the Security tab of the profile, click on the Advanced link.

Enable the Groups Allowed To Login section and add the name of the group we want to be able to login.

Above I have created a single group and nested sub groups within that group within Active Directory. In the example above, the Remote Access group contains the Sales group. This Sales group in turn contains the sub-groups holding the user accounts such as MajorAccounts, NorthernSales, SouthernSales, EMEA etc. I have also configured Nested Group Extraction as above. Now, if a user is a member of one of the nested groups they are allowed to login. This allows us to scope the search at the root level and thus ensure that all groups (for publishing resources) are within the scope of the search. This civers the situation where thereis a “flat” Active Directory structures where there is no single Organizational Unit which groups together user  group OUs to allow us a common point of entry to conduct searches. As we can now extract nested group membership we can publish resources based on that group membership while restricting logins for administrative accounts and removing the administrative burden of having to individually add users to a group just to allow remote access.

Note: If you prefer, multiple groups can be added to the above field by separating the group names with comma’s.

If you want to troubleshoot nested group extraction, or at least check that groups are being assigned to users, you can use the built in Netscaler tools to monitor the logon process. To do this create an SSH connection to the active Netscaler device using your favourite client, Putty for example. Once you have logged on using the nsroot (or similar) credentials, connect with the operating system shell by typing in shell and pressing return. Then enter the command cat /tmp/aaad.debug and press return.

This will show the debug log for logons. Log on through the AGEE logon page, output similar to the below will be created:

In the example above, the user is only in the ITServices group. This is a nested member of the All Staff group which is itself a member of the Remote Access group. If you cannot see the enumerated ancestor groups (or sufficient groups) then either nested group extraction is misconfigured or you may need to increase the number of levels enumerated.