Administrators can bind a session policy to different bind points on the Access Gateway Enterprise Edition. There are four possible locations for binding a session policy:

• Global

• Virtual Server (vserver)

• Group

• User

 

Internal priority for different bind points

Administrators can assign priority (with lowest number referring to highest priority) when binding the session policy. There is an internal priority set to cater to a session policy bound to different bind points with the same priority. The internal priority is as follows:

1. User (has the highest priority)
2. Group
3. Virtual Server
4. Global (has the lowest priority)

Instructions

How to determine the effective session policy

Administrators can determine the effective session policy based on the following:

1. A complete session policy comes with a group of parameters (such as split tunnel, single sign-on, and split DNS). Access Gateway Enterprise Edition evaluates the bound policies based on the priority to get a final effective policy for the user.

2. The parameters from the session policy with the highest priority (lowest number) regardless to the bind point will be taken into effect. That means all parameters defined at that policy will be in the effective policy set.

3. In case there is a tie in priority on different bind points, the internal priority (User > Group > Vserver > Global) kicks in.

4. Parameters from the second highest priority policy are put into the effective policy set, except those being applied in step 2. In other words, once a parameter has been put in the effective policy set, it is not affected by a policy with lower priority.

5. Again, the internal priority (User > Group > Vserver > Global) kicks in when there is a tie.

6. Steps 4 and 5 repeat until all the policies are considered or the effective policy set has all the parameters defined.

7. For parameters not defined from any of the policies, global Virtual Private Network (VPN) settings apply.

Examples

Two examples demonstrate session policy on different bind points.

Example 1 – Policy bound to group level has higher internal priority than vserver level

In this example, there are two policies involved. The first policy is called sg_policy. A user hitting this policy receives secure gateway mode access (ica proxy on). The other policy is called client_choice_policy. A user hitting this policy receives a choice of selecting to use the secure gateway mode or to launch the SSLVPN client to get a full VPN mode.

Configuration of this example:

add vpn sessionAction sgmode -SSO ON -icaProxy ON -wihome http://192.168.1.180/Citrix/AccessPlatform -ClientChoices OFF -ntDomain HKSUPPORT

(A session action called sgmode is created with the URL for the Web Interface, turning the icaproxy to on and setting the NT domain. The client choices option has been turned off as well.)

add vpn sessionPolicy sg_policy ns_true sgmode

(A session policy called sg_policy is created and the session action bound to it is called sgmode; that is the session action created on the previous command.)

bind vpn vserver sslvserver2 -policy sg_policy

(There is a VPN vserver called sslvserver2 and the session policy sg_policy is bound to it. Since there is no priority configured on the bind command, the default priority 0 will be applied. In addition, assume no other policy has been bound to this vserver.)

add vpn sessionAction client_choice -windowsClientType AGENT -SSO ON -icaProxy ON -wihome http://192.168.1.180/Citrix/AccessPlatform -ClientChoices ON -ntDomain HKSUPPORT

(A session action called client_choice is created with client choices turns on, URL for the Web Interface URL and NT domain.)

add vpn sessionPolicy client_choice_policy ns_true client_choice

(A session policy called client_choice_policy is created and the session action bound to it is client_choice which was created with the previous command.)

bind aaa group "Domain Admins" -policy client_choice_policy

(The client_choice_policy is bound to the group called “Domain Admins”. Without configuring the priority, default priority 0 will be applied.)

The rational of this example is all the users accessing the VPN vserver called sslvserver2, except for those in the “Domain Admins” group, are granted the secure gateway mode access. For users in the “Domain Admins” group, a choice is given for them to select secure gateway mode or full VPN mode. This is because, although both sg_policy and client_choice_policy are bound with priority 0, the client_choice_policy is bound to the aaa group, which has a higher internal priority than the vserver.

Example 2 – Policies with different priority across different bind points

For simplicity, the same session policies from example 1 (sg_policy and client_choice_policy) is used. Refer to example 1 for the parameters assigned for these two policies. However, the bind point and binding priority are different. Below is the configuration for how the policies are bound:

bind vpn vserver sslvserver2 -policy client_choice_policy -priority 20

(The policy client_choice_policy is bound to the vserver called sslvserver2 with a priority of 20)

bind vpn global -policyName sg_policy -priority 10

(The policy sg_policy is bound globally with a priority of 10)

With the policies bound in this way, the parameters from sg_policy are always in the effective policy because it has a higher binding priority (10 < 20) compare with the policy client_choice_policy. Even though client_choice_policy is bound to the vserver level which has higher internal priority than global level, sg_policy is still used first because explicitly configured priority is considered first. As a result, all the users receive secure gateway mode and no one can receive the client choice option. This example shows that poorly arranged priorities across different bind points can cause policies to be overridden. Administrators must pay attention on this situation.