RADIUS vs TACACS+: AAA Protocol Comparison

AAA stands for Authentication, Authorization, and Accounting. Authentication verifies who the user is (username/password, certificate). Authorization determines what the user is allowed to do (access a VLAN, run specific commands). Accounting tracks what the user did (login/logout times, commands executed). Without AAA protocols, each network device would need its own local user database, which doesn't scale. AAA protocols centralize this into a server (like Cisco ISE, FreeRADIUS, or ACS).

RADIUS (Remote Authentication Dial-In User Service) was originally developed by Livingston Enterprises for dial-up access. It is defined in RFC 2865 (Authentication and Authorization) and RFC 2866 (Accounting). TACACS+ (Terminal Access Controller Access-Control System Plus) is a Cisco-proprietary enhancement of the original TACACS protocol. Both provide AAA, but their architectures differ significantly.

RADIUS uses UDP ports 1812 for Authentication/Authorization and 1813 for Accounting (older implementations may use 1645/1646). The client (NAS – Network Access Server, e.g., a switch or wireless controller) sends an Access-Request packet to the RADIUS server. This packet contains the username, password (encrypted using a shared secret via MD5 hash), and other attributes like NAS-IP-Address and Called-Station-ID. The server responds with one of three packets:

Authorization is embedded in the Access-Accept packet — there is no separate authorization exchange. This means the NAS must trust the server's single response for both auth and authz. Accounting is separate: the NAS sends Accounting-Request (Start) when a session begins and Accounting-Request (Stop) when it ends. The server replies with Accounting-Response.

RADIUS uses a shared secret (plaintext string known to both client and server) to encrypt only the password field in the Access-Request. The rest of the packet (including username, attributes) is sent in cleartext. This is a security limitation. The shared secret is also used to compute an MD5 hash for integrity, but not for confidentiality of the entire packet.

TACACS+ uses TCP port 49. This gives reliable delivery — no need for retransmission logic in the protocol itself. TACACS+ separates the three A's into distinct packet types:

The entire TACACS+ packet body is encrypted using a shared secret (MD5-based, but the secret is used to generate a pseudo-random pad that XORs the entire body). Only the TACACS+ header (12 bytes) is in cleartext. This provides full confidentiality for all AAA information.

RADIUS:

TACACS+:

To configure RADIUS on a Cisco IOS device:

! Configure RADIUS server
radius server ISE
 address ipv4 192.168.1.100 auth-port 1812 acct-port 1813
 key mySecretKey
!
! Apply to login authentication
aaa new-model
aaa authentication login default group radius local

To verify RADIUS:

show running-config | section radius
show radius server-group
show radius statistics

Example output of show radius statistics:

RADIUS Statistics:
  Total Packets In: 150
  Total Packets Out: 200
  Retransmissions: 5
  Timeouts: 2
  Dead Servers: 0

To configure TACACS+:

! Configure TACACS+ server
tacacs server ISE
 address ipv4 192.168.1.100
 key mySecretKey
!
aaa authentication login default group tacacs+ local
aaa authorization exec default group tacacs+ local
aaa accounting exec default start-stop group tacacs+

To verify TACACS+:

show tacacs

Example output:

TACACS+ Server: 192.168.1.100/49
  Socket opens: 10
  Socket closes: 8
  Total packets sent: 50
  Total packets received: 48
  Timeouts: 2

Both protocols integrate with 802.1X (port-based access control). The authenticator (switch) acts as a RADIUS or TACACS+ client, relaying EAP messages between the supplicant and the AAA server. RADIUS is the standard for 802.1X because RFC 3579 defines how to carry EAP over RADIUS. TACACS+ can also support 802.1X but is less common. For device administration (SSH/console), TACACS+ is preferred due to command authorization.

In a typical enterprise, RADIUS is used for network access control (NAC) scenarios. For example, when an employee connects their laptop to a wired switch port, the switch acts as a RADIUS client. The employee's credentials (or machine certificate) are forwarded to a RADIUS server (like Cisco ISE). The server authenticates the user and returns a VLAN assignment (e.g., VLAN 10 for corporate devices, VLAN 20 for guests). This is the 802.1X + RADIUS combination. The switch then dynamically places the port into the correct VLAN. Accounting tracks when the user connected and disconnected. Performance-wise, RADIUS over UDP can be problematic in lossy networks — retransmissions can cause delays. Using a RADIUS load balancer or multiple servers with failover is common.

TACACS+ is the go-to for device administration. Network engineers managing hundreds of routers and switches use TACACS+ to centralize authentication and authorize specific commands. For instance, junior engineers might only be allowed 'show' commands, while senior engineers can configure interfaces. This is implemented via TACACS+ authorization. Accounting logs every command entered, which is invaluable for auditing and compliance (e.g., PCI-DSS). A common deployment pattern is to have primary and secondary TACACS+ servers, and fall back to local authentication if both are unreachable. The TCP reliability of TACACS+ means fewer retransmission issues, but it can be more resource-intensive on the server due to persistent connections.

Misconfigurations happen. A classic mistake is using RADIUS for device administration and expecting command authorization. RADIUS does not support per-command authorization in the same way — it only returns a privilege level (0-15). So if you need granular command control, TACACS+ is required. Another pitfall: forgetting to apply the AAA method list to the console or VTY lines. You can configure AAA globally, but if the line doesn't reference the method list, it won't use AAA. Always check with show line con 0 and show line vty 0 4 to see the configured authentication.