In my previous document How To: Creating a "Web Mapping" ruleset, I outlined how it is possible to create a ruleset which will assign "policies" (aka URL filtering rulesets) based on group membership in a clean fashion.
In this new document, I will expand on what was demonstrated and use more of the flexability available in MWG7. The new "Web mapping" ruleset will dynamically assign (or set) the "User-Defined.Policy" property based on the name of the current rule. Doing this lowers the administrative overhead of managing the policies and rules, but will increase the complexity and understanding required. This method is very flexible, but is like a house of cards, meaning everything has to be in place in order for it to work. If you remove one piece it could all come crashing down.
There are various other methods for achieving this similar effects as the rule architecture I have outlined here. Here is a few examples of what I commonly see:
I commonly see one-off rules to allow users/groups to specific categories or create a specific whitelist/blocklist. Using this method tends to complicate rules and may lead to inconsistent filtering if done incorrectly.
Criteria for URL Filtering RuleSet is based on User or Group
Another commonly used method is to set the criteria of the "URL Filtering" RuleSet to be "Authentication.UserGroups contains "GROUPNAME"". While this isnt a terrible concept, it can have many pit falls, such as:
The primary goal of this architecture is to consolidate the decision making process for filtering users. Keeping the decision process down to a few RuleSets helps with isolation of problems, and ensures users will be filtered in a consistent fashion. Error handling has also been built into the architecture to help avoid the "why am I not being filtered?!" question from being asked.
The new "Policy assignment" ruleset (formerly known as "Web Mapping") uses some new properties and methodology which make it more dynamic, and make it easier to manage. BUT it adds a bit of complexity.
It is very common for customers to have ranges of IP's for which they do not want to perform authentication. The following ruleset applies the "Policy assignment" concept to lists of IPs or IP ranges.
This is the most common question we get in support, "How can we filter based on groups or users?". There are many ways to accomplish this, but in my opinion, this is the cleanest solution. If used correctly and understood it can be very powerful.
Now that the "User-Defined.Policy" property has been set, we must apply the "URL Filtering" RuleSet based on the "User-Defined.Policy".
In order to ensure user's get filtered, a Default Policy container has been setup. This "catch-all" will accomplish two things:
The default value for the "User-Defined.Policy" is set to "Default". So... if the user does not match on any of the IP or group based Policy assignment rules, they will fall to the "Default" URL Filtering RuleSet.
If you create a Policy assignment rule that does not have a corresponding "filtering" ruleset. Then the user will fall to the Default ruleset. This is acheived by verifying a Policy has not already been applied.
In the event that a spelling mistake is made, or a Policy is referenced that doesnt exist, the following rule architecture will prevent any unfiltered access.
The "Default" Policy uses the "User-Defined.PolicyFiltered" property, to determine if a user was filtered. If the user was NOT filtered by a policy, then they will receive the "Default" Policy.
It would be beneficial to account for possible issues with implementing the Policy Assignment architecture. To do this you could do this in multiple ways.
Block pages are the easiest way to troubleshoot unexpected filtering. You can add properties to the block page which will instantly tell you what policy the user recieved. In addition you can identify what rule/ruleset is blocking the user. The below screenshots show how this can be done.
To troubleshoot any possible policy assignment issues, one could create a log (which should only be turned on for a specific test machine) to determine the cause for an incorrect assignment.
Below is an example of the output for the the log file (it was not blocked):
Time: [04/Apr/2012:19:04:29 -0500]
LastRuleName: Block If Virus was Found
LastRuleSetName: Gateway Anti-Malware
FiredRules: SSL Scanner, Global Whitelist, Policy Assignment - IP...
The entries "LastRuleName: Block If Virus was Found" and "LastRuleSetName: Gateway Anti-Malware" are set because they are the last evaluated rule, NOT because something was blocked. Take note that the BlockID equals 0.
See: Policy Log.xml
The above rule architecture is designed to make administrating the Web Gateway easier. In addition it may consolidate your rules and make them more comprehendible. Once this rule structure is put into place, identifying any user filtering issues should be a breeze .