Hello All. We licensed advanced and are still struggling with the active directory group policies mapping to the meraki group policy. Basically we left the network default contact filter policy to allow access to all sites and then use group policies to apply content rules starting at the top the less restrictive to the most restricted at the bottom of the group policy list. I am correct in assuming that the mx will process from the top down the group policies until it gets a hit on a user and then stops right there? Or does it continue to see if that user is in subsequent groups? I assume the former. So basically we have people at the top of the list as unrestricted and then under that have the same categories defined at the very bottom of the list (most restrictive) with url white lists. However users are still able to go anywhere they want. The event logs do show the users being mapped into specific groups but the policies are not working.    Am I understanding this order of operations correctly?    Thanks very much  ... View more

Hello All.   So we have (5) sites MX100 at the main site, MX84 at another site and (3) other MX64's.  The main site had an older Barracuda Web filter and it has been working well.  However, as we installed these Meraki devices in the enterprise we decided to upgrade from the Enterprise to Advanced licensing to use the IPS, Malware and content filtering in the cloud at all sites.  Seemed logical to go this route.  But as we are deploying this we have noticed some things that do not seem logical to us.  We are likely missing something.   #1) AD integration: This was super easy to setup on the MX.  However, it appears that you can only apply exceptions to "groups" as opposed to individual users in AD.  For instance, on the cuda we could have content category rules defined for the location.  And if a particular user comes up and says I need access to shopping sites we could setup an exclusion for that particular user via AD for that category.  However, that function does not seem to exist on the Meraki.  I would need to create a group and then add the user to that group to setup the exception.  For various people who might want these exception at the user level this could prove to be a nightmare to manage.  The closest thing I saw was to go to the clients page and select the client and apply a "group" rule to that client.  However, that is by client machine and not user.  We might have 2 users sharing one computer.  One user would get the exception where the other would not.  Am I missing something?  With AD integrated it does not seem logical to only allow exceptions based on groups and not users.    #2) On the group definitions I can create a group called "shopping exception" which we were hoping to basically setup an exception so the members of this group could visit shopping sites and not be subnet to the default "network rule" that blocks all shopping sites.  Seems logical.  However, when I go to the Network-Wide/Group Policies and scroll down to blocked web site categories it seems a little odd.  It gives me the option to override or append.  Append does not seem applicable here since I want to allow a site not block one.  Override seems to override all the network policies and forces me to recreate all the network wide category lists and omit shopping.  Is that correct?  That will be a ton of work.  Is there any way to simply "whitelist" a category for a group?     #3) It seems like these content filter rules are based on each MX instead of organizationally as a whole.  Is there any way to create an organization wide category filter that applies to all sites?  I know there is the "configuration sync" at the organization level and if that is what we need to do then I guess it would work.  But it seems odd that we can not have an organization wide content filter and then customize each site accordingly if needed.   We love the cloud management and reporting of the Meraki units.  However, this content filtering setup (especially with AD) seems like a serious regression from the barracuda.   Thanks for any info   Dave ... View more