What Is RADIUS? Security Definition

Think of RADIUS as a receptionist for a big office building. Imagine you arrive at work and need to swipe your badge to get through the front door. That badge reader doesn’t make the decision itself. Instead, it sends your badge number to a central security office where a computer checks if your badge is valid and you’re allowed to enter. That central computer is like a RADIUS server. It knows who is allowed in, what time they can enter, and which floors they can access.

Now, imagine you’re not just entering one building, but multiple buildings that are part of the same company. If each building had its own list of approved badges, it would be a nightmare to update every time an employee leaves or joins. RADIUS solves that by keeping one master list. When you swipe your badge at any door, that door’s reader sends your info to the central RADIUS server, which says yes or no.

In the tech world, RADIUS works the same way. When you try to connect to a Wi-Fi network at a coffee shop or use a VPN to log into your company’s network from home, the access point (like the Wi-Fi router) sends your login details to a RADIUS server. The server checks if you are who you say you are (authentication), decides what you’re allowed to do (authorization), and keeps a log of your session (accounting). That’s why we say RADIUS handles Authentication, Authorization, and Accounting, often called AAA.

RADIUS is not the only protocol for this job, but it’s one of the most common because it’s reliable, works with many different brands of equipment, and has been around since the early 1990s. It uses encryption to protect your password while it’s being sent across the network, but some older versions have known weaknesses, so modern implementations use stronger protections like EAP (Extensible Authentication Protocol). For IT certification exams, you need to understand that RADIUS is a client-server protocol that runs on port 1812 for authentication and authorization, and port 1813 for accounting.

In everyday language, RADIUS is the invisible helper that makes sure only the right people get onto a network, and that their activity is recorded. Without it, network administrators would have to configure every single Wi-Fi router and VPN server individually, which would be inefficient and insecure.

RADIUS stands for Remote Authentication Dial-In User Service. It is a networking protocol that provides centralized Authentication, Authorization, and Accounting (AAA) management for users who connect to a network service. It was originally developed by Livingston Enterprises in 1991 as a protocol for dial-up modem access, but has since become the industry standard for many types of network access, including wireless (Wi-Fi), VPN, Ethernet switches, and network routers.

RADIUS operates at the application layer of the OSI model. It is a client-server protocol. The network access server (NAS), such as a wireless access point, VPN concentrator, or switch, acts as the RADIUS client. The NAS sends authentication requests to the RADIUS server, which then processes the request and returns a response. The RADIUS server typically consults a user database, which could be a flat file, an LDAP directory (like Active Directory), a SQL database, or an external identity provider.

The protocol uses UDP (User Datagram Protocol) as its transport layer protocol. The standard ports are 1812 for authentication and authorization, and 1813 for accounting. RADIUS uses a shared secret (a pre-shared key) between the client and server to encrypt certain fields, such as the password. However, only the password is encrypted; other parts of the packet, like the username, are sent in cleartext. This is a known limitation, and modern RADIUS deployments often address it by tunneling RADIUS over TLS (RadSec) or using EAP (Extensible Authentication Protocol) methods that provide full packet encryption.

The RADIUS packet structure consists of a header (code, identifier, length, authenticator) followed by a variable number of attributes. The code field indicates the type of packet: Access-Request, Access-Accept, Access-Reject, Access-Challenge, Accounting-Request, and Accounting-Response. The identifier field matches request and response packets. The authenticator field provides integrity checking. Attributes carry specific information such as username, password, NAS-IP-Address, Service-Type, Framed-IP-Address, and vendor-specific attributes (VSAs).

RADIUS is defined in RFC 2865 (Authentication and Authorization) and RFC 2866 (Accounting). It has been extended by many other RFCs to support modern authentication methods. One important extension is RFC 3579, which specifies how RADIUS supports EAP. In an EAP over RADIUS scenario, the RADIUS server acts as an EAP server, and the NAS acts as an EAP authenticator. This allows the use of secure authentication methods like EAP-TLS (certificate-based), PEAP, and EAP-MSCHAPv2.

In real IT implementations, RADIUS is often deployed using FreeRADIUS (open-source), Microsoft Network Policy Server (NPS) on Windows Server, or commercial solutions like Cisco ISE. When configuring RADIUS, administrators must define the NAS clients (by IP address and shared secret), configure user accounts or link to a directory service, and define policies that determine what happens after authentication, for example, which VLAN a user should be placed on, or what IP address should be assigned.

RADIUS accounting allows the collection of session data such as login time, logout time, bytes sent and received, and reason for session termination. This data is used for billing, auditing, and monitoring. In exam contexts, it is important to remember that RADIUS is primarily for network access control, whereas TACACS+ (a similar protocol) is often used for device administration (like logging into routers and switches).

Common vulnerabilities and considerations: RADIUS over UDP does not provide inherent encryption of the full packet, making it susceptible to packet sniffing if not protected. The shared secret can be brute-forced if it is weak. Some implementations are vulnerable to dictionary attacks. For these reasons, security best practices recommend using strong shared secrets, restricting RADIUS traffic to trusted IP addresses, and considering RadSec (RADIUS over TLS) for increased security. RADIUS does not inherently support multi-factor authentication, but it can be combined with EAP methods that support certificates or OTP tokens.

RADIUS is a foundational technology in network security and identity management, and understanding it is critical for any IT professional working with enterprise networks. Without RADIUS, network administrators would have to manually configure access control on every single device that users connect to. That would include every Wi-Fi access point, every VPN gateway, every switch port that requires authentication, and every remote access server. Doing that individually is not only time-consuming but also insecure, because it becomes very difficult to enforce consistent policies or respond quickly to security incidents.

RADIUS centralizes authentication and authorization, which means that when a user’s account is disabled in the central directory (like Active Directory), they immediately lose access to all network resources that rely on RADIUS. This is essential for organizations that need to control access for hundreds or thousands of employees, contractors, and guests. It also enables sophisticated policies, such as requiring different authentication methods depending on the user’s role, time of day, or location.

RADIUS also provides accounting, which is vital for compliance, billing, and monitoring. For example, in a university that offers free Wi-Fi to students but charges per gigabyte for guests, RADIUS accounting can track exactly how much data each guest consumes. In healthcare, RADIUS logs can be used to prove who accessed the network and when, which is required for HIPAA compliance.

Another reason RADIUS matters is its ubiquity. It is supported by virtually every major networking vendor, including Cisco, Aruba, Juniper, Ubiquiti, and many others. It integrates with a wide range of authentication backends, from simple text files to enterprise directories and cloud identity providers. Because of its long history and wide adoption, RADIUS skills are highly transferable across different jobs and environments.

For IT professionals, understanding RADIUS is also important because it is often a point of failure in network access. If users cannot connect to Wi-Fi or VPN, misconfigured RADIUS is a common root cause. Knowing how to troubleshoot RADIUS, checking shared secrets, verifying connectivity, reading logs, is a practical skill that directly impacts end-user experience. RADIUS is not just a theoretical concept; it is a core tool in the network administrator’s toolkit, and mastering it is essential for anyone responsible for network security.

RADIUS appears in certification exams in several distinct question patterns. The most common is the direct definition question: “Which protocol provides centralized authentication, authorization, and accounting for network access?” The answer, of course, is RADIUS. But exam writers often try to confuse you with similar terms like TACACS+, Kerberos, or LDAP. You need to distinguish them by knowing the key differences: RADIUS uses UDP (ports 1812/1813), encrypts only the password, and is primarily for network access control. TACACS+ uses TCP (port 49), encrypts the entire packet, and is primarily for device administration.

Another common pattern is the scenario question. For example: “A company wants to implement 802.1X authentication on its wireless network. Which protocol should be used between the access point and the authentication server?” The correct answer is RADIUS because 802.1X uses EAP over RADIUS. An exam might ask: “Which port does the RADIUS server listen on for authentication requests?” Answer: UDP 1812. Or: “What is the main security weakness of RADIUS?” Answer: Only the password is encrypted; other packet fields are sent in cleartext.

Configuration questions are common in CCNA and network-focused exams. You might see a partial configuration like:

aaa new-model aaa authentication login default group radius local radius-server host 10.10.10.5 key secretkey interface GigabitEthernet0/1 authentication port-control auto dot1x pae authenticator

The question might ask: “What is the purpose of the radius-server host command?” Answer: To specify the IP address and shared secret of the RADIUS server. Another question might show a misconfigured RADIUS client where the shared secret does not match the server, you would need to identify that as the cause of authentication failures.

Troubleshooting questions also appear. For instance: “Users report they cannot connect to the corporate Wi-Fi. The access point shows RADIUS timeouts. What is the most likely cause?” Possible answers: wrong shared secret, firewall blocking UDP 1812/1813, incorrect IP address of the RADIUS server, or the RADIUS server itself is down. You need to know the typical causes of RADIUS failures.

Finally, comparison questions are popular: “Which AAA protocol encrypts the entire packet?” Answer: TACACS+. “Which AAA protocol is commonly used for network access?” Answer: RADIUS. “Which protocol uses UDP for transport?” Answer: RADIUS. “Which protocol separates authentication, authorization, and accounting processes?” Answer: TACACS+ (RADIUS combines authentication and authorization in one packet, while accounting is separate). Mastering these comparisons is essential.

In real-world IT, implementing RADIUS requires both theoretical knowledge and hands-on configuration. As a professional, you will likely be involved in setting up RADIUS for Wi-Fi, VPN, or wired 802.1X. Let’s walk through a typical deployment using FreeRADIUS on Linux, which is a popular open-source RADIUS server.

First, you need to understand the components: The RADIUS server (FreeRADIUS) runs on a server, typically in the data center. The NAS devices (like wireless access points, VPN gateways, or switches) are configured as RADIUS clients. The user database can be a local file, but in most enterprises, it’s an LDAP directory like Active Directory. You’ll configure FreeRADIUS to authenticate against Active Directory using either LDAP or the more secure Kerberos-based authentication.

Configuration involves editing several files. The main configuration file is /etc/freeradius/3.0/radiusd.conf (or similar depending on version). You define the IP addresses and shared secrets of your NAS devices in the clients.conf file. For example:

client 10.10.10.10 { secret = strongsharedsecret shortname = access-point-1 }

Next, you set up the authentication backend. If using Active Directory, you might use the ntlm_auth helper or directly integrate with LDAP. For example, in mods-available/ldap, you’ll specify the LDAP server, base DN, and bind credentials. Then you link it in the authorize section of the sites-enabled/default file.

You also need to define authorization policies. For instance, you might want to place all employees on VLAN 100 and guests on VLAN 200. In FreeRADIUS, you can set this using unlang (the policy language) or by returning attributes. Example:

update reply { Tunnel-Type = VLAN Tunnel-Medium-Type = IEEE-802 Tunnel-Private-Group-Id = "100" }

Accounting is typically enabled by default. You can log accounting data to a database (MySQL or PostgreSQL) for reporting. Many organizations use tools like Daloradius or a custom web interface to view RADIUS logs.

Common pitfalls in real deployments: forgetting to open UDP ports 1812 and 1813 on the firewall, mismatched shared secrets, incorrect NTP (time synchronization is critical for RADIUS), and not configuring the NAS to be a RADIUS client. Also, many access points require you to configure both the RADIUS IP and the shared secret, and they may only support one RADIUS server. It’s common to deploy two RADIUS servers for redundancy.

Troubleshooting is a daily task. If users cannot authenticate, you check the RADIUS logs (usually /var/log/radius/radius.log) for clues like "Packet from unknown client" (wrong IP) or "Invalid shared secret" (wrong key). You can also run the radtest utility to manually test authentication:

radtest username password radius-server 0 auth-port 1812 secret

This sends a test request and shows the response. If it returns Access-Accept, the server is working. If Access-Reject, the credentials are wrong or the user account is disabled.

practical RADIUS management involves server setup, client configuration, policy definition, troubleshooting connectivity and authentication issues, and ensuring high availability. These skills are directly tested in CCNA and Security+ labs, and they are essential for any network administrator.

RADIUS, which stands for Remote Authentication Dial-In User Service, is a networking protocol that provides centralized Authentication, Authorization, and Accounting (AAA) management for users who connect and use a network service. It is widely used in enterprise environments for managing access to network devices, VPNs, wireless networks, and other critical services. Understanding the RADIUS authentication flow is essential for IT security professionals, especially for those preparing for exams like the CISSP, Security+, CCNA, and Network+.

When a user attempts to connect to a network resource, such as a wireless access point or a VPN concentrator, the network access server (NAS) acts as the RADIUS client. The NAS sends an Access-Request packet to the RADIUS server, which contains the user's credentials (typically a username and password) along with other attributes like the NAS identifier and port information. The password is encrypted using a shared secret key, ensuring confidentiality over the network. The RADIUS server then checks these credentials against its user database, which could be an internal directory, LDAP, or Active Directory.

If the credentials are valid, the RADIUS server responds with an Access-Accept packet, which may include attributes such as an assigned IP address, session timeout, or specific authorization parameters like allowed VLANs or filter rules. If the credentials are invalid or the user is not authorized, the server sends an Access-Reject packet, and the NAS denies access. The server can send an Access-Challenge packet for additional verification, such as prompting for a one-time password or multi-factor authentication code. This challenge-response mechanism is used in Extensible Authentication Protocol (EAP) frameworks to support secure authentication methods like EAP-TLS or PEAP.

Accounting is another critical aspect of RADIUS. After the user is authenticated, the NAS sends Accounting-Start packets to the RADIUS server, logging when the session begins. As the session progresses, interim accounting updates may be sent to track data usage or time. When the user disconnects, an Accounting-Stop packet is sent, recording the end time and total resources consumed. This accounting data is vital for billing, auditing, security monitoring, and compliance. In exam contexts, candidates should remember that RADIUS uses UDP ports 1812 for authentication and 1813 for accounting, although older implementations used ports 1645 and 1646. The protocol is often compared to TACACS+, which uses TCP and separates authentication, authorization, and accounting into separate processes.

One common misconception tested in exams is that RADIUS encrypts only the password in the Access-Request packet, while the rest of the packet (including the username) is sent in clear text. This is a security limitation that must be addressed by using IPsec or VPN tunnels between the NAS and RADIUS server. RADIUS is a client-server protocol that uses a shared secret for security, and it is connectionless, relying on UDP for transport. This design makes RADIUS more scalable but less reliable than TCP-based alternatives. For example, in a CCNA or Network+ exam, you might be asked to identify which protocol is used for AAA in a Cisco environment, and the answer often distinguishes RADIUS from TACACS+ based on port numbers, encryption methods, and support for command authorization. Understanding these differences is fundamental for network and security professionals.

Configuring RADIUS correctly is a critical skill for network administrators and security engineers. Misconfigurations can lead to authentication failures, security vulnerabilities, or network outages. On Cisco devices, for example, RADIUS configuration involves several steps starting with the global configuration mode. The administrator must specify the RADIUS server IP address, the shared secret key, and the authentication and accounting ports. A typical command on a Cisco router or switch would be 'radius-server host 192.168.1.10 key MySecretKey' followed by 'radius-server key MySecretKey' to set the global key. You can configure the server for authentication using 'aaa new-model' to enable AAA services, then define an authentication list with 'aaa authentication login default group radius local'. This tells the device to use RADIUS first and fall back to local authentication if the RADIUS server is unreachable.

For accounting, commands such as 'aaa accounting exec default start-stop group radius' are used to log all executive sessions (like SSH or console access) to the RADIUS server. Similarly, 'aaa accounting network default start-stop group radius' logs network-related connections such as PPP or VPN sessions. In a wireless environment, RADIUS is often integrated with a Wireless LAN Controller (WLC). The WLC is configured as a RADIUS client, and the RADIUS server (like Cisco ISE or FreeRADIUS) handles user authentication. The configuration involves specifying the shared secret, IP address, and optionally, the timeout and retransmission settings.

Troubleshooting RADIUS issues often begins with verifying connectivity between the NAS and the RADIUS server. The NAS must be able to reach the server's IP address and the correct UDP ports (1812 for authentication, 1813 for accounting). Firewalls or Access Control Lists (ACLs) can block these ports, so using tools like 'telnet' or 'nc' to test port availability is futile since RADIUS uses UDP, which is connectionless. Instead, administrators use debug commands available on many networking devices. On Cisco IOS, the command 'debug radius authentication' shows the details of each authentication attempt, including the Access-Request and Access-Accept or Access-Reject packets. Similarly, 'debug radius accounting' displays accounting packet exchanges. These debugs help identify issues such as mismatched shared secrets, incorrect user credentials, or attribute problems.

Another common troubleshooting step is checking the RADIUS server logs. For FreeRADIUS, for instance, the 'radiusd -X' command runs the server in debug mode and outputs detailed messages about packet processing. Logs can indicate whether the user exists in the database, if the password is valid, or if the server is receiving requests from an unauthorized NAS. The RADIUS server must be configured with the correct client entries, including the NAS IP address and shared secret. In enterprise deployments, RADIUS proxy configurations are also used to forward requests to other RADIUS servers or external identity sources like LDAP.

For exams like Security+ and CISSP, candidates should know that RADIUS is an open standard (RFC 2865 and 2866) and is often used for 802.1X port-based authentication in wired and wireless environments. Troubleshooting also involves checking that the supplicant (client device) is configured to use EAP methods that the RADIUS server supports. Certificate-based authentication (EAP-TLS) requires valid certificates on both the server and client, while PEAP uses a server-side certificate. The most common reason for authentication failure is a mismatch in the shared secret, time synchronization issues (especially for certificates), or firewall rules blocking UDP traffic. In exam scenarios, you might be given a configuration excerpt and asked to identify a misconfiguration, such as using the wrong port number (e.g., 1645 instead of 1812) or missing the 'aaa new-model' command. Mastering these configuration and troubleshooting details is essential for passing vendor-neutral and vendor-specific certifications.