Skip to content

Dynamic Vlan Assignment With Radius Server And Wireless Lan Controller Configuration Example

The Microsoft Network Policy Server (NPS) is often used as a RADIUS server for WiFi networks. It can provide authentication and authorization services for users on a wireless network.

In this article we take a look at how users can be dynamically assigned to a VLAN that suits their account privileges, using RADIUS attributes passed back from NPS to the RADIUS client (usually a wireless LAN controller or access point).

This method of assigning a user to a particular VLAN based on their login credentials is also known as Role Based Access Control (RBAC). 

As wireless networks have grown to provide more and more services to organisations, the practice of creating a new SSID for each new service required has fallen out of favour, as each SSID adds more overhead to the RF medium, reducing the available bandwidth for all wireless services. 

Best practice in terms of the number of SSIDs you should have available from your wireless network is generally accepted to be around 4 or 5 SSIDs as a maximum. The main reason for this is that each SSID is constantly broadcasting 10 beacons per second, which obviously multiplies up fairly quickly as you add more SSIDs. As WiFi networks are a contended medium (i.e. only one client or AP may use a channel at any point in time), then your available airtime can get eaten up by beacons and cripple the throughput of your wireless network. The answer is to use the same SSID multiple times for multiple services, by assigning users to a designated VLAN based on their level of authorization on the network.

Looking at a simple example, lets consider a school that wishes to use the same SSID for both students and staff. Students may be allowed access to a particular set of systems (e.g. the school learning system portal and the Internet). Staff may be more privileged and allowed access to a wider set of systems (e.g. learning portal, staff administration systems and Internet). The restrictions on each group of user's access can be enforced by assigning the users to a VLAN that has appropriate access restrictions (e.g. VLANs may have ACLs applied or firewall rules that only allow traffic on those VLANs to access particular systems).

With Microsoft NPS, it is possible to decide if a user belongs to a particular group of AD users (e.g. Staff or students) and make an initial  decision about allowing them access to the network.

However, in addition, it may also pass back information about which VLAN users in each group are allowed to access. Using this approach, you can begin to see how NPS can  be used to allow  users on an SSID to be authenticated to the wireless network, but only allowed access to authorized resources by assigning them to an appropriate VLAN (based on their AD group membership).

Configuration Example

Here's an example of how you might configure NPS to assign users to a VLAN based on their user group, using NPS for the authentication and authorization of users. This configuration will work for Cisco, Meru and Xirrus systems (it may well work for other WiFi solutions too - these are the only solutions I have tested).

The key to getting this to work is the use of a RADIUS element called: 'Tunnel-PVT-Group-ID'. 

This is a RADIUS attribute that may be passed back to the authenticator (i.e. the WLC or AP) by the authentication server (i.e.NPS) when a successful authentication has been achieved. There are a few other elements which need to accompany it, but this is the key element, as it specifies the VLAN number that the user should be assigned to.

The other elements that need to be returned by NPS are:

  • Service-Type: Framed
  • Tunnel-Type: VLAN
  • Tunnel-Medium-Type: 802
  • Tunnel-PVT-Group-ID: <VLAN Number>

We'll have  a look at how we specify each of these attributes in an NPS policy. 

For our example, we'll assign all 'staff' users to VLAN 10 and all 'student' users to VLAN 20. 

Here is an overview of what the network might look like (this is obviously very simplified, but gives an overview of the type of thing that might be achieved):

VLAN 10 has an ACL (access control list) that allows users on this VLAN to access all systems across the school network. The ACL would generally be configured on the layer 3 switch or router that interconnects the school VLANs)

VLAN 20 has an ACL which only allow access to the learning system VLAN and the Internet related services.

By studying the example above, you can see that if we can control a users VLAN assignment, based on their AD group membership, we can ensure that they only receive the network access to which they are entitled (purely via their AD group membership). Also, note that this is all being done on a single SSID ("School" in this case).

Now we'll take a look at how we achieve this using NPS.

NPS Configuration

To configure NPS to provide the VLAN assignments outlined above, we will create 2 policies within NPS:

  • School Wireless - Staff (to assigned members of the staff AD group to VLAN 10)
  • School Wireless - Students (to assign members of the students AD group to VLAN 20)

The screen-shots below outline the configuration required. Here is the policy summary screen within NPS. Note that when configuring multiple policies, the order of the policies is important. Policies are assessed top-down, so make sure the policies that need to be hit are enabled and above any disabled polices.

Staff Policy

1. Create the policy and enable it:

2. Add the NAS type and AD group membership conditions (must be members of the staff group):

3. Select and configure an EAP type (note this may be PEAP or EAP-TLS - we've shown PEAP just as an example)

4. Configure the settings for this policy to assign any users which match this policy to VLAN 10:

Students Policy

1. Create the policy and enable it:

2. Add the NAS type and AD group membership conditions: (must be members of the students group to match this policy)

3. Select and configure an EAP type (note this may be PEAP or EAP-TLS - we've shown PEAP just as an example)

4. Configure the settings for this policy to assign any users which match this policy to VLAN 20:

Once NPS has been configured with policies similar to those shown above, users can be dynamically assigned to an appropriate VLAN based on their AD group membership. 

As we've already discussed, this provides great benefits in reducing additional overheads associated with multiple SSIDs on a WiFi network. In addition, it simplifies user wireless management by allowing all users to be configured with a single wireless client profile, with their access being configured via Microsoft AD.

One caveat to note when trying to use this technique is that all users must be using the same security mechanisms to join the SSID. For instance, all users must be using 802.1x (EAP) - you can't have a mix of PSK & 802.1x authenticated devices on the same SSID. Generally, they should also be using the same WPA version (i.e. WPA or WPA2).

In this post we will learn/test how the dynamic VLAN assignment works.

Basic Info:

Dynamic VLAN assignment: It pushes a wireless user into a specific VLAN based on his identity. This task of assigning users to a specific VLAN is handled by a RADIUS authentication server (i.e. ACS).

It’s a type of identity networking. It allows us to have single SSID, but allows specific users to use different VLAN attributes based on the user credentials.

This task of assigning users to a specific VLAN is handled by a RADIUS authentication server (ACS 5.2 in my case). This can be used, for example, to allow the wireless host to remain on the same VLAN as it moves within a campus network.

As a result, when a client attempts to associate to a LAP registered with a controller, the LAP passes the credentials of the user to the RADIUS server for validation. Once the authentication is successful, the RADIUS server passes (IETF) attributes to the user. These RADIUS attributes decide the VLAN ID that should be assigned to the wireless client.

***In my post I am using a single SSID

My Topology:

Let’s take an Example:

  1. We will create a SSID “XYZ” and assign a non-routed VLAN (99) or management VLAN to it.
  2. Now we have Groups of employees in our company “Production, Admin and Sales”.
  3. VLANs as per Roles.(Production – 13, Admin – 14, Sales – 17 )

Steps to Configuration:

  • Configure WLC
  • Configure ACS server
  • Verification

Configure WLC

We must configure the WLC so it can communicate with the RADIUS server in order to authenticate the clients.

  1. Configure ACS on WLC:

From the controller GUI, click Security> Authentication

  1. Create dynamic interface (for VLAN 13, 14 and 17)

Example for VLAN 13, same we have to do for VLAN 14 & 17

Controller GUI, in the Controller > Interfaces

  1. Create a WLANand assign to a Non Routed VLAN or management interface

From the controller GUI, go to WLANs> Create New

My WLAN is “XYZ”

Enable AAA override feature:

CLI Command to enable: config wlan aaa-override enable wlan-id

Configure ACS (RADIUS) Server

  • Configure Network Resources.

AAA Client (WLC management IP), Location, and device type

  • Configure User and Identity Store

Create Identity Group, Users and then assign users to Identity Groups(Production, Admin and Sales Users)

Create Identity Store Sequence

Custom Profile

End Station Filter

Create Authorization Profiles

Select EAP Method

Assign Auth. Profile as per identity

  1. Configure Network Resources.

First we will add the WLC as an AAA client on the RADIUS server so that the WLC can pass the user credentials to the RADIUS server.

Create a Location type:

From the ACS GUI, go to Network Resources > Network Device Groups > Location, and click Create

Crete Device Type:

Go to Network Resources >Network Device Groups > Device Type > Create

Add WLC as AAA client in ACS sever:

Go to Network Resources > Network DevicesandAAA Clients. Put the WLC IP and shared secret (it must be same as in WLC)

  1. Configure User and Identity Store

Create Identity Group, Users and then assign users to Identity Groups:

In this post we will create three types of users (Production, Admin and Sales Users)

For Identity Groups:

Go to Users and Identity Stores > Identity Groups> Create

For Users:

Go to Users and Identity Stores > InternalIdentity Stores > Users> Create

Create Identity Store Sequence:

As we don’t need it in this post (only internal user option will also work)

Go to Users and Identity Stores > Identity Stores Sequences > Create

  1. Define policy elements.

Custom Profile

Create a Custom SSID Profile or create an END STATION filter (we will use only one method from this and that will be CUSTOM SSID)

Go to Policy Elements > Custom> Create

Enter the Name (MySSID), choose Dictionary as RADIUS-IETF and Attribute as Called-Station-ID.

End Station Filter:

Go to Policy Elements> Network Conditions>End Station Filter>Create

*** We will not use this in this post

Create Authorization Profiles:

Go to Policy Elements> Authorization and Permissions> Network Access > Authorization Profiles > Create.

IN this post we are using vlan 13, 14 and 17 so we need three Auth Profiles.

Two ways to do: Either under Common Tasks or under RADIUS Attributes:

Both ways are shown here.

So in end auth profile will look like this:

  1. Access Policies

We are using Radius Authentication we have to use Default Network Access.

Select which EAP method we would like the wireless Clients to Authenticate. In this post we will use EAP-FAST or PEAP.

Select Identity under Default Network Access as “MyLab” which we created earlier.

Configure Authorization Rules:

Go to Access Policies> Access Services> Default Network Access > Authorization.

We can customize under what conditions we will allow user access to the network and what authorization profile (attributes) we will pass once authenticated. In this post, we selected Location, SSID, Device Type, and Identity Group.


Production User must go in vlan 13.

Sales User must go in vlan 17.

Admin User must go in vlan 14.

Logs from ACS:

Thats all 🙂