FreeRADIUS on Ubuntu 24.04 on Azure User Guide

Overview

This guide covers the deployment and configuration of FreeRADIUS on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images. FreeRADIUS is the most widely deployed RADIUS server in the world. It provides centralised authentication, authorisation and accounting (AAA) for network access: Wi-Fi access points, VPN concentrators, 802.1X switches and captive portals all ask FreeRADIUS whether a user may connect, and record how long they were connected.

The image installs FreeRADIUS 3.2 from the official Ubuntu 24.04 apt archive, run under systemd as the dedicated non root freerad user. FreeRADIUS answers RADIUS authentication on UDP port 1812 and accounting on UDP port 1813 across all interfaces. There is no web interface and no database in this image: the configuration tree under /etc/freeradius/3.0 plus a flat user file are the whole configuration.

Secure by default — no known bootstrap credential. The stock FreeRADIUS package ships a well known client shared secret, testing123, and a demonstration bob user. Neither ships in this image. On the first boot of every VM a one shot service generates a unique random shared secret for the built in localhost client and a unique sample user and password, writes them to a root owned credentials file, and removes testing123 from the entire configuration. No two instances share a credential.

What is included:

• FreeRADIUS 3.2 from the Ubuntu 24.04 apt archive, run under systemd as the unprivileged freerad user (freeradius.service)

• A RADIUS authentication listener on 0.0.0.0:1812 and a RADIUS accounting listener on 0.0.0.0:1813, both over UDP on all interfaces

• A per instance unique shared secret for the built in 127.0.0.1 client and a unique sample user and password, generated on first boot and written to /root/freeradius-credentials.txt (mode 0600)

• The standard files and pap authorisation flow, so a PAP client such as radtest authenticates the sample user out of the box

• A clean clients.conf that includes the clients.d/ directory, so you add each NAS device as its own small configuration file

• The well known testing123 shared secret and the demonstration user removed from the whole configuration tree

Prerequisites

• A VM launched from this cloudimg FreeRADIUS image on Azure.
• An Azure Network Security Group that allows UDP 1812 and UDP 1813 inbound from your NAS devices only (access points, switches, VPN concentrators). Do not expose RADIUS to the public internet.
• SSH access to the VM as azureuser.

RADIUS clients authenticate with a shared secret, so treat the shared secret like a password and scope the NSG rules to the source addresses of your network equipment.

Verify the RADIUS server is running

Connect over SSH as azureuser, then confirm freeradius.service is active and listening on the authentication and accounting ports.

sudo systemctl is-active freeradius
sudo ss -uln | grep -E ':1812 |:1813 '

You should see active, and listeners bound to 0.0.0.0:1812 (authentication) and 0.0.0.0:1813 (accounting), plus their IPv6 equivalents.

Retrieve the per instance credentials and test authentication

On the first boot of your VM, FreeRADIUS generated a unique shared secret and a unique sample user and password. They are stored in the root owned credentials file:

sudo cat /root/freeradius-credentials.txt

The file contains RADIUS_SECRET, SAMPLE_USER and SAMPLE_PASSWORD, each unique to this VM. Test authentication end to end with the bundled radtest client, which reads those values and sends a PAP Access-Request to the built in localhost client:

RADIUS_SECRET=$(sudo grep '^RADIUS_SECRET=' /root/freeradius-credentials.txt | cut -d= -f2-)
SAMPLE_USER=$(sudo grep '^SAMPLE_USER=' /root/freeradius-credentials.txt | cut -d= -f2-)
SAMPLE_PASSWORD=$(sudo grep '^SAMPLE_PASSWORD=' /root/freeradius-credentials.txt | cut -d= -f2-)
radtest "$SAMPLE_USER" "$SAMPLE_PASSWORD" localhost 0 "$RADIUS_SECRET"

The server returns Access-Accept with the reply message configured for the sample user, proving the RADIUS pipeline (client shared secret, users backend and PAP authentication) works end to end.

Confirm invalid credentials are rejected

A correctly configured RADIUS server must reject bad credentials. This image also removes the well known testing123 shared secret that ships with the stock package. The block below tests that a wrong password is rejected:

RADIUS_SECRET=$(sudo grep '^RADIUS_SECRET=' /root/freeradius-credentials.txt | cut -d= -f2-)
SAMPLE_USER=$(sudo grep '^SAMPLE_USER=' /root/freeradius-credentials.txt | cut -d= -f2-)
RESULT=$(radtest "$SAMPLE_USER" "the-wrong-password" localhost 0 "$RADIUS_SECRET" 2>&1 || true)
echo "$RESULT" | grep -q 'Access-Reject' && echo "A wrong password is correctly rejected (Access-Reject)."

A request with the wrong password returns Access-Reject, and a request signed with the old testing123 shared secret does not authenticate, because that secret is no longer present anywhere in the configuration.

Add a RADIUS client (a NAS device)

Every network device that authenticates users through FreeRADIUS is a RADIUS client (a NAS, network access server) and needs its own shared secret. The shipped clients.conf includes the clients.d/ directory, so you add one small file per device:

sudo cat /etc/freeradius/3.0/clients.conf

To authorise, for example, a wireless access point at 192.0.2.50, create a file such as /etc/freeradius/3.0/clients.d/office-ap.conf with a client block. Choose a long, random shared secret and configure the same secret on the access point:

client office-ap {
    ipaddr = 192.0.2.50
    secret = choose-a-long-random-shared-secret
    nas_type = other
}

You can also authorise a whole subnet of devices by giving ipaddr a CIDR such as 10.20.0.0/24. After adding or changing a client, restart the service so it re reads the configuration:

sudo systemctl restart freeradius

Add a user

This image uses the simple flat files backend. Users live in /etc/freeradius/3.0/mods-config/files/cloudimg-users, which is included from the standard authorize file. Add one entry per user. For a PAP user with a cleartext password, add a block like this (the continuation lines must be indented):

alice   Cleartext-Password := "choose-a-strong-password"
        Reply-Message := "Welcome, %{User-Name}"

You can attach reply attributes such as a VLAN assignment for 802.1X by adding Tunnel-Type, Tunnel-Medium-Type and Tunnel-Private-Group-Id reply items. After editing the users file, restart the service:

sudo systemctl restart freeradius

For production directories, point FreeRADIUS at an LDAP or SQL backend instead of the flat file by enabling the ldap or sql module under /etc/freeradius/3.0/mods-enabled/ and adjusting the authorize and authenticate sections. For enterprise Wi-Fi and wired 802.1X, enable the eap module and configure the EAP methods your clients use.

Point your NAS devices at the server

On each access point, switch or VPN concentrator, configure the RADIUS server address (this VM's private or public IP), the authentication port 1812, the accounting port 1813, and the shared secret you set for that device in its clients.d/ file. Keep the NSG rules scoped to your equipment, rotate shared secrets periodically, and prefer EAP methods over PAP for wireless authentication.

Support

cloudimg provides 24/7 technical support for this FreeRADIUS image by email (support@cloudimg.co.uk) and live chat. We help with adding RADIUS clients and users, migrating to LDAP or SQL backends, configuring EAP and 802.1X for enterprise Wi-Fi, RADIUS accounting, reply attributes such as VLAN assignment, version upgrades and troubleshooting. Critical issues receive a one hour average response time.

All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.