WifiNigel

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

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

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. Generally, NPS is used with various EAP methods (e.g. PEAP, EAP-TLS) that require a certificate to be presented by the NPS server to the client as part of the authentication exchange. The certificate proves the identity of NPS (the RADIUS authentication server)  to the client and is used to derive keys to build a TLS tunnel for the secure exchange of credential information. Most of the time, a Microsoft PKI infrastructure is used to issue a certificate to the NPS server, which is a relatively straightfoward process that is well documented in official Microsoft documentation. However, there may be times when you want to fire up a version of NPS (perhap s in a lab or POC environment) and just put on your own self-signed certificate, instead of having the additional overhead of getting CA serve

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. I put this document together to highlight one particular little 'gotcha' when using NPS with Windows 2008. Windows 2008 comes in three flavours: Data Centre Enterprise Standard When using NPS as a RADIUS server, you have to add a number of 'RADIUS clients' to the configuration of the NPS server. These are the devices on your WiFi network that will send the RADIUS requests to NPS each time a user tries to logon to the network. The screenshot below shows where RADIUS clients are configured in NPS: The RADIUS request contains username and password information for the user trying to logon to the network. The request is generally checked against a Windows AD domain to see if the user is supplying a valid set of AD credentials to access the WiFi network. In controll

Wireshark has an expression builder to help build filter expressions to filter out the frames that perhaps you don't want to see, or to allow you to select the frames would like to view. At first glance, the categories are pretty overwhelming due to the fantastic array of protocols that Wireshark can decode for us. I certainly had to dig around a little the first time I looked through the list before I found the WiFi related categories. I thought it might be useful to list the categories (that I have found so far!) that relate to WiFi traffic.  Here is the list, together with a brief description of each one: 802.11MGT - IEEE 802.11 Wireless LAN management frame 802.11MGT - Radiotap - IEEE 802.11 Radiotap Capture Header IEEE 802.11 - IEEE 802.11 wireless LAN IEEE 802.11 Aggregate Data - IEEE 802.11 wireless LAN aggregate frames Wi-Fi P2P - Wi-Fi Peer-to-Peer

I quite like to be able to see the frame type, sequence numbers and flags field when looking at a summary of an 802.11 capture in Wireshark.  However, Wireshark can be too helpful when decoding frames and  will display a summary of the frame which shows the detail of hight layer protocols (thus hiding the 802.11 summary info). This generally happens when decoding a capture of a WiFi network that has a guest network that is not using over the air encryption. Here is an example. Some data frames in the trace summary below are shown as ' https ' or ' Application Data ' frames, rather than layer 2 data frames: To prevent this behaviour, simply go to the " Analyze > Enabled Protocol" menu option in Wireshark and de-select 'LLC ': This will restore the standard 802.11 frame summary so that 802.11 frame types, flags etc. are available: One thing to bear in mind with this approach is that some exchanges you would normally decoded (e.g

Generally, when capturing and decoding frames in a wired network, there isn't a huge amount of interest going on at layer 2 of the OSI stack. There is pretty much one type of frame at the data link layer (i.e. an Ethernet frame), with all of the real 'interesting' stuff going on in layer 3 and above. However, when looking at 802.11 wireless packet capture and decoding, there are a whole host of different frames types at layer 2 that we might see. ( As a side note, layer 3 and above are often inaccessible to us in wireless captures as the payload of our layer 2 frames may be encrypted, rendering upper layers impossible to view. ) There are actually 3 types of frames we might see at layer 2 when performing a wireless capture: Management frames - these frames are used by wireless stations to join and leave a wireless network Control frames - these are used to assist with the delivery of data frames Data frames - these contain the actual higher-layer data that we want