The Umbrella dashboard contains powerful tools to manage your settings across Identities. The Policy Editor is one of these tools that allows the customization of per-identity filtering and security settings. While any identity can be added to any policy, the settings that apply to the end user will result from policy precedence rules.
In general, the topmost policy in the list that is added to an end user will apply. However, this gets more complex when a user has multiple identities such as the Umbrella roaming client and Active Directory (AD) identities.
If an identity has no matches in any custom policy, the identity will apply to the Default Policy. If you'd like to find out which policy is matched for a particular identity, read this article on our Umbrella Dashboard Policy Tester (located above the policy editor on the dashboard).
Policy Precedence: Identities
When choosing which identities belong to a policy, the list of added identities appears to the right of the Identity Chooser. When the entire category (i.e. AD Users, AD Groups, Networks, etc.) is chosen, a check mark appears. When only some of the categories (i.e. specific AD User(s), AD Group(s), Roaming Client(s), etc.) are chosen, a dash appears. If you are viewing a nested identity set and see a grayed-out check mark and wish to modify the sub group, go up a level and ensure that a blue check mark is not present.
Each policy has the option to select any combination of Identities.
For example, "Joe", a user in Active Directory, can be added to several different policies as an individual user, and can be included as part of any policy with "All AD Users."
Since "Joe" can be included in several policies, it's critical to understand the order in which those policies are applied to "Joe." A common misconception is that policies are additive, and by creating a "YouTube Policy" and "Facebook Policy" and adding Identities would allow all checked Identities to access these sites. This is not the case!
Policies are applied based on a "first match" methodology based on rank (the number listed at the left of each policy), which follows a top to bottom execution order. Therefore, only the highest ranked policy that matches a user's Identity will be applied, and all subsequent lower ranking matches will be ignored.
In the example provided below, we've set up a sample Identity: "Admin Adminson", an AD User. In this case, there are two policies: a rank 2 policy that applies to all AD Users (AD Users), and a second policy (rank 3) that is more restrictive and only that applies to the specific user "Admin Adminson." Since the AD Users policy is the first match in the execution order because it is the highest ranking policy of the two, it will be applied and the Restrictive Policy match will be ignored.
The goal of the Restrictive Policy in the above example was to set up the "Admin Adminson" Identity with more strict filtering than the other users, but it was not correctly ordered. Note that this will apply to Roaming Clients and Networks as well. To apply a specific policy to this user, the order of the policies will need to be updated. In this case, the Restrictive Policy needs to be moved higher than the AD Users policy. How do the policy orders get changed? Read the next section to learn how!
Configuring Policy Order
Policy order is modified via drag and drop operation using the "handles" along the left-hand side of each policy bar (see animation below). This will allow the policies to be rearranged to the desired order.
Identity Precedence Within the Same Policy
For details on which identity is logged as the final matching identity when more than one Identity share the same policy, see our same policy stats identification guide here. For example, if a user is on a registered network but also has a Roaming Client installed or if there is an AD computer, AD user, and internal network applied to the network the user is on - which applies in the reporting?
Policies and Block Page Bypass (BPB)
Policy precedence also has an impact on using bypass codes and bypass users. Since the enabling of BPB codes and users is per-policy, if your bypass code isn't working or the "Admin" bypass link isn't appearing, check that the code/user is enabled for their policy (as seen in the screenshot below, an example of a code not enabled). To enable a code or user, check the box next to the code or user, then save the policy. To confirm a user is hitting the policy expected, use the Umbrella Dashboard Policy Tester (located above the policy editor on the Dashboard) to confirm you're setting up a code to be active on the expected policy.
Confirming with the Policy Tester
Once policies are configured, before testing in the field also test policy application with our policy tester built into the Dashboard. For more detailed instructions, read on at our guide for the Umbrella Dashboard Policy Tester.
Below is an example of the use of the Policy Tester.
- Fill in the expected identities. For example, the AD user and AD computer (if you're using a VA and AD integration), Internal network, Roaming Client, and/or public network.
- Enter a domain to test.
- Click Run Test and take a look at the results. This will outline which policy applied as well as any other policies which also matched, but were of a lower policy rank and were therefore not applied.