802.1X /w Dynamic VLAN Assignment

[whistleblower]

Hi,

I´d like to use a Windows NPS Server for 802.1X Authentication on our Wired-Clients. For this I´d like to ask a question in general! How does the Dynamic VLAN Assignment work from the technical perspective, I mean how does the VLAN get changed on the Switchport itself - does the NPS/Radius do that configuration or how is this change triggerd?

greets

[PhilipDAth]

The machine tries to access the network.  The switch port says no, you must 802.1x authenticate first.  The machine responds and the switch sends this info to the NPS server.  The NPS server responds and can include in its response the VLAN to use.

The switch then places the port into this VLAN and allows the machine access.

The machine then requests an IP address using DHCP, etc.

[Bruce]

As @PhilipDAth states the switch assigns the VLAN based on the information received back from the RADIUS (NPS) server. These are the attributes that need to be returned:

Dynamic VLAN Assignment
In lieu of CoA, MS switches can still dynamically assign a VLAN to a device by assigned the VLAN passed in the Tunnel-Pvt-Group-ID attribute. It may be necessary to perform dynamic VLAN assignment on a per computer or per user basis. This can be done on your wired network via 802.1x authentication (RADIUS). In order to do so, the following RADIUS attributes must be configured and passed in the RADIUS Access-Accept message from the RADIUS server.

• Tunnel-Medium-Type: Choose 802 (Includes all 802 media plus Ethernet canonical format) for the Attribute value Commonly used for 802.1X. 
• Tunnel-Private-Group-ID: Choose String and enter the VLAN desired (ex. "500"). This string will specify the VLAN ID 500.
• Tunnel-Type: Choose Attribute value Commonly used for 802.1X and select Virtual LANs (VLANs).

Once these attributes are configured on the RADIUS server, client devices can receive their VLAN assignment dynamically.

Reference: https://documentation.meraki.com/MS/Access_Control/MS_Switch_Access_Policies_(802.1X) 

[whistleblower]

so it isn‘t necessary to enable CoA for the dynamic vlan assignment to work, correct? if so, why does this option than exist and where/when should or could it be used?

[Bruce]

For straight 802.1x assignment of a VLAN when a user first connects to the network, CoA isn’t required. Enabling CoA configures the switch to listen for CoA messages from the RADIUS server. This allows some more advanced servers, e.g. Cisco ISE (there are other vendors too), to tell the switch to perform the authorisation of the switch port again, so allowing the VLAN to be changed after initial authentication has been performed. This is useful where the RADIUS server has separate threat feeds, or is performing ongoing posture monitoring and can detect, or be informed, of a change in the client state.

There is also a new feature that you may be interested in too called Group Policy ACL, https://m.youtube.com/watch?v=nekC3_z5SDk. It’s akin to dACLs on the Cisco Catalyst. I can’t find any information on the Meraki site about it, but it was included in the MS14.5 release notes - so you’d need to run the beta code train.

[whistleblower]

please allow me two more questions on this topic..

1-)

---

@Bruce wrote:

For straight 802.1x assignment of a VLAN when a user first connects to the network, CoA isn’t required. 

---

what is the reason from technical perspective - the CoA is disabled per default in the dashboard?

2-)

---

@Bruce wrote:

 Enabling CoA configures the switch to listen for CoA messages from the RADIUS server. This allows some more advanced servers, e.g. Cisco ISE (there are other vendors too), to tell the switch to perform the authorisation of the switch port again, so allowing the VLAN to be changed after initial authentication has been performed. This is useful where the RADIUS server has separate threat feeds, or is performing ongoing posture monitoring and can detect, or be informed, of a change in the client state.

---

maybe you know the current possibilities when using ISE in combination with Meraki MS Switches products? I´m not sure what of the features are supported compared when using the Cisco Enterprise devices e.g. device profiling, posturing, TrustSec, etc.

---

@Bruce wrote:

There is also a new feature that you may be interested in too called Group Policy ACL, https://m.youtube.com/watch?v=nekC3_z5SDk. It’s akin to dACLs on the Cisco Catalyst. I can’t find any information on the Meraki site about it, but it was included in the MS14.5 release notes - so you’d need to run the beta code train.

---

thanks for pointing me to that - I´ll have a look and try to understand how this can be used probably in my deployments as well 🙂

[Bruce]

Sure, no worries.

1) The 802.1x processes by themselves allow for a user to be authenticated and for a VLAN to be assigned to the port. With the original 802.1x once a user was authenticated and VLAN assigned there was no way to change the authorisation on the port until the user physically disconnected and reconnected. Modern systems required that if security conditions change the authorisation of the port can be changed, and hence in the last five years or so switches have supported CoA to enable this. You need a RADIUS server that supports CoA (e.g. Cisco ISE, Aruba ClearPass) if you’re going to use it, but for standard 802.1x almost any RADIUS server can be used. See here, https://documentation.meraki.com/MS/Access_Control/Change_of_Authorization_with_RADIUS_(CoA)_on_MS_S...

2) There is a document (which I can’t find now) which outlines the compatibility of Cisco ISE with Meraki MS switches. From memory they don’t support URL redirect, and they definitely don’t support TrustSec/SGT (the MS390 is slightly different, but best not go there). EDIT: found the document https://community.cisco.com/t5/security-documents/how-to-integrate-meraki-networks-with-ise/ta-p/361...

Hope this helps.

[whistleblower]

@Bruce

I just want to let you know, that regarding the feature = Group-Policy ACL

I‘ve found the following documentation: https://documentation.meraki.com/MS/Access_Control/Meraki_MS_Group_Policy_Access_Control_Lists

I think it describes the functionality very good but one question is left open for me 🙂

Maybe you can tell me, how this will work/ should be configured when 802.1X Multi-Auth is configured? (example is PC connected behind IP-Phone)

[Bruce]

@whistleblower thanks for updating the thread, that documentation is new since the Group Policy ACL went into public beta and it nicely completes it. Your questions around multiple authentications is a good one, and I don’t know the answer - I’d need to try it to confirm. Below is what I’d expect to happen (based on experience and ‘guess-work’), but would be great for someone that knows to update this thread.

1. Single-Host, easy and just as expected.

2. Multi-Domain, I would expect that the Group Policy ACL will only be triggered by the data domain, and that will be enforced on the port. I doubt very much whether the voice domain will trigger Group Policy ACL - the only question will be whether or not the ACL will apply to traffic in the voice domain (my gut feel would be that it won’t, but needs to be confirmed).

3. Multi-Auth, I expect this will work as it does for VLANs where all authentications have to return the same VLAN or they are denied. In this case I expect they’d have to return the same Group Policy ACL or they’ll be denied. The voice domain will be as per above.

4. Multi-Host, isn’t supported with Group Policy ACL.

Would be great if someone that actually knows could confirm this, or add the correct results.