Saturday, 22 March 2014

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.

Tuesday, 18 March 2014

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. 

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).

Monday, 17 March 2014

Cisco WLC N+1 Redundancy - APs Not Joining Redundant Controller

Just thought I'd post up a gotcha I hit today around Cisco N+1 redundancy.

In summary I had a primary Cisco 5008 WLC (AIR-CT5508-50-K9) with a 5508 HA WLC (AIR-CT5508-HA-K9). I set it up for N+1 redundancy as per the Cisco guidelines (note HA, not SSO):

http://www.cisco.com/c/en/us/td/docs/wireless/technology/hi_avail/N1_High_Availability_Deployment_Guide/N1_HA_Overview.html

Both WLCs were running 7.4.121.0 code.

The APs joined the primary controller as expected with no problems. However, when I failed the primary WLC, the APs would not join the secondary. A debug of CAPWAP events on the HA controller revealed the following messages:

*spamApTask2: Mar 17 12:34:43.679: 1c:1d:86:xx:xx:xx Discovery Request from 192.168.1.1:53528

*spamApTask2: Mar 17 12:34:43.679: 1c:1d:86:xx:xx:xx Join Priority Processing status = 0, Incoming Ap's Priority 1, MaxLrads = 500, joined Aps =0
*spamApTask2: Mar 17 12:34:43.680: 1c:1d:86:xx:xx:xx Discovery Response sent to 192.168.1.1:53528

*spamApTask2: Mar 17 12:34:43.680: 1c:1d:86:xx:xx:xx Discovery Response sent to 192.168.1.1:53528

*spamApTask2: Mar 17 12:34:53.675: 00:0f:24:2b:04:c2 DTLS connection not found, creating new connection for 192:168:20:2 (53528) 192:168:1:19 (5246)

*spamApTask2: Mar 17 12:34:55.674: 00:0f:24:2b:04:c2 DTLS connection not found, creating new connection for 192:168:20:2 (53528) 192:168:1:19 (5246)

*spamApTask2: Mar 17 12:34:59.674: 00:0f:24:2b:04:c2 DTLS connection not found, creating new connection for 192:168:20:2 (53528) 192:168:1:19 (5246)

*spamApTask2: Mar 17 12:35:07.674: 00:0f:24:2b:04:c2 DTLS connection not found, creating new connection for 192:168:20:2 (53528) 192:168:1:19 (5246)

*spamApTask1: Mar 17 12:35:53.762: 1c:1d:86:xx:xx:xx Discovery Request from 192.168.1.1:53527

*spamApTask1: Mar 17 12:35:53.762: 1c:1d:86:xx:xx:xx Join Priority Processing status = 0, Incoming Ap's Priority 1, MaxLrads = 500, joined Aps =0
*spamApTask1: Mar 17 12:35:53.762: 1c:1d:86:xx:xx:xx Discovery Response sent to 192.168.1.1:53527

After lots of re-checking of the configuration and head-scratching I called a colleague for inspiration. He advised me he had seen recently a similar issue. The answer: a reboot of the HA WLC.

...it always seems obvious in hindsight.