We have three different features that we have gone through, and each of them gives us some functionality, for example, whether we want all the different features to be available to the user at the same time and give the users the option to choose between different features.

If we want to have a single web portal where we want to give the users the ability to choose the kind of resource they need, we need to make a change to the default session policy that they use. Under Session Policy, go to the request profile that is bound to it and then click on the Client Experience pane. Here, click on the Advanced button. In the menu, we have an option called Client Choices. By enabling this, the users will get an option to choose what type of feature they need when logging in to the web portal, as shown in the following screenshot:

The options presented here are dependent on what is configured in the session policy. For example, if Clientless Access is not defined, it will not show up as an option here. If we have not entered a web interface address and STA is not available, Citrix XenApp will not show up as an option. Lastly, if we have set the vServer to basic mode, it will automatically go to the StoreFront server after authentication. Another option we have is to use expressions. We can use expressions to filter sessions based on user agents, IP addresses, and so on. For example, we want to create a dedicated session policy to be applied only to Android devices and the default session policy to be applied to all other devices that are connecting. For Android devices, the following CLI expression declares that the connecting client must have a user agent string, which contains Citrix Receiver and Android:

REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver&&REQ.HTTP.HEADER   User-Agent CONTAINS Android/

Then, we create a custom session policy that is bound to that expression containing the specific configuration for our Android devices. We then use the general ns_true expression to apply to the rest and bind a session policy for the rest of the devices. Also, remember that the Android policy needs to have a lower priority than the other one, as ns_true applies to all clients that are connecting to the vServer.

One last feature that we can use is filtering based upon the AD group. For example, we want users who are part of the executives group to gain access to everything in the corporate network and the regular users to gain access to some of the network. The way this operates is that when a user connects to the web portal, we can use NetScaler to get the list of the AD groups that the user is a member of from Active Directory, and find the first policy that is bound to one of the AD groups. It is important to note that user policies are processed before vServer and global policies. Therefore, if we have two session policies—one bound for the vServer and another for a user group—the user group policy will win.

In order to use this feature, we must first enable the authentication policy to get the list of the AD groups that the user who is connecting is a part of. This can be done by making sure that the memberOf attribute is entered in the authentication policy in the Group Attribute field. This is shown in the following screenshot:

After that is done, we need to go into the Policy Manager to create the AD groups. This can be found in the NetScaler Gateway pane. Here, we must first create a group under AAA Groups. The group name must be identical to the group name in the AD. Now, we can start by clicking on the + sign and then assign policies to the group. The policy should then appear as shown in the following screenshot:

Here we can define different session policies, audit policies, and for instance, intranet IP policies based upon an AD user group, which makes it a lot easier to scope rules to different departments.