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.


Saturday, 15 March 2014

Microsoft NPS as a RADIUS Server for WiFi Networks: Self Signed Certificate

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 (perhaps in a lab or POC environment) and just put on your own self-signed certificate, instead of having the additional overhead of getting CA servers etc. going.

Finding out how to create and install your own self-signed certificate is not that easy to do, so I thought I'd document the process I managed to get going recently, which may help someone save themselves some time at some point.

To carry out this process, you will need:
  • a copy of OpenSSL
  • an NPS server
I personally use Windows as my main platform, so getting hold of OpenSSL can be a bit of a challenge. There is a Windows distribution available, but I prefer to run it within Cygwin (as I had a few issues with the native Windows distribution). If you go down the Cygwin route, you will need to add the OpenSSL package after installing Cygwin ( Don't worry, you can do it direct from the Cygwin installer). If you're on any Linux/Unix based platforms, you will have to install OpenSSL using the method that applies to your platform.

Create The Certicate

Once you have OpenSSL installed and working, you will need to enter the following command from a CLI to create your certificate and private key file:

openssl req -x509 -sha256 -nodes -days 1826 -newkey rsa:2048 -extensions v3_req -keyout Your-hostname.key -out Your-hostname.crt
This will prompt you for a number of fields that you need to complete. The output is shown below:

Loading 'screen' into random state - done
Generating a 2048 bit RSA private key
......+++
.....................................................................................+++
writing new private key to 'Your-hostname.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:GB
State or Province Name (full name) [Some-State]:Staffordshire
Locality Name (eg, city) []:Stafford
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Acme-Wireless
Organizational Unit Name (eg, section) []:Janitors
Common Name (e.g. server FQDN or YOUR name) []:your-hostname.domain.com
Email Address []:me@here.com

When completing the information above, the one field you must get right is the 'Common Name' field. This may be used when doing hostname checking during the EAP process.

This will create 2 files :
  • Your-hostname.key (the private key file)
  • Your-hostname.crt (the certificate)
Obviously, in the examples above, you substitute your own hostname. The file naming does not affect the operation of the certificate and is just for reference.

Next, we combine the private key and certificate in to one file so that we can install both on to the NSP server. This is done with the following OpenSSL command:

openssl pkcs12 -in Your-hostname.crt -inkey Your-hostname.key -export -out Your-hostname.pfx

When you enter this command, you will be prompted to enter a password. This will be used to import the certificate in to NPS, so don't forget it!!!

Once this command has been executed you will have a third (and final) file that will be imported as your final certificate on to NPS (in this case, 'Your-hostname.pfx')

Importing the Certificate in to the NPS Server

We now have our PFX file which we can import in to NPS. The first thing to do is to copy the PFX file we created on to the NPS server (if it's not already on there).

Now, we need to import the file in to the machine certificate store of our NPS server. So, we fire up MMC (usually by typing 'mmc' in a command box) and Add in the certificate snap-in for the computer account of the local machine (as shown below) :






 Once we have the snap-in loaded, we need to navigate to the Personal folder of the certificate store (seel below). This is where we want to import our newly created certificate.

Once we have located the folder, right-click and select 'All Tasks > Import': 


When prompted, select the PFX file that we created (note you have to change the file-type drop-down in the file type selector to 'Personal Information Exchange' to see the certificate file listed:

  
 Select the file and step through the import wizard as shown below You will need to enter the password you entered when creating the PFX file to be able to import it (I told you you'd need it!):






Once the wizard is completed, you should end up with the certificate imported as shown below:


If you now double-click on the certificate that you see above, you will see the properties of the certificate itself:

We need to make a minor update to the properties of the certificate for it to work with NPS. Select the 'Details' tab of the certificate:


Hit the 'Edit Properties' button:


We need to alter the certificate purposes to support only 'Server Authentication' and 'Client Authentication'. To do this, hit the 'Enable only the following purposes' radio button and de-select all roles except 'Server Authentication' and 'Client Authentication':


Once the changes are made and you've hit 'OK', we need to copy the certificate across to the 'Trusted Root Certificate Authorities' folder of the certificate store. Without this, the certificate will not be trusted by NPS as a root CA (and won't work). Copy the certificate as shown below:




If you create a policy in NPS that uses either PEAP or EAP-TLS, when you edit the properties of the EAP method in your policy, you should now be able to select the certificate that you have created and imported:


Exporting the Certificate for Client Devices

Once we have the certificate installed on our NPS server, we need to make sure we have a copy of the certificate to install on to our clients. The certificate will need to be placed in to the 'Trusted Root Certificate Authorities' folder of the certificate store on each client. To export the certificate, follow the steps below to create a copy of the certificate that can be imported on to your wireless clients:





(Note: There are a number of methods and tools for achieving what is described in this article, so please do not take this as the definitive method for achieving this goal. Some methods include using the IIS 6.0 server resource kit, but I would not recommend that method as the  key lengths for the certificates that can be generated are only 1024 bits - I believe that the recommended length is now 2048 bits)