To setup and install a RADIUS server in Azure for wireless authentication use our Azure marketplace solution. The server comes configured with Microsoft Server NPS and has all the required firewall ports configured allowing you to quickly deploy a RADIUS Server into your Azure tenant. You’ll be able to add your wireless APs as clients and authenticate your wireless or VPN users using Active Directory. Define different access policies and security polices within Network Policy Server.
Azure RADIUS Server
Cloud Radius Server Authentication Solution
Setup RADIUS Server 2016 in Azure
Setup RADIUS Server 2019 in Azure
Also checkout – freeRADIUS with daloRADIUS – Supports Azure AD Authentication
Getting Started with RADIUS
Once you have deployed our Azure RADIUS server to your Azure tenant, you are now ready to configure it for wireless authentication with your Active Directory. At the moment Azure AD DS doesn’t support the ability to register services with Azure Active Directory Domain Services (Azure AD DS), if you require Azure AD authentication, checkout our other cloud radius server that supports Azure AD authentication. For Active Directory authentication, you will need to deploy a domain controller into Azure
Â
Open ‘Network Policy Server’ from the desktop or administrative tools:
Register NPS with Active Directory
The first thing you want to do is register this NPS with your 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 haven’t added to AD yet. If you see the same add to your domain and then come back to this step)
Create Shared Secrets
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:
Create RADIUS Clients
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 NPS Server
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:
Â
- 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.
Â
- 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.
Â
- 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. Steps below on how to generate a self signed certificate.
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 Certificate to Local Computer > Personal
Once a certificate has been acquired, these are the instructions on how to import a certificate.
Â
- Right-click the Start button and click Run
- Type mmc and hit Enter
- Hit Ctrl+M (or click File -> Add/Remove Snap-in…)
- Select Certificates from the Available snap-ins and click Add >
- Select Computer account and click Next, then Finish
- Expand Certificates (Local Computer) -> PersonalÂ
- Right-click Personal > All Tasks > Import – Select Local Machine, click next and browse to where you’ve saved your certificate.Â
- Follow the wizard to import your certificate.
This option is not recommended for production deployment, due to dramatically reduced security.
Setup 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 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.
Cisco Meraki RADIUS Authentication
I am 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 Azure 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 from 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.
Deploy a PEAP Wireless Profile using AD Group Policy (Optional)
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 2016:
Â
- 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
Once you’ve deployed the wireless profile to users or manually setup one on a test machine, we can now test connecting.
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:
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.
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 Azure:
Â
RADIUS Authentication and Authorization
UDP:Â 1812 /Â 1645
Â
RADIUS Accounting
UDP: 1813 / 1646
Â
You also need to make sure the RADIUS server in Azure can communicate with your Active Directory
Â
If you are using Azure NSG and need to change / add ports refer to the following guides:
Â
To setup Azure firewall rules refer to – Azure Network Security Groups
RADIUS Server Support
If you have any questions about the setup of our RADIUS authentication solution in Azure, leave your comments below and we will reply within 24 hours or contact us directly.
Hello Andrew,
Thank you for the article.
I added my vm with NPS to my Azure Active Directory Domain Service yet the “Register server in Active Directory” option remains grey. Can you offer any direction to help?
Hi Hamish. Sure, you will need on-prem Active Directory in order to register the NPS server with Active Directory. Azure AD doesn’t allow users to register services directly into Azure AD. It has to be done with an on-prem Active Directory environment. The best way to do it is to setup a VM in Azure and setup Active Directory and sync on-prem AD to Azure AD.
Hi andrew, will this work with if i have azure Ad domain services instead of a domain controller on vm on azure, i am looking to have ldap integeration with meraki for wirless contollers authentication, appreciate your feedback
Hi Rami,
At the moment Azure AD domain services doesn’t allow users to register services with Azure ADDS. The only way round it is to deploy a domain controller on Azure and register it with your Active Directory
Thank you
Andrew
Great, thanks.
i am looking to setup a vmx in Azure for VPN Connectivity and Radius Server with Domain Controller Vms as you suggested, what about MFA with Azure AD will we be able to do that from the Radius?
Hi Rami, yes you simply install the NPS extension for Azure AD MFA onto our RADIUS VM. The following article explains how to install the NPS agent onto our RADIUS Server in Azure: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension