What Is RADIUS? An Overview
RADIUS stands for Remote Authentication Dial-In User Service. It is an open protocol standardized in RFC 2865, designed to centralize the management of Authentication, Authorization, and Accounting (AAA) for devices and users seeking access to network resources. It solves the problem of distributed, inconsistent, and device-specific access controls by introducing a central server that enforces policy and tracks usage across the entire network.
Unlike a directory service that stores user identities and attributes (like LDAP), RADIUS acts as an intermediary. It enables routers, VPN appliances, Wi-Fi access points, switches, and other Network Access Servers (NAS) to delegate credential checking, access policy definitions, and audit trails to a central point. This allows organizations to enforce consistent authentication standards, manage access control rules in a single place, and collect detailed logs of network usage for monitoring or regulatory compliance.
RADIUS is a protocol, not a storage backend. It streamlines network access processes by allowing devices to offload complex authorization decisions and recordkeeping to a purpose-built server, which can interact with identity data in external stores as needed.
How Does RADIUS Work? Protocol Basics and Workflow
RADIUS operates on a client-server model using the User Datagram Protocol (UDP). Network Access Servers—such as gateways, wireless controllers, or VPN concentrators—act as RADIUS clients. When a user or device attempts to connect, the NAS collects credentials and sends an Access-Request packet to the RADIUS server over UDP port 1812.
The RADIUS server then authenticates the user, typically by verifying supplied credentials (username/password, certificates, or tokens) against a backend such as LDAP or Active Directory. This server is authoritative for granting or denying access but may delegate credential lookups to external systems.
The basic RADIUS AAA workflow includes:
- Authentication: NAS sends user credentials (often obfuscated) to the RADIUS server.
- Authorization: If credentials are valid, the server responds with Access-Accept along with attributes (e.g., permitted VLANs, session timeouts) that define what the user can do. If invalid, Access-Reject is sent.
- Accounting: Independently tracked via separate messages (UDP port 1813), RADIUS servers log start, stop, and interim updates about active sessions—such as connection duration, bytes transferred, or reason for termination.
The protocol is inherently extensible. Attributes in Access-Accept, Access-Reject, or Accounting-Response packets can encode vendor-specific policies, transport role-based privileges, or report granular usage data.
Importantly, while RADIUS obfuscates user passwords using a shared secret between NAS and server, it does not encrypt all traffic by design. Additional measures—such as confining communication to trusted networks or utilizing RADIUS over TLS (RadSec)—are essential for strong confidentiality and integrity.
Where Is RADIUS Used? Common Scenarios
RADIUS is foundational in enterprise and service-provider networks where centralized access control is required. Typical deployment patterns include:
- Wi-Fi Authentication (802.1X/WPA-Enterprise): Wireless access points or controllers ask users to authenticate with their domain credentials. The AP acts as a NAS, forwarding requests to a RADIUS server, which then validates users (often against LDAP, Active Directory, or other identity platforms) before granting access.
- VPN Access Control: Remote users connecting to a VPN gateway submit credentials, which are proxied by the gateway (as the RADIUS client) to the RADIUS server. Access policies—such as permitted subnets or session lifetimes—are enforced centrally.
- Switch and Dial-In Access: Enterprise switches can require authentication before activating ports or services. ISPs rely on RADIUS for PPP, DSL, or dial-up subscriber authentication and metering.
RADIUS is not limited to on-premises deployments. Modern enterprise and cloud architectures often position RADIUS as the policy engine between on-prem Network Access Servers and cloud-based identity providers, bridging physical network security with remote authentication services.
Understanding RADIUS Authentication Methods
RADIUS supports multiple authentication mechanisms, each with distinct security implications:
- PAP (Password Authentication Protocol): Sends the user's password in cleartext (obfuscated with the RADIUS shared secret, not encrypted). Simple, but offers limited security if intercepted; avoid over untrusted networks.
- CHAP (Challenge-Handshake Authentication Protocol): Performs a challenge-response sequence that does not transmit the password directly, offering some protection against replay attacks but is still vulnerable if NAS or passwords are weak.
- EAP (Extensible Authentication Protocol): Defined in RFC 3579 for RADIUS, EAP allows flexible authentication, including certificate-based, token, smart-card, or tunneled password schemes. When combined with protocols like EAP-TLS or PEAP, it can provide strong, mutual authentication and per-session encryption.
Support for multiple methods enables RADIUS to accommodate a wide range of security requirements and device capabilities. However, use cases demanding high assurance should pair RADIUS with EAP variants that leverage certificates and encrypted tunnels.
RADIUS vs LDAP: Protocols, Problems, and Patterns
A common source of confusion is the relationship between RADIUS and LDAP. While both can be part of an authentication workflow, they serve fundamentally different purposes:
- LDAP (Lightweight Directory Access Protocol) is a directory service protocol. It stores, searches, and manages hierarchical identity data—usernames, groups, organizational units, etc.—and enforces access to these records.
- RADIUS is an AAA protocol. It makes access decisions for network connections, applies policies, and aggregates accounting records. It is not designed for direct identity storage or complex directory queries.
In practice, RADIUS servers often authenticate users by proxying credential checks to an LDAP or Active Directory backend. For example, when a user connects to Wi-Fi, their credentials flow from the AP (RADIUS client), to the RADIUS server, which validates them using an LDAP bind or AD authentication. RADIUS then returns policy controls and records usage, while LDAP (or AD) remains the source of truth for identity data.
You use RADIUS when you need:
- Centralized, consistent authentication and policy enforcement at the network edge (Wi-Fi, VPN, switches).
- Protocol-level support for AAA separation and detailed accounting, not just identity lookup.
- Integration with a variety of network devices that natively support RADIUS.
You use LDAP when you need:
- Directory lookups, user attribute retrieval, or hierarchical group membership management for applications.
- Direct, granular access to identity data (but not network access enforcement).
RADIUS acts as an enforcing intermediary and policy broker—often sitting between network devices and an LDAP server—but is never a replacement for directory services.
Security Considerations for RADIUS Deployments
RADIUS has been fundamental to network security for decades, but has legacy design elements that warrant careful consideration:
- Transport Security: By default, RADIUS uses UDP and only obfuscates (does not encrypt) user credentials with a shared secret. All other attributes, including authorization and accounting data, are sent in plaintext. If the shared secret is weak or the communication path is exposed, credentials and accounting information can be intercepted or tampered with.
- Authentication Method Strength: Avoid PAP if possible; it provides minimal security. CHAP is better but not robust against modern attacks. Use EAP-TLS or protected EAP methods where strong mutual authentication and encryption are required.
- Shared Secret Management: Shared secrets between NAS and RADIUS server must be unique, complex, and stored securely. Re-using secrets across clients increases attack surface.
- Modern Extensions: Implementations can mitigate native weaknesses by using RADIUS over TLS (RadSec) or by tunneling authentication inside EAP methods that provide strong session protection.
RADIUS’s flexibility and broad support are offset by these fundamental limitations. Proper deployment requires not just configuration, but also network design and continuous auditing of both protocol choices and credential management.
Extending and Integrating RADIUS
One of RADIUS’s major strengths is extensibility. The protocol is built around attribute-value pairs; both standardized (defined in RFC 2865, RFC 2869, and subsequent RFCs) and vendor-specific attributes allow organizations and manufacturers to introduce new policies and features without altering the core protocol.
- RADIUS Accounting (RFC 2866): This extension formalizes how session start, stop, and interim usage events are sent to a central server for logging, billing, or quota enforcement.
- EAP Transport (RFC 3579): Enables RADIUS to serve as a transport for rich, modern authentication frameworks, supporting multi-factor, certificate-based, and federated methods.
- RadSec (RADIUS over TLS): While not defined in the core RADIUS RFCs, various implementations support running RADIUS over TCP/TLS, ensuring confidentiality and integrity for all AAA traffic.
Modern deployments often combine RADIUS with directory synchronization (e.g., enterprise directories, cloud identity providers) to integrate policy enforcement with up-to-date identity information.
Should You Use RADIUS?
RADIUS remains a cornerstone in enterprise and service-provider networks for controlling access to Wi-Fi, VPNs, and wired infrastructure. It excels at decoupling authentication logic and policy from individual network devices, supporting large-scale deployments with consistent enforcement and comprehensive accounting.
Use RADIUS when:
- You need a centralized AAA policy engine for heterogeneous network devices.
- Network access control must interact with enterprise directories but remain application-independent.
- Detailed session accounting and dynamic policy assignment are operational requirements.
Avoid direct RADIUS deployments without secure authentication methods (e.g., EAP-TLS) or additional transport protections (e.g., RadSec), especially outside trusted, segmented networks. For scenarios requiring directory navigation, attribute management, or identity lifecycle operations, pair RADIUS with LDAP/Active Directory rather than replacing one with the other.
Understanding RADIUS’s role as an AAA protocol and its distinction from directory protocols lets you choose the right technology mix for scalable, secure network access control—now and in the future.