How to set up a RADIUS server for WiFi authentication

A RADIUS server is what turns “one WiFi password for everyone” into per-user authentication. This guide sets one up end to end. It covers FreeRADIUS on Linux and Windows Server NPS, the access point side, the client side, testing, and the failures you will hit. It is vendor-neutral first, then specific.

What you need before you start

Do not open a config file yet. Get these first. Each one blocks the build if it is missing.

• An identity source. Where your users live: Active Directory, Entra ID, LDAP, or a local user file for testing.
• A certificate authority decision. EAP-TLS and PEAP both need a server certificate. Decide now whether you use your internal CA, a public CA, or a self-signed test CA. This decision shapes everything downstream.
• Admin access to the access point or controller. You will register the RADIUS client and set the shared secret there.
• A test client. One laptop and one phone. You test on both, because they fail differently.
• An IP plan. Static IP for the RADIUS server. Know which subnets the access points sit in.

Treat this as a gate. If any item is missing, stop and get it. Skipping the CA decision is the most common cause of a rebuild.

Choose your authentication method first, not your server

The authentication method constrains the whole design. Choose it before you install anything.

• EAP-TLS. Certificate on the client and the server. Mutual authentication, no password to steal. The most secure option, and the most work — you need a certificate on every device.
• PEAP-MSCHAPv2. Server certificate only. The client authenticates with a username and password inside a TLS tunnel. Easier to deploy because it reuses directory passwords. Weaker, and only as safe as its server-certificate validation.
• EAP-TTLS. Similar to PEAP, tunnelling other authentication methods. Common in mixed-vendor and education networks.

The trade-off is security versus onboarding effort. For the full comparison, see EAP-TLS vs PEAP. Pick the method here, because the server, the certificates, and the client config all follow from it.

Step by step: FreeRADIUS on Linux

FreeRADIUS is the standard open-source RADIUS server. This is the Linux path.

• Install it. On Debian or Ubuntu: apt install freeradius. On RHEL family: dnf install freeradius freeradius-utils.
• Register the access point as a client. Edit clients.conf. Add a block for each AP or controller with ipaddr set to the AP address, secret set to a long random string, and nastype = other. The secret here must match the shared secret you set on the access point.
• Set the EAP method. Edit mods-available/eap. Set default_eap_type to tls or peap, and point the tls-config paths (private_key_file, certificate_file, ca_file) at your server certificate, its key, and the CA that signed it.
• Connect the identity source. For a lab, add a test user in the authorize file. For production, enable the ldap or krb5 module and bind it to your directory, then reference it in the authorize and authenticate sections.
• Run it in debug mode. Stop the service and run radiusd -X (or freeradius -X). This prints every step of every request. You will live in this output while you get it working. When it is stable, run it as a service again.

Step by step: Windows Server NPS

Network Policy Server (NPS) is the Microsoft path. It fits an Active Directory or Entra-joined environment.

• Install the role. Add the Network Policy and Access Services role. Then register NPS in Active Directory so it can read user accounts.
• Add the access point as a RADIUS client. In the NPS console, under RADIUS Clients, add each AP or controller: a friendly name, its IP address, and a shared secret. The secret must match the AP.
• Create a Connection Request Policy. This decides which requests NPS handles locally versus forwards. For a single NPS, the default “authenticate on this server” policy is enough.
• Create a Network Policy. This is the real access rule. Set conditions (for example, membership of a Windows security group), constraints (the EAP type: Microsoft PEAP, or Smart Card or other certificate for EAP-TLS), and settings (the VLAN or filter to apply on success, via standard RADIUS attributes).
• Install a server certificate. NPS needs a certificate with the Server Authentication purpose, from a CA the clients trust. In an AD environment, issue it from Active Directory Certificate Services. This certificate is what the client validates during PEAP or EAP-TLS.

Configure the access point or controller

The server is only half of it. On the SSID, set WPA2-Enterprise or WPA3-Enterprise, then configure the RADIUS server IP, authentication port UDP 1812, accounting port UDP 1813 (enable accounting; it is what gives you session records), and the shared secret exactly as set on the server.

Add a second server for redundancy if you have one. This is also the point where, on a multi-site or cloud design, RadSec replaces plain RADIUS on the wire — see RADIUS vs RadSec. On a single trusted LAN, plain RADIUS is fine.

Configure the client supplicant

The client is where PEAP is made safe or left broken. The setting that matters is server-certificate validation. On every platform, the client must trust the CA that signed the server certificate (the trust anchor) and validate the server name against the certificate.

If you skip server-name validation, PEAP will still connect — and it will connect to a rogue server just as happily. That is the setting everyone skips and the one that makes password-based EAP safe.

• Windows — in the WiFi profile, enable “Verify the server’s identity by validating the certificate”, select the trusted root CA, and enter the server name.
• macOS — the first connection prompts to trust the certificate. Push a configuration profile to pin it in a managed fleet.
• iOS — same trust prompt on first join. Use a configuration profile to pre-install the trust and the server name.
• Android — recent versions require you to select the CA certificate and specify the domain. “Do not validate” is not a production option.

In a managed fleet, push these settings with your device management tool. Do not rely on users configuring them by hand.

Test and read the logs

• Basic connectivity: radtest testuser testpass 127.0.0.1 0 . This uses PAP and confirms the server answers. A successful reply is an Access-Accept.
• EAP testing: radtest does not test EAP. Use eapol_test (from wpa_supplicant) with a config file that specifies the EAP method, to test PEAP or EAP-TLS end to end.

In the server log, a success is an Access-Accept for the user. A failure is an Access-Reject, and the useful line is the reason just above it — a certificate problem, an unknown user, or an EAP-type mismatch. In radiusd -X, that reason is printed in full. Read up from the reject to find it.

The seven failures you will hit

• Wrong shared secret. Symptom: the server logs “Shared secret is incorrect” or drops the request silently. Fix: make the secret on the AP and in the client entry identical.
• Firewall on 1812. Symptom: the server sees nothing at all. Fix: open UDP 1812 and 1813 between the AP and the server.
• Certificate not trusted by the client. Symptom: the client refuses to connect, or warns about the server. Fix: install the CA on the client, or push it by profile.
• Server-name mismatch. Symptom: connects on one device, fails on another after a certificate change. Fix: set the expected server name in the client profile to match the certificate.
• EAP method mismatch. Symptom: immediate reject, no tunnel. Fix: make the client’s EAP method match the server’s policy.
• Clock skew. Symptom: certificate validation fails for no obvious reason. Fix: sync time on the server and clients with NTP.
• Accounting configured but not listening. Symptom: authentication works, but you have no session records. Fix: enable the accounting listener on 1813 and confirm the AP is sending to it.

If your setup fails, it is almost always one of these seven. Work down the list.

Hardening before production

• Rotate the shared secret from any value you used in testing.
• Restrict client IPs so the server answers only known access points.
• Enable accounting and confirm records are being written.
• Set log retention to meet your policy — and no longer, for privacy.
• Monitor certificate expiry. An expired server certificate stops authentication.

When to stop building and buy

Building a RADIUS server is the right way to learn how authentication works. It is not always the right way to run it.

Stop and evaluate a managed service when you are adding sites faster than you can build servers, you have no documented owner for certificate renewal, or authentication depends on one person’s knowledge. Those are the failure modes a service removes. We compare the two paths in cloud RADIUS vs on-premise, and Cloud4Wi’s Cloud NAC provides built-in cloud RADIUS if you decide the operational layer is not worth owning.