Microsoft NPS as a RADIUS Server for WiFi Networks: SSID Filtering

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

In this article we look at how we can use NPS to provide authentication for WiFi users across a number of SSIDs.

We have previously discussed how to authenticate groups of users using the same SSID and then assign them to a VLAN that is appropriate to their security authorization. However, there may still be instances where two or more SSIDs are in-use on a wireless network and we would like to base policy decisions on the SSID that the authentication request is being generated from.

As an example, if we consider a school, perhaps we would like students to only be able to authenticate if they connected to the SSID: "Student_Net". Similarly,  staff should only be able to connect using the SSID: "Staff_Net". This would prevent any students using the staff SSID, even though they have valid AD network credentials, and vice versa.

There are two methods of achieving this goal - we'll take a look at both of them. We may use either of two RADIUS attributes to perform our decision making process in our NPS policies:

• Call Station ID
• NAS-ID

So that you can visualize what our example might look like, here is a diagram of a theoretical network. We have an NPS which is part of the Microsoft AD domain, a wireless LAN controller and an AP broadcasting the two SSIDs previously discussed.

Don't worry too much about the various VLANs and services shown, our main points of interest are the wireless clients (Student & Staff), the access point (AP), the wireless controller and the Microsoft NPS server. The staff SSID is mapped (statically on the wireless controller) to the staff VLAN on the WLC, with the student SSID mapped to the student VLAN.

As we're using an EAP authentication method (which we must, by implication of the fact we are using NPS) to authenticate users, we need to consider the 3 components of the EAP process:

• the supplicant (the wireless laptops in our case)
• the authenticator (the wireless controller)
• the authentication server (NPS) 

The diagram below shows a generic 802.1x authentication exchange, showing the 3 components of the process:

What we are trying to achieve is the authentication of our wireless clients against the Windows AD environment. 

NPS acts as our authentication server and provides the interface in to the AD domain to check any credentials provided by the wireless clients.

The wireless controller (the authenticator) acts as the go-between for the wireless clients and the NPS server, converting authentication requests from the clients in to RADIUS requests that the NPS server can understand and process.

The student and staff devices are the actual devices that need to be authenticated (the supplicants).

NPS Policy Using Call Station ID

The 'Call Station ID' is one of the RADIUS attributes that we can use for our SSID matching logic in our policy. From my experience of a number of wireless vendors, this seems to be the RADIUS attribute that is most commonly sent by an EAP authenticator (i.e. AP or WLC) that contains SSID information that we can use to pattern match.

The actual attribute contains the MAC address of the client, together with the text of the SSID name in a format similar to this: 

00-00-bb-cc-dd-ee:<SSID_Name>

In the attribute value that we specify in our policy to match our SSID, we are actually specifying a regular expression to match the end of the Call Station ID string (i.e. our SSID). For instance, if our SSID name is "Staff_Net", then to match it in our policy, we simply put a dollar symbol ($) at the end of the string we want to match. In this case, we simply put the value: "Staff_Net$"

Just to provide a real world example for us to look at, we have a Cisco wireless LAN SSID configuration to look at (though this approach will work with many other vendors equipment). The SSIDs we are using are "Student_Net" and "Staff_Net".

To configure NPS to provide the policy enforcement for our theoretical network, we will create 2 policies within NPS:

• School Wireless - Staff (to authenticate staff users on the staff SSID)
• School Wireless - Students (to authenticate student users on the student SSID)

Here are screen-shots of the NPS policies that we need to create:

We'll take a look in detail at how each policy is configured.

Staff Policy

1. Create the policy and enable it:

2. Add the NAS type, AD group membership conditions (must be members of the staff group) and the Called Station ID condition (more detail on this in next screen-shot):

3. The Called Station ID condition is added by hitting the 'Add' button in the Conditions panel and scrolling down to the 'Gateway' section of the available conditions and then selecting "Called Station ID".

4. If you hit the 'Add' button, you get to enter the 'Calling Station ID' parameter, which will be added to your policy. In this case, we want to use the parameter to ensure only requests from our SSID ("Staff_Net") will pass this condition. To match our SSID, we have to enter the following string : Staff_Net$ (see graphic below).

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

6. Finally, configure the standard RADIUS attributes:

Student Policy

1. Create the policy and enable it:

2. Add the NAS type, AD group membership conditions (must be members of the student group) and the Called Station ID condition (using value 'Student_Net$'):

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

4. Finally, configure the standard RADIUS attributes:

NAS-ID

When using the NAS-ID RADIUS attribute to specify the SSID that we would like use for our policy decision process, things are very slightly easier. 

Instead of specifying a regular expression string to filter out the SSID part of the attribute (as we have to do with the Called Station ID), we just specify the actual value of the NAS-ID which we configure on our wireless network. The NAS-ID can be the same as the actual SSID, or we can specify some other value if we choose.

As an example, here is how we might configure the NAS-ID value for a Cisco wireless LAN controller. This is the configuration of our staff and student SSIDs with NAS-ID values of 'Staff_NAS_ID' and 'Student_NAS_ID' respectively:

When we now create our policy, the process and values are exactly the same as the examples presented previously for the Called Station, with the exception of the 'Called Station ID' parameter in the Conditions area of our policy configuration. This time, instead of selecting the 'Called Station ID', we choose to use the 'NAS Identifier' parameter.

The NAS identifier configuration is shown below. Note how the value for the 'NAS Identifier' value in our policy exactly matches the NAS-ID parameter specified on the SSID configuration on the wireless LAN controller:

As discussed previously, the NAS-ID parameter is available across many different wireless vendors. Although I have presented a Cisco example in this article, many other vendors support the same RADIUS parameter. I'd recommend using the NAS-ID parameter where possible as it is slightly easier to use and more flexible to use. 

Hopefully, you can now see how you can use either the 'Called Station ID' or the 'NAS Identifier' RADIUS parameters in your NPS policies to tailor the policy decision making process to be SSID-specific. This technique will generally be used where two or more SSIDs that use 802.1x authentication (e.g. PEAP, EAP-TLS) are available on a wireless network.

If you found this article useful, please check out my other articles at http://WiFiNigel.blogspot.com.