Showing posts with label SSID. Show all posts
Showing posts with label SSID. Show all posts

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.

Friday, 16 August 2013

How Much Air-Time Do Beacons Actually Burn?

It’s a well known rule of thumb when designing WiFi networks that you need to try to keep the number of SSIDs broadcast by your wireless network  down to a ‘reasonable’ number. In this article, I take a look at how much of an issue SSIDs (and their beacons) are in consuming valuable wireless air-time.

Generally, it’s recommended to keep the number of SSIDs below around 5 (ish).

The reason for keeping the number of SSIDs to a minimum is that each SSID is advertised using a type of management frame called a ‘beacon’.  Beacons are generally sent 10 times per second for each SSID on the wireless network. Therefore, if you have 10 SSIDs, they will each be advertised 10 times per second, giving us 100 beacons per second.

Air-time is a finite resource – there is only so much data that can be transferred across the air over a period of one second. If a large chunk of air-time is being consumed by SSID beacons, then that doesn’t leave a whole lot of time remaining for actual user data to travel over the air (which is the whole point of having a wireless network!).

I have previously heard statements from various wireless engineers along the lines of up to 50% of available air-time being consumed by beacons once you have 6 or 7 SSIDs being broadcast by a network. I’ve taken this information on face-value and never really thought too much about it.

However, this evening I found myself in a hotel room with some time on my hands, a Cisco WLC, a Cisco AP and a copy of Metageek Eye PA. I thought it was time to test the ‘conventional wisdom’.

My approach was simple: I would set up my AP on channel 11 (2.4GHz) and capture all frames using Eye PA. I would vary the number of SSIDs being broadcast and monitor the results.

I would also vary the lowest mandatory speed supported by the 2.4GHz network between 1Mbps, 11Mbps and 54Mbps. Beacons are sent at the lowest mandatory speed that is configured for a wireless network. Therefore, if 1Mbps is the lowest mandatory speed, beacons are sent at 1Mbps (and hence are a lot slower and consume more air-time)

To determine how much actual air-time is being consumed by beacons, I would use Eye PA’s filtering capabilities to remove all frames except beacon frames, and remove any other local interfering SSID traffic (i.e. the pesky hotel WiFi on the same channel!). This would leave me with just the beacon frames from my AP:

Eye PA Filtering Beacon Frame


Eye PA allows you to select a period of one second of the filtered traffic that you have captured, and also shows the amount of air-time those frames consumed in that period:



I just then applied some simple maths to work out how much time the beacons frames consumed over a period of one second.
I then tabulated the results:

Number SSIDs Broadcast
Lowest Mandatory Speed
Beacons AirTime Over 1 Sec (mS)
Percentage AirTime Used by Beacons
1
1Mbps
25
3%
7
1Mbps
167
17%
15
1Mbps
326
33%
1
11Mbps
10.5
1%
7
11Mbps
73.5
7%
15
11Mbps
158
16%
1
54Mbps
1.52
0%
7
54Mbps
10.6
1%
15
54Mbps
20.8
2%

The results show pretty much what I expected, but I was surprised by how little time the beacons consumed, particularly once the lowest mandatory speed is ramped up to 54Mbps. They certainly don’t support the information that had been imparted to me regarding 7 SSIDs consuming 50% of all air-time.

You can clearly see the effect of adding more SSIDs (and consequently more beacons). As more SSIDs are added, more air-time is devoted to beacon traffic. This is a bad thing, if it becomes a significant chunk of your air-time.

You can also clearly see the effect of increasing the lowest mandatory speed supported by the wireless network. Once you increase it to 54Mbps, even with 15 SSIDs, you are only consuming 2% of the available air-space.

I suspect that the conventional wisdom of keeping your SSID numbers down to below 5 is founded on the assumption that many wireless networks are going to be installed using default settings. Often, default settings will configure the lowest mandatory speed to one of the lower 802.11b speeds, which could then make significant numbers of SSIDs an issue.

For me there are several lessons to take away:

  • Verify what the defaults of a system are – what is the lowest mandatory speed configured on your system out of the box?
  • Increasing the lowest mandatory speed on a wireless network is going to increase the efficiency (and hence throughput) of your wireless network significantly – less time will be given over to beacon traffic
  • The ‘less than 5 SSIDs’ rule may be a good starting point, but on a well engineered network, it may not be as relevant as it used to do, especially in the presence of modern wireless clients which do not need to support the lower, legacy speeds of 802.11b/g.

A word of caution though before making any wholesale changes to your network. Make sure you do not have any older wireless clients that need to be able to connect to the network at the slower/legacy speeds. Clients need to be able to initially associate to a wireless network at the lowest mandatory speed supported by a wireless network. If you have older devices that are not in areas that have good coverage, they may not be able to associate at a higher speed and will not be able to join the wireless network in those areas. It is probably worth testing the effect of any changes you make carefully.


I’d welcome any feedback on my testing. If there are any flaws in my logic or testing or there are other considerations I may have missed, then please feel free to drop me a note or comment.

Thursday, 19 April 2012

Fast SSID Change - Out Of The Shadows

There are many configuration settings on a piece of networking kit that are just 'there'.

They sit there year after year just minding their own business being a quiet little chunk of configuration sitting in their default state not doing anyone any particular harm. Then, occaisionally, you come across some obscure case that causes you to actually pay attention to what exactly that particular setting is 'bringing to the party'.

One particular instance I came across recently is the 'Fast SSID Change' setting on a Cisco WLC.

From memory, it's been sat there for quite a while on many of the controllers I've installed, sitting dutifully in its default state of 'Disabled'. I've never really paid it much attention as it doesn't (on the face of it) seem to cause anyone any particular problems.

However, I recently ran in to a situation where a customer had some Apple iPads that he wanted to connect to an SSID that was mapped to an internal corporate VLAN. The iPads connected up quite nicely using PEAP - nothing too interesting there. However, the customer also wanted to flip an iPad or two across to the guest user SSID, which was mapped on to a completely different VLAN and anchored to a DMZ controller. The reason to flip between the 2 SSIDs was purely to carry out testing of the new wireless solution (i.e. corporate users with iPads and guest users with iPads).

The iPad was correctly configured for both SSIDs. To flip between the 2 SSIDs, we simply opened the network settings of the iPad and selected each SSID in the list of shown wireless networks. (For full disclosure, the iPad was running iOS 5.1.x, the guest SSID was brodcasting and the corporate SSID was set to not broadcast).

However, when I tried to flip between the SSIDs (e.g. guest SSID to corporate SSID), the iPad would attempt to connect to the newly selected SSID, but would fail and fall back to the original SSID that it was connected to. The real head-scratcher was that a smartphone correctly configured for both SSIDs switched between the two SSIDs back and forth with no issues at all!

After quite a bit of pondering and double-checking of the iPad wireless configuration, I decided to run a client debug on the WLC. The debug seemed to show that the iPad was associating with the newly selected SSID, but then reverted back to the original SSID before any authentication took place. I wasn't too sure what was going on...

After some digging around, I found a few Cisco forum posts talking about 'Fast SSID Change' which sounded like it might be related. Here is the description of the 'Fast SSID Change' parameter from the WLC help files:

"When you enable Fast SSID Change, the controller allows clients to move between SSIDs. When the client sends a new association request for a different SSID, the client entry in the controller connection table is cleared before the client is added to the new SSID.


When Fast SSID Change is disabled, the controller enforces a delay before clients are allowed to move to a new SSID."

So, I tried changing the 'Fast SSID Change' parameter to 'enabled' and suddenly the iPads were happily switching between the two SSIDs with no issues!

I'm guessing this was a timing issue on the iPads - I guess they weren't quite as patient as the smartphone.

The question remaining in my mind is this: why is 'Fast SSID Change' set to disabled by default? I wonder if there are any particular reasons you wouldn't want to just blindly enable it for every installation of a new WLC? (I haven't found any reasons to date...)

I tried to think of other scenarios where you may run in to this issue. It's hard to think of any beyond the testing scenario I described above, but I guess there will be one or two use-cases. I thought of something perhaps around a provisioning-type WLAN where maybe some type of client or agent is provisioned to an iPad and then you need to flip across to another SSID to use the new client or agent, but that was the best I could come up with.

I'd be interested to hear if anyone else has any good arguments for or against enabling 'Fast SSID Change'.

References: