Here’s how to configure a RADIUS server on any platform, without the mistakes that cost you a weekend.
Alan DeKok, CEO and Founder, InkBridge Networks
Most guides on how to configure a RADIUS server assume you are running Microsoft NPS on Windows Server, they walk you through a wizard, and stop there. That’s fine if your whole world is Windows. It’s less useful if you run Linux, a mixed network, an ISP, a campus, or anything that has to scale past a single small building.
This guide gives a high level overview of how to configure a RADIUS server in a way that holds up in production, no matter what server software you choose. It covers the core setup steps, the authentication decisions that matter, the mistakes we see most often, and how the configuration recommendations that are needed for Wi-Fi, VPN, and 802.1X.
What a RADIUS server does
A RADIUS server sits between your network devices and your user database. It answers one question: should this user or device be allowed on the network, and if so, with what level of access. It handles Authentication (proving identity), Authorisation (deciding what that identity may do), and Accounting (recording what happened). Those three jobs are usually shortened to AAA.
Before you change any settings, it helps to understand how the protocol works and why it has stayed secure for three decades. The RADIUS server never talks to end user devices. Instead, a network access server (a switch, wireless controller, VPN concentrator, or access point) collects the credentials from the end user device (EAP, PPPoE, etc.) and forwards them to the RADIUS server. The server checks the credentials against the user store, and returns an accept or reject, usually with attributes that give the user a particular kind of authorization (10 hours access, 100Mbps connectivity, etc. )
If you want more background, we explain the RADIUS protocol and why it is secure in a separate guide.
Getting that flow clear in your head makes every configuration step that follows more obvious.
How to configure a RADIUS server: the core steps
The exact screens differ between products, but the sequence is the same whether you configure FreeRADIUS, Microsoft NPS, or a commercial appliance.
To configure a RADIUS server:
Install the RADIUS server software on a dedicated host or virtual machine.
Keep the base system minimal and patched and start the service in debug mode once to confirm it runs cleanly before you change anything. On FreeRADIUS, this is also where you learn to read the server’s debug output, which is the single most useful skill for everything that follows. The FreeRADIUS getting started guide walks through a first install end to end.
Define your RADIUS clients.
A client is not an end user; it is each network access server (switch, wireless controller, VPN concentrator, or access point) that will send requests.
Add each device by IP address, set its type where the server asks, and give it a long, random shared secret that is unique to that device. The shared secret is what proves the device is genuine, so treat it with the same care as any other key and never reuse one across your estate.
Connect the RADIUS server to your database or user store.
Most organisations point RADIUS at the directory they already run, so people authenticate with credentials they already have. That is usually Active Directory or LDAP for enterprises and campuses, or a SQL database for ISP subscriber records. The server reads both credentials and group membership from here, and the way your groups are organised will shape the authorisation policies you write next.
For the enterprise case, follow our step-by-step guide on how to connect FreeRADIUS to Active Directory.
Choose your authentication methods. Decide which protocols the server will accept - PAP, CHAP, EAP, or MS-CHAP - based on what your clients support and how far you trust the path between them. (More on this below.)
Enable only what you need rather than turning everything on. Both CHAP and MS-CHAP should be treated as end-of-life for anything new; we explain why in MS-CHAP is dead.
Write your authorisation policies. Authentication only proves who someone is; authorisation decides what kind of network access they get.
Map users or groups to a VLAN, a bandwidth or session limit, a set of services, and any time-of-day or device conditions that apply, and the server returns these to the network as RADIUS attributes. If you want the model behind this, see how RADIUS authorisation works.
Enable accounting and logging. Turn on accounting so you have a record of who connected, from where, and for how long.
You will need it for troubleshooting, for security review, and for billing if you are an ISP. For performance, keep this accounting data separate from your live authentication path. Our guide to how RADIUS accounting works covers what gets recorded and why.
Test against real credentials before you go live.
Use a test account and a real client device, watch the server in debug mode, and confirm that both accept and reject cases behave the way you expect, including the attributes the server sends back. A structured approach here saves hours later; we set one out in network troubleshooting isn’t magic.
That last step is the one people skip, and it is the one that saves the weekend.
Choosing the right authentication method
This is where a poor decision weakens everything after it. The authentication methods you allow decides how well the user credentials are protected.
People who don’t understand RADIUS call PAP insecure because they believe that the password is sent over the network in clear-text. This simply isn’t true. In RADIUS, the password is sent securely over the network, and even the BlastRADIUS attack was not able to break that security.
In contrast, CHAP and MS-CHAP both hash the password with random challenge, but computers have gotten a lot faster in the last 30 years. Without getting into details, both CHAP and MS-CHAP should both be treated as insecure. In fact, anyone with a laptop, a few terabytes of disk space, can break CHAP or MS-CHAP in a few milliseconds.
This attack means that you must treat CHAP and MS-CHAP as being “plain text equivalent”. That is, sending CHAP or MS-CHAP over the network is exactly the same as sending the password over the network in the clear! So don’t use either method, unless the data is protected by RadSec, or by a TLS-based EAP methd.
EAP methods such as EAP-TLS give you certificate-based authentication and are the strongest option for Wi-Fi and 802.1X, at the cost of running a certificate infrastructure. EAP methods such as TTLS and PEAP send user credentials inside of a TLS tunnel, so they are safe and secure.
If you want a worked example, we walk through configuring FreeRADIUS with PAP.
The shared secret deserves the same care. It is not a user password; it is the key that authenticates each network device to the server. Use a long, random secret, and use a different one for every client. Reusing a single secret across your whole network means that one compromised switch will open up your entire network to attack.
Worth subscribing to.
Worth reading.
Our weekly newsletter covers network authentication tips, how-tos, security vulnerabilities, free resources, standards updates, and industry news. (All stuff you should stay up to date on!)
Common RADIUS configuration mistakes
After configuring RADIUS systems for enterprises, ISPs, and universities for a couple of decades, we see the same handful of mistakes again and again.
The first is exposing the RADIUS server to untrusted networks. RADIUS was designed to run inside trusted infrastructure. Keep it on a management network, and never let requests arrive straight from the public internet.
The second is treating redundancy as optional. If one RADIUS server going down means nobody can log in, you have built a single point of failure into the front door of your network. Plan for at least two servers, and configure your clients with a primary and a secondary from the start.
The third is skipping the user-store design. A RADIUS server is only as good as the directory behind it. If group membership is messy in Active Directory, your authorisation policies will be messy too.
The fourth is leaving debug logging on in production or, at the other extreme, switching accounting off to save disk. Log what you need, rotate it, and keep accounting on.
Configuring a RADIUS server for Wi-Fi, VPN, and 802.1X
Most real deployments exist to solve one of three problems, and the configuration shifts a little for each.
For Wi-Fi and wired 802.1X, you configure the RADIUS server as the authentication back end for your access points and switches, usually with PEAP or EAP-TLS, so that every user and device proves who they are before joining. This replaces a shared Wi-Fi password with individual credentials.
For VPN, the RADIUS server authenticates remote users against your existing directory, so a departing employee loses network access the moment their directory account is disabled.
For administrator access to network devices, RADIUS - or its sibling TACACS+ - controls who can log in to switches and routers and which commands they are allowed to run. The core configuration is the same in each case; what changes is the authentication method and the authorisation attributes you send back.
Frequently asked questions
How long does it take to configure a RADIUS server?
A basic setup on a single server can be done in an afternoon. A production deployment with redundancy, directory integration, and tested policies is a larger piece of work, and the timeline depends far more on your network design than on the software.
Which ports does a RADIUS server use?
Modern RADIUS uses UDP port 1812 for authentication and 1813 for accounting. Open these ports only between your network access servers and the RADIUS server, never to the wider network.
Can I configure a RADIUS server to use Active Directory?
Yes. FreeRADIUS and most other servers can authenticate users against Active Directory, so people log in with the credentials they already have. We cover the details in our guide on using FreeRADIUS and Active Directory together.
Do I need a RADIUS server for Wi-Fi?
If you want individual logins rather than one shared password, then yes. A RADIUS server is what lets each person and device authenticate separately, which is the basis of enterprise Wi-Fi security.
Is FreeRADIUS a good choice for configuring a RADIUS server?
FreeRADIUS runs a large share of the world’s authentication and is free to deploy. It is powerful and flexible, which also means the default configuration is a starting point to be customised rather than a finished product. That customisation is exactly the work we do for clients who would rather not learn it the hard way.
Need more help?
If your team is wrestling with network configuration, a troubleshooting problem you cannot resolve, or a system that needs to be more resilient, we can help. InkBridge Networks has 25 years of expertise - we wrote the standards, maintain FreeRADIUS, and have seen every failure mode there is. Reach out to request a quote.
Related Articles
The FreeRADIUS getting started guide
After an administrator installs FreeRADIUS for the first time, the big question is “Now what?” Most sites need complex policies, interactions with databases, and logging. Yet the documentation for the server doesn’t give detailed instructions for how to configure the server for your particular location.
Why your RADIUS server should run in a VM
A junior system admin might inadvertently type the wrong thing into a command line, or a minor upgrade can break some obscure dependency between libraries resulting in a cascading set of errors that bring the network down. When your infrastructure stops working, (and it will, you just don’t know when), it is critical to fix it quickly.