How to Setup AWS RADIUS Server (NPS) Cloud RADIUS for Wireless Authentication
To setup and install a Cloud RADIUS Server running NPS in AWS running on Windows Server, the easiest and quickest way is to our AWS RADIUS NPS Server solution in the AWS marketplace. Launch the image direct from the marketplace. Perfect solution for providing wireless authentication for your access points (APs).
This AWS RADIUS server solution uses Network Policy Server (NPS) to perform centralized authentication, authorization, and accounting for wireless, authenticating switches, remote access dial-up or virtual private network (VPN) connections. When you use NPS as a RADIUS server, you configure network access servers, such as wireless access points or VPN servers, as RADIUS clients in NPS.
- Authenticate wireless users and control access to your wireless APs based on user, IP, device, AD groups and more
- Unlimited number of RADIUS clients (APs) and remote RADIUS server groups
- Single sign-on solution. Allow users to logon to wireless APs automatically
- Active Directory or local security accounts manager for authentication
- Allow or deny connections to specific wireless networks that you specify by network type and Service Set Identifier (SSID)
- Allow or deny connections based on AD group membership
AWS RADIUS Server
Cloud RADIUS Server Authentication Solution
Table of Contents
Getting Started with AWS RADIUS Server
Once you have deployed our RADIUS server solution from the AWS marketplace. The first step is to RDP into your new VM:
- Guide on how to RDP into an AWS instance
Next, Once you have logged into the AWS RADIUS server, you are now ready to configure it for wireless authentication with your Active Directory.
Open ‘Network Policy Server’ from the desktop or administrative tools:
The first thing you want to do is register this NPS with your AD active directory.
We do this by right clicking the top of the tree and then clicking ‘Register server in Active Directory’: (This can be your onprem Active Directory or AWS Directory Service).
In this example it is shown as greyed out because the AD have not been added.
If you see the same add to your domain and then come back to this step.
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, but first you need to make sure you have a certificate in the local computer store.
Add a Trusted Certificate to Network Policy Server (NPS)
A RADIUS server must host a certificate that allows both network clients and APs to validate the server’s identity. There are three options for this certificate:
1.) Acquire a certificate from a trusted Certificate Authority. As long as the CA used is trusted by clients on the network, a certificate can be purchased and uploaded into NPS to accomplish and server identity verification (required by clients). Common examples of trusted CAs include GoDaddy and VeriSign.
2.) Implement a Public Key Infrastructure and generate a certificate (advanced)
A PKI can be used on the network to issue certificates trusted by clients on the network. A strong understanding of PKI is recommended for this option.
3.) Generate a self-signed certificate and turn off client server validation (insecure)
A self-signed certificate can be generated for testing/lab purposes, though clients will not trust a self-signed certificate and will need to have server validation disabled in order to connect.
Create a Self Signed Certificate
If you don’t have a PKI or a certificate from a third party, you can create a self signed certificate using the built-in powershell module.
Open up Powershell.exe as Administrator and run the following command
New-SelfSignedCertificate -DnsName "RADIUS FQDN" -CertStoreLocation "cert:\LocalMachine\My"
Example:
New-SelfSignedCertificate -DnsName "fs.Test.local"-CertStoreLocation "cert:\LocalMachine\My"
Import Self Signed Certificate
Steps below on how to generate a self signed certificate.
Once a certificate has been acquired, these are the instructions on how to import a certificate.
- Right-click the Start button and click Run.
2. Type mmc and hit Enter
3. Hit Ctrl+M (or click File -> Add/Remove Snap-in…)
4. Select Certificates from the Available snap-ins and click Add >
5. Select Computer account and click Next, then Finish.
6. Expand Certificates (Local Computer) -> Personal .
7. Right-click Personal > All Tasks > Import – Select Local Machine, click next and browse to where you’ve saved your certificate.
8. Follow the wizard to import your certificate.
This option is not recommended for production deployment, due to dramatically reduced security.
Setup RADIUS NPS Access Policy
Now lets 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‘:
The next page allows you to configure traffic controls. Here you can setup VLANS and access control lists to control traffic. You will need to refer to your AP manufacturer if they support these options, as this page is optional or you can configure later if you need these settings configured. Press Next to continue
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 authorized.
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.
Cisco Meraki RADIUS Authentication
We are going to use Cisco Meraki MR access points in this example.
Once a RADIUS server has been set up with the appropriate requirements to support authentication, the following instructions explain how to configure an SSID to support WPA2-Enterprise, and authenticate against the RADIUS server:
- In Dashboard, navigate to Wireless > Configure > Access control.
- Select your desired SSID from the SSID drop down (or navigate to Wireless > Configure > SSIDs to create a new SSID first).
- For Association requirements choose WPA2-Enterprise with my RADIUS server.
- Under RADIUS servers click Add a server
- Enter the Host (IP address of your RADIUS server, reachable from the access points), Port (UDP port the RADIUS server listens on for Access-requests; 1812 by default) and Secret (RADIUS client shared secret):
6. Click the Save Changes button.
Aside from the RADIUS server requirements outlined above, all authenticating APs will need to be able to contact the IP address and port specified in Dashboard.
Make sure that your APs all have network connectivity to the RADIUS server, and no firewalls are preventing access. Review the AWS firewall ports below
VLAN Tagging Options
Dashboard offers a number of options to tag client traffic from a particular SSID with a specific VLAN tag. Most commonly, the SSID will be associated with a VLAN ID, so all client traffic from that SSID will be sent on that VLAN.
With RADIUS integration, a VLAN ID can be embedded within the RADIUS server’s response. This allows for dynamic VLAN assignment based on the RADIUS server’s configuration.
Please refer to Cisco’s documentation regarding Tagging Client VLANs with RADIUS Attributes for configuration specifics.
Testing RADIUS Server from Meraki Dashboard
Dashboard has a built-in RADIUS test utility, to ensure that all access points (at least those broadcasting the SSID using RADIUS) can contact the RADIUS server:
- Navigate to Wireless > Configure >Access control.
- Ensure that WPA2-Enterprise was already configured based on the instructions in this article.
- Under RADIUS servers, click the Test button for the desired server.
- Enter the credentials of a user account in the Username and Password fields.
- Click Begin test.
- The window will show progress of testing from each access point (AP) in the network, and then present a summary of the results at the end.
APs passed: Access points that were online and able to successfully authenticate using the credentials provided.
APs failed : Access points that were online but unable to authenticate using the credentials provided. Ensure the server is reachable from the APs, the APs are added as clients on the RADIUS server.
APs unreachable: Access points that were not online and thus could not be tested with.
(Optional) Deploy a PEAP Wireless Profile using AD Group Policy
For a seamless user experience, it may be ideal to deploy a PEAP wireless profile to domain computers so users can easily associate with the SSID.
Though optional for user auth, this is strongly recommended for machine authentication.
The following instructions explain how to push a PEAP wireless profile to domain computers using a GPO, on a Domain Controller running Windows Server:
- Open the domain Group Policy Management snap-in.
- Create a new GPO or use an existing GPO.
- Edit the GPO and navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Wireless Network (IEEE 801.X) Policies.
- Right Click Wireless Network (IEEE 801.X) Policies and choose Create a New Windows Vista Policy.
- Provide a Vista Policy Name.
- Click Add for Connect to available networks.
- Choose Infrastructure.
- On the Connection tab, provide a Profile Name and enter the SSID of the wireless network for Network Name(s). Click Add.
- Click the Security tab. Configure the following:
- Authentication: WPA2-Enterprise or WPA-Enterprise
- Encryption: AES or TKIP
- Network Authentication Method: Microsoft: Protected EAP (PEAP)
- Authentication mode: Computer Authentication (for machine auth).
- Click Properties.
- For Trusted Root Certification Authorities select the check box next to the appropriate Certificate Authorities and click OK.
- Click OK to close out and click Apply on wireless policy page to save the settings.
- Apply the GPO to the domain or OU containing the domain member computers (refer to Microsoft documentation for details).
Once you’ve deployed the wireless profile to users or manually setup one on a test machine, we can now test connecting.
Testing Wireless Access Profile
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:
Single Sign On (SSO) For Windows Devices
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’re a lot more flexibility.
AWS RADIUS Server Firewall Ports
The following firewall ports will need to be open for each of your wireless access points (APs) to allow them to access your RADIUS / NPS server in AWS:
RADIUS Authentication and Authorization
UDP: 1812 / 1645
RADIUS Accounting
UDP: 1813 / 1646
To setup AWS firewall rules refer to – AWS Security Groups
You also need to make sure the RADIUS server in AWS can communicate with your AD Active Directory
Radius NPS Server Support / Further Documentation
Check out the following links for further documentation and support for Radius NPS Server:
https://docs.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-top
