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)

Popular posts from this blog

The 5GHz “Problem” For Wi-Fi Networks: DFS

-
Image
Wi-Fi networking provides us with 2 bands for the operation of wireless LAN networks: the 2.4Ghz band and the 5GHz band. The 2.4GHz band has a reputation of being something of a “sewer” of a band, due to its limited number of usable channels, the number of Wi-Fi devices already using the band, and the high levels of non-Wi-Fi interference that it experiences. Many wireless LAN professionals will generally advise that you put your “important stuff” on the 5GHz band whenever possible. 5GHz has far more channels available, a corresponding lower number of devices per channel, and generally suffers much lower non-Wi-Fi interference. However, beneath the headline of “2.4Ghz = bad, 5Ghz = good”, there lurks a shadowy figure that can be troublesome if you’re not aware of its potential impact: DFS. Background Wi-Fi networks operate in areas of RF spectrum that require no licence to operate. This is in contrast to many other areas of the radio spectrum that generally require some form of (p
Read more

What Are Sticky Clients?

-
Image
One term you'll often hear banded about when talking with Wi-Fi professionals is "sticky clients". I thought it might be worth spending a few moments exploring what is meant by "sticky clients", why they are generally considered to be a bad thing in Wi-Fi networks and some approaches to mitigate them. Background Many folks dealing with Wi-Fi networks often talk about the "sticky" characteristics of wireless clients when discussing client roaming within a W-iFi network. In an ideal world, we'd like to have access points providing ubiquitous coverage across our desired area providing high-quality, consistent client coverage where-ever we go. In this wonderful land of rainbows and unicorns, our clients would gracefully roam from AP to AP, detecting and associating with their closest AP throughout the coverage area to ensure their best connection speed at all times. Unfortunately, the real world doesn’t quite reflect this roaming-client
Read more

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
Read more