Default NetScaler changes

When deploying a NetScaler, Citrix recommend that you make these changes by default ( ).

The Windows Scaling one was particularly useful on a customer site recently where connections over CAG would drop due to window size on the TCP stream not being negotiated with the ASA filrewall correctly. Enable windows scaling and the issue went right away.

Explanation of what re-arming a Microsoft operating system is all about

Very good piece in one of the Citrix VDI in a box best practice articles at

VDI-in-a-Box 5.1 offers a new setting at the template level to reset the activation timer. Leaving this unchecked implies that the image’s activation clock is not rearmed during prepare. Checking the box implies that the image’s activation clock is rearmed during prepare, decrementing the activation count. If the image’s activation clock is rearmed more than 3 times before the image is activated by KMS (Microsoft activation Key Management Service), the image cannot be prepared because the /generalize will fail.


According to Microsoft: “Resetting the activation timer prevents the image’s grace period from expiring before the image is deployed. Running Sysprep.exe does not remove the installed product key, and administrators are not prompted for a new key during mini-setup… When building demo virtual machines (VMs) for internal use (e.g., building VMs for the organization’s sales department or to set up a temporary training environment), running the Slmgr.vbs script with the /rearm command-line option extends the grace period another 30 days, which in turn resets the activation timer but makes no other changes to the computer. The activation timer can be reset three times for computers running Windows 7 or Windows Server 2008 R2.”

GSLB Site IP Already Exists

So, I’m building a Global Server Load balancing solution based on NetScaler and I made a mistake entering in the IP address for the local GSLB site. I deleted the site and then went to create a new local site but whatever I do the site creation fails with the following error.


It turns out that, when the site is created NetScaler records the GSLB local site IP in its list of IP addresses. The RTM version of NetScaler 10.0 (build 54.6) has a bug in that it doesn’t delete this IP address.

Bacause a Global Site IP already exists, you cannot “add” another one. So, if you need to change the IP address used for the local GSLB site, you just need to delete the IP address recorded here and you are good to go. The other choice it to update the firmware to the current version as this bug is fixed in build 54.7.


Default URLs and Passwords for Citrix VDI in a Box

Access Gateway Enterprise Edition Nested Group Extraction and Publication of Resources

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.