ArubaOS-CX TACACS+ Command Authorization

TACACS+ on ArubaOS-CX is straightforward until you enable command authorization, at which point a single ordering mistake can leave a switch where no command is permitted — including the commands you would use to fix it. The settings that prevent that outcome are authorization fail-through, explicit local fallback at the end of every group list, and checking the effective configuration with show commands before you log out of the console. This guide covers the full configuration with those safety rails, plus the verification and recovery steps for a switch that has already locked itself out.

The pieces of AOS-CX remote AAA

Authentication decides who you are, authorization decides what you may run, accounting records what you ran. On AOS-CX only TACACS+ can provide remote command authorization; RADIUS can authenticate and account, but authorization falls back to local RBAC groups (administrators, operators, auditors). Each connection type — console, SSH, telnet, default — is configured separately, which is exactly what you want: console authorization should always end in local.

Configuring the server, ordering and fallback

tacacs-server host 10.20.0.11 key plaintext S3cretKey1
tacacs-server host 10.20.0.12 key plaintext S3cretKey1
tacacs-server timeout 5
tacacs-server tracking interval 60
aaa server group tacacs-group
 server 10.20.0.11
 server 10.20.0.12

aaa authentication login default group tacacs-group local
aaa authentication login console local
aaa authorization commands default group tacacs-group local
aaa authorization commands console local
aaa authorization commands ssh group tacacs-group local
aaa accounting commands default start-stop group tacacs-group
aaa accounting commands ssh start-stop group tacacs-group

Read the authorization lines carefully: the group list must end with local or none. If every listed server is unreachable and no local fallback is present, command execution is denied for everyone. Note also the asymmetry — local authorization is attempted only when no server in the list can be reached; if a server answers but rejects the command, the command fails and local is never consulted.

Fail-through and the order it must be configured in

HPE's own guidance is explicit: configure authorization fail-through before authentication fail-through. If authentication fail-through is enabled first, a user can authenticate successfully locally and then be unable to run anything because authorization still points at an unreachable server list with no fallback.

aaa authorization commands fail-through
aaa authentication login fail-through

This ordering matters most during initial rollout. A practical plan is to roll out authentication first (group + local fallback), verify that an SSH login reaches the TACACS+ server, then enable authorization with the group list ending in local, and finally add accounting once command authorization is proven stable.

Verification before you leave the console

Do not close the console session until all of the following are true.

show tacacs-server statistics
show aaa authentication
show aaa authorization
show aaa accounting
show user-list
show accounting log

Then test the path that actually breaks in production: block the TACACS+ servers in a lab or shut the server on the management network, log in over SSH, and confirm you can still enter configuration mode and run commands. If the test login works but commands are denied, the fallback keyword is missing from the authorization list. Also verify that a local administrator account exists with a known password — a switch with only remote authentication configured and no reachable server has no way in except a console factory reset.

Recovery from a locked-out switch

If command authorization has made the switch unusable, the console is the only way back. Log in on the console (where authorization is configured as local if you followed the template), then correct the authorization list or remove the remote authorization entry. If the source configuration was copied from another switch that already contained the authorization lines, the switch can enter a state where nothing executes; the documented recovery is a hard reboot with the configuration corrected offline — which is why the fail-through penalty note exists in the HPE documentation.

Command authorization with local user groups

When authorization falls back to local, the fallback is not "no restrictions" — it is the switch's role-based access control. Built-in groups are administrators, operators and auditors; anything else you need has to be a user-defined group with command authorization rules. That distinction matters for the design of the fallback: if remote authorization normally restricts a group of engineers to a subset of commands, the local fallback should mirror that subset, otherwise a TACACS+ outage quietly grants everyone administrative rights.

user-group NOC-ENGINEERS
  allow-command show *
  allow-command configure terminal
  forbid-command configure terminal
  allow-command interface *
  allow-command no shutdown
  deny-command reload *
!
user admin group administrators password ciphertext <hash>
user network-dennis group NOC-ENGINEERS password ciphertext <hash>

show user-group
show user-group NOC-ENGINEERS commands
show user-list

Rules are evaluated in order, so the ordering principle is: allow the narrow set of commands the role needs, then deny the dangerous classes explicitly. forbid-command entries are worth adding even when a deny-by-default posture exists, because they produce a clear error message and a log entry when someone with a legitimate reason tries to run them — which is exactly the signal you want for reload and erase operations.

Accounting: the audit trail that answers "who did it"

Accounting is configured separately from authorization and sends command records to the TACACS+ servers. It is the component that turns an incident review from guesswork into evidence, so enable it for both the SSH and console paths. The interesting reading is not one line but a sequence: the commands a user ran before something broke are the fastest way to explain a change nobody remembers making.

aaa accounting commands ssh start-stop group tacacs-group
aaa accounting commands console start-stop group tacacs-group
aaa accounting commands default start-stop group tacacs-group

show accounting log all
show accounting log last 20
show aaa accounting
show tacacs-server statistics

If accounting records are missing while authentication works, check the group exists and the server is reachable on the accounting port; accounting failures do not block command execution, so a broken accounting path is silent until you need the records. The local show accounting log is the last-resort copy and keeps only a limited number of entries, which is another reason to push to the server.

Diagnosing TACACS+ authentication failures

Work outward from the switch. First confirm the server list and shared key are right — a key mismatch produces an authentication failure indistinguishable from a wrong password, and it is the most common cause of "the password is definitely correct". Then confirm reachability on port 49 in the management VRF, because a management VRF that is not included in the server definition is a classic silent failure.

show tacacs-server
show tacacs-server host 10.20.0.11
show vrf mgmt
ping 10.20.0.11 vrf mgmt
show aaa authentication
show logging -r | include -i tacacs

Symbolic error output is your friend during rollout: enabling it shows the specific failure (key mismatch, timeout, unexpected response) rather than a generic denial. Timeouts deserve their own attention — if the servers are slow, increase the timeout before shortening it, and enable tracking so the switch stops sending to an unresponsive server and moves to the next one in the list. During a rollout, keep the console configured local so that a broken management network cannot lock you out of the recovery path.

Rollout sequence and rollback

1. Create the server groups and verify reachability from the management VRF.
2. Configure authentication with group ... local for SSH and default, leave console local, and verify a login with a known user.
3. Configure authorization with fail-through enabled before authentication fail-through, per the vendor's own ordering guidance.
4. Configure accounting.
5. Verify from a second session — never the session you configured in — and only then log out of the console.

Rollback is a matter of ordering the reverse: remove authorization first, then authentication, then accounting. If a switch has become unusable because authorization rejects everything, the console path (configured local) is the way in; where even that is unavailable, the documented consequence is a hard reboot with a corrected configuration, which is the outcome the fail-through and fallback settings exist to prevent.

FAQ

Can RADIUS do command authorization on AOS-CX? Remote authorization requires TACACS+. RADIUS is fine for authentication and accounting, with local RBAC handling what a user may run.

What happens if the TACACS+ server answers but denies the command? The command fails and local authorization is not attempted. Fallback triggers only when no server in the list can be reached.

Do I need two server entries? Yes for availability: two servers in one group, and the group named last in the authorization list followed by local.

How do I test the fallback safely? Block the TACACS+ servers with a firewall rule on a maintenance test switch, log in over SSH, and confirm you can enter configuration mode. Do it on a test device first, not on the core.

Quick reference: the commands that matter most

Six lines are worth memorising, because they are the ones you will type under pressure during a rollout or an incident. Authentication order, authorization order with local fallback, fail-through, server tracking and the two verification commands that show you the effective configuration rather than the intended one.

aaa authentication login default group tacacs-group local
aaa authorization commands default group tacacs-group local
aaa authorization commands fail-through
aaa authentication login fail-through
tacacs-server tracking interval 60
show aaa authorization && show aaa authentication

Two habits around them: apply authentication before authorization, and never leave a session until the second verification command has printed the local fallback at the end of the list. If the fallback is missing, the switch is one TACACS+ outage away from a console-only recovery.

Related Reading

Related reading: TACACS+ vs RADIUS for Network Device AAA: How to Choose, TACACS+ AAA Accounting and Command Authorization, OpenSSH Server Hardening: sshd_config Guide

原文链接：https://arubanetworking.hpe.com/techdocs/AOS-CX/10.16/HTML/security_8100-8360/Content/Rem_AAA_cmds/aaa-aut-com-10.htm