TACACS+ AAA Accounting and Command Authorization

Authentication with TACACS+ is the easy part. The value of TACACS+ over RADIUS is the other two A's: authorization of individual commands, and accounting that records exactly who ran what on which device. Getting those two right requires understanding a handful of Cisco IOS behaviours that are easy to get subtly wrong — the most common being that config commands are authorized by default unless you turn that off, and that a TACACS+ server with no command set defined will silently permit everything.

The baseline configuration

aaa new-model
!
tacacs server ISE1
 address ipv4 10.0.0.5
 key 0 SuperSecretKey
 timeout 5
!
aaa group server tacacs+ TAC
 server name ISE1
!
aaa authentication login default group TAC local
aaa authentication enable default group TAC enable
aaa authorization exec default group TAC if-authenticated
aaa authorization commands 15 default group TAC if-authenticated
aaa authorization commands 1 default group TAC if-authenticated
aaa accounting exec default start-stop group TAC
aaa accounting commands 15 default start-stop group TAC
aaa accounting system default start-stop group TAC

Order matters: the first method list entry is authoritative for the login path, the authentication side must succeed before authorization is consulted, and if-authenticated is what lets a user who authenticated successfully proceed if the TACACS+ server becomes unreachable at authorization time. A bare group TAC with no fallback is a genuine security posture and a genuine availability risk at the same time — decide deliberately.

Command authorization and the config-commands trap

! enabled by default - authorizes every command typed in config mode
aaa authorization config-commands
!
! reduces TACACS+ load dramatically, at the cost of authorizing only EXEC commands
no aaa authorization config-commands

With aaa authorization config-commands enabled (the default), every single command entered in configuration mode generates a TACACS+ authorization request. That is the only way to stop a user with EXEC access from reconfiguring the device, and it is also how you flood a TACACS+ server on a busy change window. Pick per platform: on core routers, keep it; on access switches where the same engineers do all the work, disabling it cuts request volume by an order of magnitude.

The corresponding server-side model is privilege-level command sets. A user is assigned a privilege level at exec time, and each command is authorized against the set for that level. Two consequences people miss: a user at privilege 15 with a restrictive command set can still be blocked from specific commands, and do-prefixed commands from EXEC mode are authorized as configuration commands.

Accounting: what the records actually contain

! wait for the IP/session to be fully set up before the start record
aaa accounting delay-start
!
! periodic interim updates for long sessions (minutes)
aaa accounting update periodic 15
!
! send a stop record even when the request is denied
aaa accounting send stop-record always
!
! count unsuccessful authorization attempts
aaa authorization policy... ! see note below
show aaa sessions
show tacacs
debug aaa accounting

start-stop gives you a record at the beginning and end of each command and each session. delay-start is specifically important on asynchronous or tunnel-based access: without it, the start record may not carry the assigned IP address, which makes correlation with a DHCP or VPN log impossible. A stop record that never arrives (device power loss, for example) is the classic accounting gap — the fix is usually an accounting update interval combined with server-side session aging.

Verification sequence

show aaa sessions
!  Total sessions since last reload: 3
!  Session Id: 12
!   Unique Id: 2147483647

show tacacs
! Tacacs+ Server : 10.0.0.5/49
!  Socket opens: 42
!  Failed Connect Attempts: 0
!  Aborts: 0

test aaa group tacacs+ netadmin Passw0rd legacy   ! prove reachability + creds

If authentication works but no accounting records arrive, check three things in order: the method list name must be default (or referenced explicitly on the line), the TACACS+ server must have accounting enabled for that device group, and the request must actually leave the router — debug tacacs shows the outgoing accounting packet.

Failure modes seen in production

• Everyone locked out after a policy change — no local fallback and no console access tested. Always validate on a console session before applying to the login line.
• Command authorization silently permissive — a user exists on the server but has no command set; most servers then permit the command. Define an explicit deny-by-default set.
• Accounting records with no username — the user was authenticated locally (fallback path) rather than by TACACS+.
• Request storm during config pushes — configuration management tools sending thousands of commands with config-commands enabled. Either disable it or exempt the service account.

If you are still choosing between the two server protocols, RADIUS vs TACACS+ for Cisco AAA covers the trade-offs, and RADIUS CoA and disconnect messages explains the dynamic-authorization equivalent on the RADIUS side.

原文链接：https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/security/a1/sec-a1-cr-book/sec-cr-a1.html