RADIUS is surprisingly bad at actually being centralized, despite its name.
Let’s see it in action. Imagine a user, Alice, trying to connect to a Wi-Fi network. Her laptop, the "client," doesn’t know anything about her username or password. Instead, it sends an authentication request to a RADIUS server. The RADIUS server then acts as a middleman, checking Alice’s credentials against a backend database (like Active Directory or a local user list). If they match, the RADIUS server tells the Wi-Fi access point (also a RADIUS client) to let Alice in, sending back a set of instructions (called Access-Accept) that might include her IP address and network access policies. If they don’t match, it sends back an Access-Reject.
sequenceDiagram
participant Laptop as Alice's Laptop
participant AP as Wi-Fi Access Point
participant RADIUS as RADIUS Server
participant AD as Active Directory
Laptop->>AP: Authenticate (username: alice, password: <secret>)
AP->>RADIUS: RADIUS Access-Request (username: alice)
RADIUS->>AD: Check credentials for alice
AD-->>RADIUS: User found, password matches
RADIUS-->>AP: RADIUS Access-Accept (IP: 192.168.1.100, Policy: VLAN 10)
AP-->>Laptop: Grant Access (IP: 192.168.1.100)
This dance is powerful because the access point doesn’t need to store every user’s password. It just needs to trust the RADIUS server. This is the core problem RADIUS solves: managing authentication for many network devices (switches, VPN concentrators, Wi-Fi access points) from a single point. It separates the "authentication service" from the "network access enforcement."
The key components are:
- RADIUS Client: This is the network access device (like your Wi-Fi AP or VPN gateway). It intercepts user authentication attempts and forwards them to the RADIUS server. It must be configured with the RADIUS server’s IP address and a shared secret.
- RADIUS Server: This is the brain. It receives requests from clients, validates user credentials against a backend (like LDAP, Active Directory, or a local database), and sends back instructions (Access-Accept or Access-Reject). It also needs to be configured with the IP addresses of its clients and the shared secret for each.
- Backend Authentication Server: This is where the actual user identities and credentials live (e.g., Active Directory). The RADIUS server queries this to verify who the user is.
The "shared secret" is crucial. It’s a pre-shared password between the RADIUS client and server. All communication is encrypted using this secret, ensuring that only legitimate clients and servers can talk to each other. If the shared secret doesn’t match on both sides, the RADIUS server will simply ignore requests from that client.
The RADIUS protocol itself is quite simple, primarily using UDP ports 1812 (authentication) and 1813 (accounting). Accounting is often overlooked but vital for tracking who accessed what, when, and for how long. The RADIUS server receives accounting packets from clients and logs them, typically to a file or database.
Most people think RADIUS is just about passwords, but it’s also a powerful policy enforcement tool. When the RADIUS server sends an Access-Accept, it can include "Attribute-Value Pairs" (AVPs) that tell the access device how to grant access. For instance, it can specify the IP address to assign, the VLAN to put the user on, session timeouts, bandwidth limits, or even which specific services they can access. This allows for granular control over network access based on user identity.
The "centralized" aspect is often a bit of a misnomer because you typically need multiple RADIUS servers for high availability. If one server goes down, users can’t authenticate. So, you’ll often deploy primary and secondary RADIUS servers, and configure your RADIUS clients to try the secondary if the primary fails. This adds complexity but ensures resilience.
What most people don’t realize is how RADIUS handles "tunneling" for protocols like PPTP or L2TP VPNs. When a VPN client authenticates via RADIUS, the RADIUS server can send back AVPs that tell the VPN gateway to establish a tunnel to the user, encapsulating their entire network session within that tunnel. This allows the VPN gateway to act as a RADIUS client for the user’s initial authentication, and then the RADIUS server orchestrates the tunnel setup.
The next major concept you’ll grapple with is EAP (Extensible Authentication Protocol), which RADIUS often uses to negotiate more secure authentication methods like PEAP or TLS.