Posts

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

Image
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

Microsoft NPS as a RADIUS Server for WiFi Networks: Dynamic VLAN Assignment

Image
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

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