Microsoft NPS as a RADIUS Server for WiFi Networks: Dynamic VLAN Assignment
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.
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).
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.
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):
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).
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).