Showing results for 
Show  only  | Search instead for 
Did you mean: 

How To: Creating a "Policy Assignment" ruleset (formerly "Web Mapping")


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.


Other methods (and their pitfalls)

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:


User or Group based rules within the URL Filtering RuleSet

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.                 

user or group.png

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:

      1. If user is apart of multuple filtering groups, they will get filtered twice
      2. Decision making is broken up and may create inconsistent URL filtering




Goals of "Policy Assignment" architecture

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.



  1. Authentication must be setup on the MWG in order for group based rules to work (not required for IP based rules).
  2. You should have read the original document How To: Creating a "Web Mapping" ruleset, this outlines fundamentals behind the concept.


What's New

  1. To make the rules more dynamic, the criteria and events are based on the Rule name or RuleSet name. This is very important to recognize!
  2. The properties referenced are "Rules.CurrentRule.Name" and "Rules.CurrentRuleSet.Name".
  3. A new  "Policy Assignment" RuleSet for IPs has been added to demonstrate other use cases and flexibility of the Rule Engine.


Policy assignment ruleset (aka Web Mapping)

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.


Policy Assignment (based on IP)

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.


Methodology to understand

      • The "User-Defined.Policy" is set based on the Rule name.
      • "Authentication.IsAuthenticated" is set to "true" in order to exempt the IP addresses from Authentication because only non-Authenticated clients should be authenticated (under default rules).


1_2_2012-04-04_112852.png 10_2_2012-04-04_182051.png


See: Policy Assignment - IP.xml


Policy Assignment (based on Group/User list)

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.


Methodology to understand

      • Rule name, is equal to the group name you wish to filter based on.
      • Alternativley you can add users to a list, and they will also match.
      • "User-Defined.Policy" is set based on the in the event.
      • Rule event stays the same, the Rule name and the User list criteria should be changed if you need to duplicate the rule for new policies.





See: Policy Assignment - Group_Users.xml


Policy ruleset(s) for URL Filtering

Now that the "User-Defined.Policy" property has been set, we must apply the "URL Filtering" RuleSet based on the "User-Defined.Policy".


Methodology to understand

    • URL Filtering ruleset will only match if the "User-Defined.Policy" property equals the RuleSet name.




See: Static - URL Filtering - Policies.xml

Understanding the "Default" Policy container (catch-all)

In order to ensure user's get filtered, a Default Policy container has been setup. This "catch-all" will accomplish two things:

  1. Apply a "Default" Policy to any users that have not explicitly been assigned a policy
  2. Account for misconfiguration or spelling mistakes in rules


"Default" Policy assignment

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.




Accounting for misconfiguration

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.




Building a dynamic URL Filtering RuleSet

Coming soon...



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.


Modify the blockpages

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.


9_2012-03-28_185917.png 10_2012-03-28_190609.png


Create a policy assignment log

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.


12_2012-04-04_193156.png 5_2_2012-04-04_115648.png


Below is an example of the output for the the log file (it was not blocked):


Time: [04/Apr/2012:19:04:29 -0500]





StatusCode: 301

BlockID: 0

Policy: Servers

WasPolicyFiltered: true

DoesPolicyExist: true

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 .

Labels (1)

If a user is member of two AD groups that match to a general policy use for mostly everyone and a policy for someusers only (a URL category not in the general policy for example), will this setup allow access to both policies for this user?


I dont quite understand what you mean. But, this architecture is meant to prevent "double-filtering". So if a user is apart of groupA and groupB, you get to decide which one has higher precedence. You decide by ordering your "Policy Assignment" rules accordingly. Does this help?


Yes, this is what I was reading from your document.  Thank you


John great read- is there a way to modify a Policy Assignment to filter by subnets vice Group_Users\IP's?  We have some users in APAC who require additional blocks due to government guidelines.  How can this be achieved?


Hi Carlos! You can do this using the rules I have above. Take a look at the first screenshot, the criteria is "Client.IP is in range list "Server IP Ranges".

Please let me know if I misunderstood your question.


Were you able to figure this one out Carlos?


Not really John-

For our company , due to geographical location and lack of IT Staff at these regions, the goal is to enable NTLM authentication for each region at a time based on subnets rather than bulk push.  This approach would allow us to test the region\ fix or modify policy \ troubleshoot\ etc.  and move on to the next region.   This approach less burdens our HelpDesk with calls.

e.g.  Mexico location has 5 floors each on several different subnets on each floor.  So we would work on users on 1st Floor - 10.13.xx.xx/xx- & 10.14.xx.xx./xx-  we would deploy NTLM authentication  \ test policy - modify if necessary \ , etc. etc .etc

Hope this makes sense.


Great Article!

I don't know if this is assumed knowledge, but maybe you can cover how to handle individual exceptions within this policy structure.

For example, a member of the Internet-Strict group needs to be granted access to Facebook.  I'm assuming you would just create an exception rule within the rule set, but this might be helpful to include anyway.


Question: if you're using AD domain groups for policy assignment/matching, do you need to include the domain in the name?  So for your example, the rule set name would be "DOMAIN\Internet Strict"?

It doesn't seem to work for me when I don't include the domain name.


There is an option in your authentication settings that says "include domain name in group names", you must have that checked.

Good rule of thumb, however the groups appear in the authentication test, is how you need to enter them in the group related rules.




Great article. I am following your methodology. How and where can we add exceptions for users who are part of a group (eg. Internet Strict) like the below

1) a goup of users belonging to different AD groups require access to specific site to upload and download that is blocked

2) a user requires access to a blocked site

3) a user requires access to upload to a blocked site

How can we best put this in the above mapping.

I created a rule called User Exceptions which checks a list containing a list of users having exceptions. Requests, responses and embedded are enabled. But is this the best way to implement?


We had the exact same scenario as you did.  There are multiple ways to do it,  but here's how we did it.

1.  I stopped using AD groups.  I didn't like having to look in 2 different places to see what exceptions we had.  So I made all my groups in MWG7 instead.

2.  Next, we would create rules with exceptions either for a specific group of users or a specific group of websites.

3. Since we had several rules, I separated the upload exceptions from the URL exceptions for ease of management.  So in your case, here's how our policy would look:

  • Internet Strict - Upload Exception
    • URL Exception: AD Group1
    • URL Exception: User 2
    • Block All Rule (For Restricted Categories)
    • [Sub Rule Set] Internet Strict - URL Exceptions
      • Upload Exception: User 3
      • Block All Rule (For All Uploads)

Hopefully it's clear.  Let me know if you have any questions.


Thanks for posting this. What this shows is how powerful the rule engine can be. However, I think this approach is not very flexibel when it comes to merging access rights for users who are in multiple user groups, and it seems to complicate things if you need to make exceptions and whitelisting. More powerful != always better. What is wrong with the first two approaches that are specified in the "Background" paragraph? You rule them out because they tend to be error prone, but isn't the other concept just as error prone?

I would be interested in hearing your thoughts about this.

Also, what's with that dynamic URL Filtering Rule Set?


Hi cc,

Thank you for your questions!

You are correct. This architecture does not do this (merge access rights for users in multiple groups), nor did I intend it to.

This architecture was meant to bridge the gap between Web Gateway 6 and Web Gateway 7. As such, it assumes that you would like to assign a single policy for a specific group (as was done in WG6). SmartFilter did have this kind of structure, and I had a conversation with one of my proserve colleagues about this, but had not seen it in the wild yet.

While this may not be the most flexible method, it does allow for consistent filtering (making sure that everyone is accounted for accordingly), and is done cleanly (so you can look at the ruleset and understand what is attempting to be accomplished).

For these reasons I feel that this approach is better; the rules are easier to understand. I've seen a lot of configurations and a lot of them lumped all of the group/user based rules into a single ruleset, so when something went wrong, it was a usually a guessing game (for the customer) as to what rule was actually matching. In addition to the rules being easier to understand, the ruleset architecture above allows for error, but it does it safely. If you dont match on the correct policy you WILL fall to the default policy. This makes things much more evident as to where the problem lies (with policy assignment). Whereas with a ruleset with all of the rules in one, if something goes wrong, there could be any number of different results (i.e. a user could get allowed to everything, or they could get blocked for everything). This ruleset minimizes the number of outcomes.

As for the "dynamic filtering ruleset", this was something I was going to expand on if there was interest. It basically entails use of the referencing lists by name (instead of statically). Thereby allowing you to simply create a single ruleset for all of the policies, and only requiring the lists to be referenced in the ruleset. However this dynamic way of referencing lists is not without it's pitfalls, therefore it ineeds a rigid structure otherwise everything could fall apart.




Thanks Jon for the detailed response. I really like your approach, I just feel it might trap me one day into a very static ruleset that does not allow me to make flexible exceptions (like whitelisting stuff or put users in more than just one policy). We are currently in the process of migrating our existing WW6 deployment to MWG7. Your approach would basically allow me to replicate what we had on Webwasher, which is nice. I am undecided now

Is it possible to mix and match this with "classic" User/Group based rules or would you advise against doing that? I figure I could use your approach for 99% of all my needs, but for that 1% that needs "special handling", I would use User/Group based rules in addition. What do you think?



This approach does assume that you want users to get one single policy. So you will be trapped in that 😉

If you want to have a discussion about it, feel free to give a call in or open a SR and ask it be assigned to me (you can list the SR # here).

After we talk we can post our result here.




Thanks Jon, I really appreciate that. I might come back to you once we have a clearer picture of how we want to go forward with MWG7. Maybe a single policy per usergroup will be enough. Goog to know though that I can discuss this further with you!




Hello Jon ! Many thanks for this documentation it was very helpfull. I tried to modify the blockpages but I cant add the $User-Defined.Policy$ variable... I have no problem to add the two others... Do you have any clue to solve it ?

Thanks in advance

Best regards,



You have to add another NON-user-defined property, you can then edit it, to use a user-defined property.




Jon, I really like this aswell, because it makes it clean and easy to follow. One question. We have alarge environment, were we have say 8-10 sub organizations that will be usingthe same MWG's. They more than likely will want some of their own policies.

Would it be better to createdifferent russets/groups for each organization and make the criteria forthat ruleset that Organizations IP range ( we have to use IP) and then create aweb mapping , URL filters and white list in that ruleset, for that organization?That would have to be created 8-10 times,  for each organization. Pretty much just whatyou have here but 8-10 times. I have also thought about making a master mappingthat used a user-defined property like organization and assigning the property tobe named by each organization then still doing a separate policy filter(Relaxed, restricted etc) for each organization after they have been tagged inthe higher level mapping that mapped them to their specific russet. 

As well as leaving a defaultpolicy at the every bottom for anything that does not get filtered in any ofthose origination level mapping and filters. Not sure if you can follow mythinking. Or maybe have a suggestions. Any suggestions on how handling severalorganizations  would be great.


Hi Jon,

I have followed your tutorial as exactly written by you but in the end it failed.

This is real case scenario..

There are 2 groups , authenticated with NTLM.

1st Policy assignment: General  (Events: equal to General)

2nd Policy assignment: Internet (Events; equal to Internet)

3rd Default policy assignment (if not authenticated or not belongs to any group, it will goes to default policy)

URL Filtering:

General (User-defined.policy: General) .. whitelist :

Internet (User-defined.policy: Internet)....  blocklist:

Default (default policy)

User from General policy by right can access because the policy says it is on whitelist but when User from Internet policy try to access to, it does not go to blocklist of Internet policy. But it went through General policy.

When I checked AD, both users are not duplicated.. Which means they are all separated.

What I did in the group policy assignment is selecting groups: General for General and Internet for Internet.

I have called Tech Support but they seemed very clueless..

Here is the case id: 4-13444698826

Version history
Revision #:
3 of 3
Last update:
‎03-20-2018 11:30 AM
Updated by:

Community Help Hub

    New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

  • Find Forum FAQs
  • Learn How to Earn Badges
  • Ask for Help
Go to Community Help

Join the Community

    Thousands of customers use the McAfee Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

  • Get helpful solutions from McAfee experts.
  • Stay connected to product conversations that matter to you.
  • Participate in product groups led by McAfee employees.
Join the Community
Join the Community