TACACS+ vs RADIUS for Device Administration

Both TACACS+ (RFC 8907) and RADIUS (RFC 2865, RFC 2866) provide centralized AAA for network devices. This post compares them specifically for device administration – controlling who can log into routers, switches, and firewalls, and what they can do once logged in.

Protocol Comparison

AAA Separation

The core architectural difference is how each protocol handles the three AAA phases.

RADIUS combines authentication and authorization into a single request-response exchange. The server returns the privilege level together with the authentication result. After that, the device makes all authorization decisions locally based on that privilege level.

TACACS+ treats each phase as an independent exchange. The device authenticates the admin first, then sends a separate authorization request for each action – including individual CLI commands. This means the server controls not just who gets in, but what they can do after login.

Command Authorization and Accounting

This is where the protocols diverge the most for device administration.

With TACACS+, when an admin types a command, the device sends an authorization request to the server before executing it. The server checks the command against a policy scoped by user, group, and device, then permits or denies it. Every executed command is also sent to the server as an accounting record.

With RADIUS, there is no command-level interaction after login. The admin gets a privilege level (0-15) and the device permits everything available at that level. There is no way to deny specific commands, and accounting only records when the session started and ended.

sequenceDiagram
    participant Admin
    participant Device
    participant AAA as TACACS+ Server

    Admin->>Device: SSH login
    Device->>AAA: Authentication (username/password)
    AAA->>Device: Authentication PASS

    Admin->>Device: show running-config
    Device->>AAA: Authorization (cmd: show running-config)
    AAA->>Device: PASS
    Device->>AAA: Accounting (cmd: show running-config)
    Device->>Admin: output

    Admin->>Device: write erase
    Device->>AAA: Authorization (cmd: write erase)
    AAA->>Device: FAIL
    Device->>Admin: Command authorization failed

None of this is possible with RADIUS – after Access-Accept, the server is out of the loop.

Authorization Granularity

TACACS+ authorization is evaluated on the server side for every action. The server receives the username, the device identity, and the exact command being executed, and makes a permit/deny decision based on all three. This allows policies like:

• User jdoe can run show commands on all devices, but configure terminal only on access switches.
• Users in the noc group are denied reload and write erase everywhere.
• A specific device group allows debug commands only from users in the engineering group.

Policies can be changed on the server without touching any device configuration.

RADIUS authorization happens once at login. The server returns a privilege level (0-15) in the Access-Accept response, and the device maps that level to a set of locally defined commands. All users at the same privilege level get the same access on every device. Changing what a user can do requires either changing the privilege level mapping on every device, or assigning a different privilege level on the server.

Multiprotocol Support

For device administration, the authentication method determines how credentials are exchanged between the device and the AAA server.

TACACS+ supports ASCII (interactive prompt-based authentication), PAP, and CHAP. The ASCII method is the most common for device login – it allows the server to control the login dialog, including prompting for additional factors like a token code after the password.

RADIUS supports PAP, CHAP, MS-CHAPv2, and EAP. The EAP framework gives RADIUS a wider range of authentication mechanisms, but most of them (EAP-TLS, PEAP) are designed for network access rather than device administration. For device login, PAP and CHAP are typically used.

Data Protection

Per RFC 8907, TACACS+ obfuscates the packet body using a shared secret and MD5-based pad. This protects usernames, commands, and accounting data in transit, but it is not encryption in the cryptographic sense – it relies on the secrecy of the shared key and the properties of MD5, which is considered weak by modern standards. RFC 9887 addresses this by defining TACACS+ over TLS 1.3 on a dedicated port (TCP 300), providing proper encryption, integrity, and mutual authentication.

RADIUS obfuscates only the User-Password attribute in Access-Request packets. Everything else – including the username, privilege level, and all accounting data – is sent in cleartext. RadSec (RADIUS over TLS) addresses this similarly.

Failure Handling

When the AAA server becomes unreachable, both protocols support fallback to local device credentials. The difference is detection time: TACACS+ uses TCP and detects failures via connection reset, while RADIUS uses UDP and must wait for retransmission timers to expire before failing over.

With TACACS+ command authorization enabled, a server outage can lock admins out of all configuration commands. This makes redundant TACACS+ servers and properly configured local fallback critical for production environments.

Deployment Architecture

flowchart TD
    subgraph mgmt["Management Network"]
        R[Core Router]
        S[Switch]
        F[Firewall]
    end

    subgraph aaa["AAA Infrastructure"]
        T1[TACACS+ Primary]
        T2[TACACS+ Secondary]
        ID[(LDAP / Active Directory)]
    end

    R -->|TCP 49| T1
    S -->|TCP 49| T1
    F -->|TCP 49| T1

    R -.->|TCP 49\nfailover| T2
    S -.->|TCP 49\nfailover| T2
    F -.->|TCP 49\nfailover| T2

    T1 --> ID
    T2 --> ID

Managed devices authenticate against the primary TACACS+ server, with automatic failover to the secondary. Both servers use the same identity store for user credentials and group-to-policy mapping.