Dynamic VLAN Assignment (Cisco and NPS)

In an earlier post we used 802.1x to authenticate users into the network and assign them into a VLAN based on either a successful or unsuccessful authentication as well as a VLAN for clients who did not send an initial EAPOL message. While this can be quite useful, it can also be quite restrictive – what if we wanted different authenticated users into different VLANs rather than just the authenticated VLAN? This is entirely do-able. An example use case would be having be an office with several hot desks, used by various departments, but a compliance restriction that places heavy restrictions on network access into particular resources such as HR, finance and so on. It would be an administrative headache to keep logging into the switch each time to change the VLAN depending on who was sat at these hot desks for the day, so we can leverage 802.1x to do this for us.

If you’re reasonably new to 802.1x then I suggest you head over to my earlier post on 802.1x and return back once you’ve read it. It covers some of the fundamental concepts and configurations which we’ll build on here. To start with, we’ll want to configure our AAA settings but this time with one addition ‘aaa authorization network default group radius’ which will instruct the switch to use AAA for network services including VLAN assignment. We’ll also get away without stipulating a VLAN for the interface as this will be passed to the switch from the RADIUS server (although in production you may want to set this in case the RADIUS server(s) are unavailable).

aaa new-model
aaa authentication dot1x default group radius
aaa authorization network default group radius
dot1x system-auth-control


radius-server host 172.16.0.20
radius server key CiscoLab

vlan 20
name Staff
vlan 30
name Students
vlan 40
name Guests



interface GigabitEthernet0/14
switchport mode access
dot1x pae authenticator
dot1x port-control auto
spanning-tree portfast


On the NPS policy side we’ll add in the IP addresses of the switches as RADIUS clients with the RADIUS server key we setup earlier on the switch. We’ll then create a couple of new Network Policies for VLAN20, VLAN30 and VLAN40 with conditions against the Active Directory user groups we want to assign, with specific attention to the RADIUS Attributes section as we’ll need to use options 64, 65 and 81 to feed the VLAN options back to the switch. The below screen grabs show the process for VLAN40, but it is just a rinse and repeat for the other VLANs modifying the groups and VLAN ID where required.

NPS Policy

Once this is complete the last step is to configure a client machine for 802.1x wired authentication. I’ve covered this here, but in brief this requires the ‘Wired AutoConfig’ service starting on the Windows device.

Now onto testing…

Assuming you’re good to go for connectivity between the switch and RADIUS servers then we can move onto connecting our device to the network port we configured for 802.1x. Here I’ve connected in the device and given the credentials of an authorised student, as a result being placed in VLAN30:

In this example I disconnected the device, reconnected and gave the credentials of an authorised guest to be placed into VLAN 40 (Guest):

And finally, providing credentials that place me into VLAN 20 (Staff):

There are some extensions to this, we can incorporate a ‘dot1x auth-fail vlan #‘ command to take care of any devices that refuse to talk 802.1x with the switch. Anther useful extension of this is for approved devices such as printers we can use MAC Authentication Bypass to authenticate these devices by MAC address should they time out on the 802.1x process – I’ll cover this in a future post!