Azure AD, AAD DS & RADIUS (NPS)

This is something that has been on my bucket list for a while. I’ve always been interested in running a Wi-Fi network with WPA2 Enterprise security, authenticating against a RADIUS server that is linked up to Active Directory. Active Directory and RADIUS integration is nothing new, however the added challenge of my setup was that I had no on-prem AD. I had a cloud-only tenant using Azure AD as the sole ‘identity provider’.

For the Wi-Fi networking infrastructure, we recently switched to UniFi rather than bridging a million household routers all over the place. We now have a USG and 4-5 access points to service the church property made up of around 4 separate buildings.

So how do you deploy a RADIUS server with Azure Active Directory integration, when AAD doesn’t actually provide native support for RADIUS itself?

Through a lot of research, I initially came across a brilliant tool - freeradius-oauth2-perl - which allows you to setup a FreeRADIUS server that communicates with Azure AD via OAuth2. I spun this up on a $5 Vultr instance for testing. After a lot of experimenting, it worked perfectly, with one catch - you must use EAP-TTLS. That in itself wasn’t much of a problem as most devices natively support EAP-TTLS, but it was a massive barrier if we had to configure each device either manually or get people to install a profile in order to connect devices to the network.

I looked for alternative solutions and ultimately decided to deploy Azure AD Domain Services, along with a Windows Server 2019 VM on the same subnet running NPS. A word of warning though - AADDS doesn’t come cheap especially for small businesses & organisations. The lowest-tier Standard SKU is priced at US$0.15/hour, which adds up to just over US$100/month. For a handful of users, that’s not exactly sustainable.

Luckily if you’re a non-profit organisation you can apply for a $3500 USD Azure credits grant each year. My church after 5 months still hadn’t figured out any use for the credits, so I decided to spend some of it on this setup.

For the Windows Server 2019 Datacenter VM, I put it on the cheap Standard B1s plan which costs roughly $6/month.

After deploying both AADDS (follow this guide ) & the Windows Server VM, fixing DNS server settings on the vnet and configuring your firewall correctly, login to the Windows VM and domain-join the VM to AADDS. This will require a restart.

Once you’re back in, you’ll want to add a certificate to NPS in order to authenticate clients using PEAP. You can install one you already have (NPS doesn’t play nice with wildcard certificates) or generate a self-signed one. To generate a self-signed one, go to PowerShell as an administrator and run:

$cert = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname nps.mydomain.tld

This will install the cert in the Personal store of the server. Make sure you specify both the server name and domain name as the DNS name or else authentication won’t work.

Next, add the NPS role to the VM and deploy the RADIUS server. You need to add your public on-prem IP as a RADIUS client under ‘RADIUS Clients’ in NPS first (right-click and click ‘New’). Fill in a friendly name, the public IP (note that you cannot use your AADDS domain due to the vnet DNS configuration) and a secure shared secret.

I would recommend using the configuration wizard on the initial NPS start page - select ‘RADIUS server for 802.X Wireless or Wired Connections’ in the dropdown, and then ‘Configure 802.X’.
For the connections type, select ‘Secure Wireless Connections’ and name your policy as appropriate.
Click next on the switches page, this simply lists the RADIUS clients you configured earlier.
Select ‘PEAP’ as the authentication method, click ‘Configure’ and then select the certificate you installed earlier.
On the next page, you can choose to allow or deny authentication to specific groups of users.
Skip the traffic controls unless you want to configure VLAN settings, then finish the wizard.

To help secure your configuration, go to Policies -> Network Policies and then find the policy that the wizard configured. Go to its properties and ensure that ‘Ignore user account dial-in properties’ is checked.
Under Constraints -> Authentication Methods, make sure that only MSCHAP-v2 is selected, and under Settings -> Encryption, uncheck everything except for ‘Strongest encryption’.

If you’re using Windows Server 2019 (doesn’t apply to any older versions), the default firewall rule for RADIUS is faulty, so you’ll need to configure a new one to allow RADIUS requests. Go to Windows Firewall advanced settings, add a new inbound rule that controls ‘Port’ connections for UDP and port 1812. Allow the connection on Domain networks and name it as appropriate (i.e. Allow UDP 1812).

If your vnet firewall is configured correctly to allow RADIUS connections, you should be ready to go.

For troubleshooting, you may want to enable accounting in NPS and check the certificates used. NPS doesn’t like every certificate so try using a self-signed one if you’re really stuck.