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)

Friday, 14 March 2014

Microsoft NPS as a RADIUS Server for WiFi Networks: RADIUS Client Limits

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 controller-based WiFi networks (e.g. Cisco, Meru, Aruba), the controller is generally the source of the RADIUS requests (i.e. the RADIUS client). If you have a WiFi network of 4 wireless controllers and 200 access points, you just add the 4 controllers as RADIUS clients in NPS. The diagram below demonstrates this point - there is one controller, therefore one RADIUS client:


However, if you are using a WiFi architecture which does not use a controller (e.g. Aerohive, Xirrus, AirTight), then each AP is the source of RADIUS requests (i.e. the RADIUS clients). If you have a network work of 200 APs, you need to add 200 RADIUS clients to NPS. The diagram below shows how APs become RADIUS clients in a controller-less network:



(Note: there are also some other cases, such a Cisco's Flexconnect, where the controller is the RADIUS client in normal operation, but the APs take-over that role in a controller failure situation - yeah, confusing...)

In Windows 2008, there is a restriction when using NPS with the 'Standard' edition which may cause an issue. When using the Datacenter or Enterprise versions of Windows 2008, NPS can support an unlimited number of RADIUS clients, and will also support IP ranges for RADIUS clients (which is useful if you have a lot of APs and they are all on the same subnet).

The Standard edition, however, can only support 50 RADIUS clients and does not allow ranges of IP addresses for RADIUS clients.

The limitation with the Standard edition is rarely an issue in controller-based networks, as there are generally a very low number of controllers. However, when using non-controller WiFi solutions, you may well hit the 50-device (i.e. AP) limit. In summary, if you are using more than 50 APs in a controller-less deployment, Windows 2008 Standard edition will not meet your needs - you must deploy the Enterprise or Data Centre edition.

The following document from Microsoft details the limitations: http://technet.microsoft.com/en-us/library/cc770442(v=ws.10).aspx

Windows 2012

Finding the corresponding information for Windows 2012 is a little bit more tricky. However, I did manage to dig out this document which seems to indicate varying numbers of clients depending on the edition (wow, there are a lot of them). Check out the line titled: "IAS Connections" in this document: http://www.microsoft.com/en-sg/download/confirmation.aspx?id=38809

I have summarized the information below:


Edition
Max IAS (NPS) Connections
Windows Server 2012 Datacenter
2,147,483,647
Windows Server 2012 Standard
2147483647
Windows Server 2012 Essentials
10
Windows Server 2012 Foundation
10
Microsoft Hyper-V® Server 2012
50
Windows Storage Server 2012 Standard
50
Windows Storage Server 2012 Workgroup
50
Windows MultiPoint Server 2012 Premium
2,147,483,647
Windows MultiPoint Server 2012 Standard
10

Beyond the PDF document I have linked to above, I can't find any other official references to the 2012 limitations around NPS - if you find any, please add them in the comments section of this article.