TACACS+ vs RADIUS for Network Device AAA: How to Choose

Both protocols authenticate administrators on switches and routers, and picking the wrong one costs you command-level control or forces you into vendor lock-in. The decision is not about popularity - it is about three concrete capabilities that differ between them.

The Differences That Actually Matter

The short version: TACACS+ for device administration, RADIUS for network access.

Why TCP Beats UDP Here

Your access control path should not silently lose packets. TCP gives TACACS+ retransmission and connection state, so a failed login is a failed login rather than a timeout you cannot distinguish from a dead server. RADIUS over UDP requires you to configure per-server timeouts and retransmits and to reason about which response arrived from where. On a management network with a handful of servers, that is a small but real operational difference.

Per-Command Authorization Is the Killer Feature

On TACACS+ the AAA server decides, per command, whether an operator may run it - including arguments. That is how you give a junior NOC engineer show everywhere and conf t nowhere, without creating a dozen local privilege levels and hoping the vendor implements them identically.

! Cisco IOS: TACACS+ with authorization on exec and commands
aaa new-model
aaa authentication login default group tacacs+ local
aaa authorization exec default group tacacs+ local if-authenticated
aaa authorization commands 1 default group tacacs+ if-authenticated
aaa authorization commands 15 default group tacacs+ local if-authenticated
aaa accounting exec default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+

tacacs server TAC1
 address ipv4 10.10.10.60
 key <secret>
tacacs server TAC2
 address ipv4 10.10.10.61
 key <secret>

aaa group server tacacs+ TACACS-GRP
 server name TAC1
 server name TAC2

Note the if-authenticated / local fallback. Getting this wrong is the classic self-inflicted outage: the ACS server dies, or the switch loses its route to it, and nobody can log in - including over the console if the console is also pointed at TACACS+ with no local fallback.

Accounting: What You Must Be Able to Prove

TACACS+ accounting records which commands which user ran, with the start and stop of each. RADIUS records sessions and byte counts. If your change-control or audit process needs 'who typed this command, when, and what was the result', that requirement alone selects TACACS+.

The Hybrid Most Enterprises Actually Run

• TACACS+ for administrative CLI access to switches, routers and firewalls.
• RADIUS for 802.1X/MAB, VPN, Wi-Fi and any supplicant-based access.
• Local accounts as the last-resort fallback, with passwords in a vault, enabled only on the console or out-of-band path.

One trap with the hybrid: identity can drift. If the same human is jdoe in RADIUS and john.doe in TACACS+, correlation during an incident becomes manual work. Standardise the username schema across both directories before you deploy, not after.

Availability Design

1. At least two servers, in different failure domains, reachable over the management network.
2. Per-device local fallback configured and tested - actually test it by blocking TCP 49, not by assuming.
3. Source-interface and routing verified for the management VRF on every device.
4. Time synchronised: TACACS+ and RADIUS logs are useless in an investigation if device clocks differ by minutes.

Related reading on this site: TACACS+ accounting and command authorization in more depth, RADIUS CoA and disconnect messages for access networks, and serial console servers as the out-of-band path that saves you when AAA is unreachable.

原文链接：https://datatracker.ietf.org/doc/html/rfc8907