Setting up a reliable and secure wireless network is a key part of today’s infrastructure. It has always been a need but with the massive increase of BYOD and corporate owned mobile devices it has become a necessity.
With this in mind having a way to authenticate users without having to individually input a shared wireless key is a big time saver along with being a lot more secure. If someone discovered what the pre-shared key was and shared it (assuming you don’t have any other security in place (MAC filtering, VLANs, etc.)) anyone could gain access to your network.
This is where the benefit of RADIUS authentication comes in. Now RADIUS isn’t a new technology and has been around for years. However it is still a very effective way to control access to a network. As well as using it to authenticate users on a wireless network it can and is used for the same purpose on VPN’s and wired connections.
For use in a wireless network your wireless access points need to support WPA/WAP2 Enterprise security. These will act as your RADIUS clients, sending any authentication requests for access to the wireless network to the RADIUS server to do the AAA (Authentication, Authorisation and Accounting).
You will also need a server to act as your RADIUS authentication server. This will process requests based on the policies and conditions you setup to decide whether a client can connect to the wireless network or not. You are also able to configure a RADIUS accounting server which will keep a log of any access requests.
Once this is setup it will allow or deny users access to the wireless network using their active directory accounts. This eliminates the need to input a pre-shared key on each device reducing the risk of unauthorized parties learning it.
The other major benefit of this is that it can be configured to allow your domain’s machine accounts to authenticate automatically. This means they can connect to your Wi-Fi without the need to manually attach each device. The Wi-Fi profile can also be pushed out using group policy or SCCM allowing central management (however this does rely on an initial connection to the network to receive the update).
For this setup I am going to use a Windows Server 2016 server with ‘Network Policy and Access Services’ installed. However as RADIUS is a standard you can achieve the same goal with a LINUX server using a product like ‘FreeRADIUS’.
Before you start the process it is useful to sort an SSL certificate first. For this example I requested a certificate from our internal Certificate Authority to use on the RADIUS server. This means it is already trusted by all the machines in the domain. However you can use the default self-signed SSL certificate that the server generates for initial setup and testing.
The first thing to do is install the ‘Network Policy and Access Services’ server role by doing the following. In server manager click ‘Add roles and features’ and click ‘Next’ until you reach the ‘Server roles’ page. Once here select ‘Network Policy and Access Services’:
Once you have selected this you will be prompted to add the dependant features for the role to function, click ‘Add Features’:
Click ‘Next’ until you reach ‘Confirm installation selections’ page and click ‘Install’:
Once this has finished installing open ‘Network Policy Server’ from the start menu:
The first thing we want to do is register this NPS with our active directory. We do this by right clicking the top of the tree and then clicking ‘Register server in Active Directory’:
(In this example it is shown as greyed out because I have done this step already)
Next we want to create a template for your shared secrets. All of the RADIUS clients that will authenticate with the server will need this shared secret so that they can authenticate. In the long run it is easier to create a template with this in to save entering it on each RADIUS client we setup.
Expand ‘Template Management’ and right click on ‘Shared Secrets’ and click ‘New’:
Give the template a name and either enter your own shared secret or click the ‘Generate’ radial button and then click ‘Generate’ at the bottom.
Make a note of the share secret, this is needed later.
This will create you one as seen below. If you hover over the yellow warning sign you will see a message telling you that it may be too long for some clients. If this is the case you can shorten the shared secret to a more appropriate size or create your own. Click ‘OK’ to save:
Next under ‘RADIUS Clients and Servers’ right click ‘RADIUS Clients’ and click ‘New’:
Fill this out with the relevant information, under ‘Address’ enter the IP address of your first RADIUS client. This will be the address of your first wireless access points. Under ‘Shared Secret’ select the template we created earlier and click ‘OK’:
Repeat this process for any of your wireless access points you want to act as RADIUS clients. Once you have done this, any you have added will be listed:
Now that all the RADIUS clients are setup we need to setup the access policy. With the top of the tree selected, on the right hand side under ‘Standard Configuration’ you need to select ‘RADIUS server for 802.1X Wireless or Wired Connections‘ from the drop down list and then click ‘Configure 802.1X’ below:
Select ‘Secure Wireless Connections’ and give it a suitable name at the bottom and click ‘Next’:
On the next screen you should see a list of RADIUS clients which we setup earlier, so we don’t need to do anything here. Click ‘Next’:
From the drop down list select ‘Microsoft: Protected EAP (PEAP)’ and then click ‘Configure’:
Here you can specify the certificate you would like to use to secure the connection using the drop down menu. I had already requested a certificate for this purpose which I selected. However you can use the default self-signed one for now. Click ‘OK’ and then click ‘Next’:
At this stage you can specify which domain groups will be given access to the wireless network. Click ‘Add‘ and search for any domain groups you would like to add and then click ‘Next‘:
On the last page confirm your settings and click ‘Finish’:
You will now see under the ‘Network Policies’ section that a new policy has been created:
If you double click on this policy you can see the settings that are in force:
Under the ‘Conditions’ tab you can see what conditions are required to connect to the wireless network. In this example anyone who is a member of the DOMAIN\Staff group will be authorised.
At this stage you can add, edit or remove groups using the buttons below. If we were to add the DOMAIN\Domain Computers group any machine on the network could authenticate and connect to the wireless network with its machine account:
Going a step further you can create another policy to deny access to the wireless network. The easiest way to create another policy is to duplicate the first one. Do this by right clicking the first policy and clicking ‘Duplicate Policy’:
Under ‘Overview’ tick the ‘Policy enabled’ box and change the ‘Access Permission’ to ‘Deny access’:
Under the ‘Conditions’ tab click on the current windows group and click ‘Edit’. Remove the DOMAIN\Staff group and add the group containing users you don’t want to have access to the wireless network. Click ‘OK‘ and then click ‘OK’ again:
On the ‘Network Polices’ page right click the newly created deny policy and move it to the top if it isn’t there already so that it has the processing order of ‘1’.
Policies are processed from the top down so the deny policy will be processed first. Denying any user who meets the conditions of the policy even if they are also a member of the group that is listed in the allow policy:
You can at this stage click on the ‘Accounting‘ section and enable this RADIUS server to act as an accounting server too, keeping logs of any connection requests. This is either in the format of a log file or an SQL database.
The next step is to configure the wireless access points to pass authentication requests to our newly configured RADIUS server. The setup and process will differ depending on the brand of access point you are using.
I am going to use is a Ubiquiti UniFi system. These are all centrally managed so configuring individual access points isn’t necessary as all changes are pushed out to each access point by the central controller. However if you are using a brand that requires each access point to be configured separately you would have to do the same thing on each one.
On the UniFi system after logging into the controller I navigate to Settings > Profiles and click ‘Create New RADIUS Profile’.
Give the profile a suitable name and enter the IP address of the RADIUS authentication server we just setup along with the shared secret we created with it. I also have the option of adding a RADIUS accounting server (if you set it up), which is at the same address as the authentication server and click ‘Save’:
Under Settings > Wireless Networks I can add a new wireless network by clicking ‘Create New Wireless Network’. Specify a suitable name for your wireless network (SSID), tick the ‘Enable’ box, change the ‘Security’ to ‘WPA Enterprise’, select the ‘RADIUS Profile’ we created on the last step and click ‘Save’:
These settings are now provisioned to all the wireless access points in this wireless group, which for me is all of them.
The wireless network is now visible and we can attempt to connect as normal:
Now enter a username and password for a valid domain account that is a member of the group you specified earlier in the allow policy.
Depending on the model of phone you will get more of less detail at this stage. On an Android phone you need to manually specify the certification authority certificate when joining the network that will validate the server certificate we selected earlier during the setup process. This has to be installed manually first. For testing purposes you can use the drop down list and select ‘Don’t validate’:
On an iOS device initially you will just be asked for a username and password and then asked if you trust the server certificate. If you have preinstalled the CA certificate beforehand and enabled full trust for it you won’t be asked.
Providing all the details are valid the device will connect to the wireless network as it would with any other:
For any windows domain joined devices such as tablets or laptops you will have 2 options to connect depending on your setup.
First, If you specified DOMAIN\Domain Computers earlier in the conditions of the allowed policy the devices will be able to authenticate using their machine accounts.
You can just click the wireless network and it will seamlessly connect authenticating in the background with its machine account. Using group policy or SCCM you can deploy the wireless profile centrally making each Windows device connect automatically without user intervention. However this does require an initial connection to the network (wired or wireless) to receive the GPO or SCCM update.
If you didn’t specify the DOMAIN\Domain Computers group earlier a user account is required to access the network. The second option is when a user tries to connect to the wireless network they will be asked for a username and password. If they are already logged in as a domain user they can select the option to connect using the currently logged in user. Providing the user is a member of the correct group the device will connect to the wireless network, authenticating with that users credentials.
Eliminating the need for a pre-shared key gives you much more control over who has access to your wireless network. Other conditions can be specified under a policy as well as windows groups such as times of the day, IP address ranges, etc. If a user leaves or is compromised there account can be disabled or their password changed to deny them further access to the wireless. Policies can be tailored to your specific needs giving you a lot more flexibility.
