Linux and RADIUS Centralized Authentication

This article explains how the Linux operating system integrates with the Remote Authentication Dial-In User Service (RADIUS) protocol to facilitate centralized user authentication, authorization, and accounting (AAA). It covers the role of Pluggable Authentication Modules (PAM) on client systems, the communication lifecycle between the Linux kernel, client daemons, and remote servers, and how Linux functions as both a RADIUS client and a centralized RADIUS host.

The Role of PAM in Linux RADIUS Authentication

Linux delegates authentication tasks through Pluggable Authentication Modules (PAM), an architecture that separates core applications from specific authentication mechanisms. To authenticate against a RADIUS server, Linux administrators integrate a module such as pam_radius_auth.

When a user attempts to log into a Linux machine—whether locally, via OpenSSH, or through a virtual private network (VPN)—the login service invokes PAM. The PAM configuration file for that service routes the request to the RADIUS module. The module reads configuration parameters from a target file (typically /etc/pam_radius_auth.conf), which defines the remote server's IP address, port, shared secret, and timeout threshold.

The Network Authentication Lifecycle

The interaction between Linux and a RADIUS server follows a standard client-server request/response model operating primarily over UDP (ports 1812 for authentication and 1813 for accounting):

1. Request Creation: The PAM module or local application formats the user credentials into an Access-Request packet. The password attribute is obfuscated using an MD5 hash combined with the pre-shared secret configured on both the Linux host and the RADIUS server.
2. Transmission: The packet is sent to the designated RADIUS server via UDP port 1812.
3. Evaluation: The RADIUS server processes the request against its internal database, an LDAP directory, or Active Directory.
4. Response: The server returns one of three outcomes:
   • Access-Accept: The user's credentials are valid. The packet may also return vendor-specific attributes (VSAs), such as assigned shell parameters, home directories, or group memberships.
   • Access-Reject: The credentials are invalid or the account is locked, causing PAM to deny entry to the user.
   • Access-Challenge: The server requires secondary verification, such as a multi-factor authentication (MFA) token, which the Linux PAM stack prompts the user to supply.

Linux as a RADIUS Server: FreeRADIUS

Beyond acting as a client, Linux is the dominant platform for hosting RADIUS services, primarily through FreeRADIUS. When deployed as a server:

• Backend Integration: The FreeRADIUS daemon binds to network interfaces to listen for incoming authentication requests from switches, wireless access points, VPN concentrators, or other Linux servers. It integrates directly with Linux system resources, including MySQL/PostgreSQL databases, local Unix user files, and OpenLDAP servers.
• Accounting (AAA): Linux handles accounting data via UDP port 1813. When a session starts or terminates on a client device, the device sends Accounting-Request packets (Start, Stop, or Interim-Update). FreeRADIUS logs these metrics to text files (detail logs) or directly to a relational database to track network usage, session duration, and IP allocation.

Local User Identity Synchronization

A common challenge when authenticating Linux logins via RADIUS is that standard Linux utilities expect local system entities, such as a User ID (UID), Group ID (GID), and local home directory.

To bridge this gap, Linux environments typically pair RADIUS authentication with an identity provider via the System Security Services Daemon (SSSD) or configure the PAM stack with pam_mkhomedir. This configuration allows RADIUS to handle the password verification remotely while the Linux operating system automatically creates local user environments dynamically upon the first successful login.