Am I understanding group policy application correctly???

[AaronKennedy]

I have a complete Meraki ecosystem from end-to-end (MX, MS, MR) and I have been experimenting with applying Group Policies to wireless devices connecting through a single SSID. This is the behavior I have noticed, and I just need some confirmation that my observations match how things are "supposed to" happen.

If my SSID uses a splash page that authenticates with Active Directory, I use Nat Mode for IP assignment, and in Security & SD-WAN --> Configure --> Active Directory I set things up so different AD groups have different policies applied to their devices, then...

• After a device connects and the user signs in, the Dashboard client page for that device will show its policy as "normal", but the group policy based on AD membership appears to have actually been applied to the device and the rules in the AD policy are being followed correctly. On the Network-wide --> Configure --> Group Policies page, it always states that there are zero affected clients in the policies based on AD membership regardless of how many devices may actually be connected.
• If I subsequently manually apply a different group policy to one of these devices via its client page in the Dashboard, rules from this new policy are followed, but the rules in the policy assigned based on AD membership are also ALSO still being followed. It is as if the device is now affected by TWO group policies.

Now, let's switch things up. If I change the SSID to use a WPA-2 password instead of a splash page, set the IP assignment method to Bridge Mode, tag the devices with a VLAN, and have a server on that VLAN handle DHCP, then the behavior of group policies changes.

• If a user on a domain-joined workstation logs into that device, then the appropriate AD assigned group policy is applied during that user's session. If a different user subsequently signs in, then the AD assigned policy for the new user gets applied instead. But the group policy seems to be only partially applied. Layer 3 and Layer 7 rules are inconsistently applied, and none of the overrides or appends in the 'Security Appliance' section of the group policy seem to have any effect whatsoever.
• However, if a user signs into the device with a local account, then no custom group policy is applied and the device is given a "normal" status. If I create a new group policy and tag it with the correct VLAN, then this policy gets applied to the non-domain computer instead. But like before, only some of the policy seems to be applied. Layer 3 & 7 rules are inconsistent and the 'security appliance' customization is ignored.

Finally, if I tweak things so the Layer-3 MS switch handles DHCP for the VLAN, domain workstations are out of luck entirely, but things get a little bit better for the non-domain computers... 

• Now if I set a custom policy and tag it with the appropriate VLAN, then it will be applied to the devices that connect and the Layer-3 rules will work properly. Layer-7 is still spotty, and any security appliance customization is still ignored.

My assessment of these observations is that if I want a group policy to be completely and reliably applied to a device, then I need to let the MX handle DHCP. If I let the MS Layer-3 switch handle DHCP, I lose the ability to customize content filtering and threat protection on the MX. If I let my WIndows domain controller handle DHCP then all I am left with is the ability to regulate bandwidth and scheduling.

Thanks for taking the time to read my lengthy post.  Am I understanding group policy behavior correctly?

[PhilipDAth · Accepted solution]

Group policy settings that are applied by the MX only works for clients that use the MX as their default gateway.  They wont work if they are using a layer 3 switch as their default gateway (or an MR in NAT mode).

If you do use an alternative default gateway then the policy gets applied to all traffic coming from that default gateway (and hence all clients behind it).

[AaronKennedy]

Ahh... so it isn't what device is handling DHCP that determines policy application, but what the client is using as its gateway that determines policy application.  That means...

1. If my Windows AD domain uses the MX IP as its default gateway, then group policy should get applied as expected to all domain workstations.
2. If I set up an SSID that uses "NAT Mode: Use Meraki DHCP" for IP assignment, then the MX will act as the gateway for those devices and group policy will be applied as expected to all connected devices.
3. If I set up an SSID that uses "Bridge Mode: Make clients part of the LAN" for IP assignment but have my MS320 supply IP addresses, then the 'interface IP' for the relevant VLAN on the MS acts as the gateway for those devices. But group policy should still be applied, because the traffic arrives at the MX from the SVI IP of the MS320, and the MX will apply group policy to all traffic from that IP.

Scenario 1 is exactly the behavior I have witnessed on my network with my domain-joined devices.

Scenario 2 seems to be working as well, but here is where I still have a question... Users connect through an AD splash page and I have different group policies that get applied in this scenario depending on the AD group membership of the user. Those work as expected. However, if I subsequently manually assign a device a different group policy, then BOTH the new custom group policy and the AD group policy seem to be applied simultaneously. Is this expected behavior, or should the manually applied policy be completely overriding the policy assigned during sign-in?

Scenario 3 does not seem to be working in the manner described above. When I set up an SSID in this manner, neither the automatically assigned AD group policy or a manually applied custom policy seem to work as expected. Bandwidth restrictions are still applied, but only port-based Layer-3 firewall rules work. URL/IP-based Layer-3 rules do not work, nor do any Layer-7 firewall rules. Any customization made to the network defaults on the security appliance are also not applied.

I originally had my wireless network set up as described in Scenario 3 so I could VLAN-tag and partition different user groups, but struggled with getting group policy to work properly, so switched to Scenario 2. I got working group policies as a result, but lost the ability to separate different user groups into different VLANs.

Does my problem stem from the fact that my VLANs are set up as interfaces on the MS320 switch?  If I configured my VLANs as subnets on my MX100 instead would that allow me to still partition users into different VLANs but have working group policies get applied to them?

And one last (sort of related) question. I work at a 750 student K-12 school and we have an MX100 (advanced security), an MS320, multiple MS2xx and many MR34/42. Is my network over-designed? Do I actually need the Layer-3 switch? How can I leverage the added functionality of the Layer-3 switch if I have to use the MX for all of my routing in order to properly apply group policies?

Sorry for an even longer reply 🙂

[PhilipDAth]

>  If I configured my VLANs as subnets on my MX100 instead would that allow me to still partition users into different VLANs but have working group policies get applied to them?

Correct.

>Do I actually need the Layer-3 switch?

If you have high bandwidth flows on site (such as to on-premise servers) then you need the L3 switch.  If most of your traffic is to and from the Internet then you can use your MX100.

[AaronKennedy]

Thanks.

I think I just needed someone to 'listen' as I talked through the whole situation. I have a much better understanding now of how to accomplish what I want with VLANs & Group Policy.

Of course I now have some questions about high-bandwidth flows over the internal network, but that is a topic for a different thread.