Arista EOS AAA: TACACS+ and RADIUS Configuration

Managing dozens of Arista switches with local usernames does not scale, and auditors expect every login and every command to be traceable to a central identity store. EOS supports centralized AAA (authentication, authorization and accounting) against TACACS+ or RADIUS servers with local fallback. This guide shows the exact EOS configuration: defining the server and shared key, creating server groups, setting login and enable authentication, enabling exec authorization so TACACS+ can return role attributes, and accounting commands to syslog.

The three As are worth separating before you type anything, because EOS treats them as independent method lists. Authentication answers "who is this and did they prove it". Authorization answers "what are they allowed to do" - and on Arista this is expressed through roles, not through per-command permit/deny like a classic Cisco deployment. Accounting answers "what did they do" and, on EOS, records that to syslog rather than back to the AAA server. Getting the accounting path right is usually what an audit actually asks for, and it is the part most first deployments forget.

Adding the AAA Server and Key

switch(config)# tacacs-server host 192.168.1.1 key MyTacacsServerKey
switch(config)# tacacs-server key 0 MyTacacsServerKey

For RADIUS the equivalent is radius-server host 192.168.199.49 key test123. When the management plane runs in a VRF, append vrf MGMT to the host statement. Optionally pin the source address with ip tacacs source-interface Management1 (or ip radius source-interface) so the server sees a stable source IP for per-device policy.

The first line defines a per-server key, which gives you the ability to rotate keys on one server without touching the others. The second defines a global key applied to every server for which no per-server key is set. If both exist, the per-server key wins.

Two practical points about the key itself. First, the key is a shared secret - if it does not match character-for-character between the switch and the TACACS+ server, the server silently discards the request and the switch falls back to the next method with no useful error message. Typos that include a trailing space are a genuinely common cause of "AAA is broken" support tickets, so set the key with the keyboard, not by copy-paste from a document. Second, the key 0 form stores the key in clear text in the running configuration; use key 7 to store it obfuscated if your configuration backup process is not itself encrypted.

Adding the VRF qualifier matters in any environment where management lives in its own VRF - which is most modern designs:

switch(config)# tacacs-server host 192.168.1.1 vrf MGMT key MyTacacsServerKey
switch(config)# ip tacacs source-interface Management1 vrf MGMT

If you use a hostname rather than an IP, also configure a name server in the same VRF with ip name-server vrf MGMT 8.8.8.8, otherwise the lookup fails and every AAA request times out.

Configuring Authentication Methods

Authenticate SSH logins against the remote group first, falling back to local accounts, while the console keeps using only local users (useful when the AAA server is unreachable during an outage):

switch(config)# aaa authentication login default group tacacs+ local
switch(config)# aaa authentication enable default group tacacs+ local
switch(config)# aaa authentication login console local

EOS reads a method list left to right and stops at the first method that returns a definitive answer - accept or reject. That ordering is the whole design of the list:

• group tacacs+ first means central authentication is authoritative when the server is reachable.
• local last is the fallback. It only comes into play when the server is unreachable or times out, which is exactly the break-glass behaviour you want during an outage.
• login console local deliberately removes the server from the console path entirely, so physical access never depends on the network being healthy.

One nuance: because local is a fallback rather than a second opinion, an account that exists locally but is rejected by TACACS+ will not be retried locally. If the server says no, the answer is no. Design your fallback expectation accordingly - local accounts are for when the server is silent, not for when it says reject.

For full lockdown you can drop local from the default list, but then a TACACS+ outage locks out remote SSH entirely. Most teams keep the local fallback and simply restrict those accounts to a small, audited set of break-glass users with strong passwords and a policy that they are rotated after every use.

Authorization and Accounting

Enable exec authorization so the TACACS+ server can return the Arista role (for example Cisco ISE sending the Arista-AVPair with role network-admin or network-operator), then log every command typed by every user:

switch(config)# aaa authorization exec default group tacacs+ local
switch(config)# aaa authorization commands all default local
switch(config)# aaa accounting exec default start-stop logging
switch(config)# aaa accounting commands all default start-stop logging

Note that roles themselves are still defined locally on the switch - the AAA server only tells EOS which role to grant.

Two lines in that block do very different jobs and are easy to confuse. aaa authorization exec default group tacacs+ local authorizes the session itself - it is the mechanism by which the server assigns the user a role after authentication succeeds. aaa authorization commands all default local authorizes individual commands against the local role definition. On EOS you usually leave command authorization pointing at local, because the role the user received already carries the correct command permissions; the server influences which role, the switch enforces what that role can do.

The start-stop keyword in the accounting lines means send a record when the event starts and another when it ends - so an exec accounting record contains both the login and the logout with a duration, and a command record is a single log entry per command. The all keyword covers every privilege level; substitute a privilege level number (for example level 15) if you only want to log privileged commands and keep the syslog volume manageable.

Because EOS accounting writes to logging, the records land in your syslog stream rather than a file on the switch. That means your AAA audit trail is only as good as your syslog retention: make sure the switch's logging host points at a collector that stores the events for the period your auditors require, and that the clock is synchronised with NTP so the timestamps line up with the TACACS+ server's own records.

Roles and Privilege Levels

Authorization on EOS is role-based. The roles ship in a fixed set - network-admin, network-operator and network-monitor (read-only, no exec access) - and each one carries a defined set of permitted commands. When TACACS+ returns a role attribute, the user is placed in that role for the session, and every command they type is checked against it.

You can also attach roles locally to a username, which is how you build local fallback users that are more restricted than the default:

switch(config)# username breakglass privilege 15 role network-admin secret Str0ngPass!
switch(config)# username readonly role network-operator secret An0ther!Pass

A cleaner pattern is a custom role that grants exactly what a subset of operators need - for example reboot only, or running-config read access - so that the TACACS+ server can hand out a least-privilege role rather than full admin:

switch(config)# role myrole
switch(config-role-myrole)# 10 permit command enable.*
switch(config-role-myrole)# 20 permit command show.*

Each rule is numbered and evaluated in order, so you can layer a broad permit and then add a narrower deny above it for the one command you want to withhold. This is substantially more granular than plain privilege levels, and it is the reason Arista deployments rarely need the Cisco-style per-command TACACS+ authorization lists.

Using Server Groups (Optional)

switch(config)# aaa group server tacacs+ tac-grp-01
switch(config-sg-tacacs+)# server 192.168.1.1
switch(config-sg-tacacs+)# exit
switch(config)# aaa authentication login default group tac-grp-01 local

Server groups earn their place the moment you run more than one server. A group gives you a named, ordered list of servers, and EOS tries them in turn - so you can define a primary and a secondary TACACS+ server without enumerating them at every method list:

switch(config)# aaa group server tacacs+ tac-grp-01
switch(config-sg-tacacs+)# server 192.168.1.1
switch(config-sg-tacacs+)# server 192.168.1.2
switch(config-sg-tacacs+)# exit

Groups also let you separate concerns: a TACACS+ group for logins and command accounting, a RADIUS group for 802.1X or VPN authentication, each referenced from the method list that needs it. Mixing protocols inside a single group is not supported, so keep one group per protocol and combine them at the method list instead:

switch(config)# aaa authentication login default group tac-grp-01 group radius local

Verification

switch# show running-config | include aaa
switch# show aaa methods
switch# show tacacs+

The three commands answer three different questions. show running-config | include aaa confirms what you configured actually persisted. show aaa methods shows the resolved method lists - the authoritative view of the order EOS will use, which is worth checking because it catches the case where a method list you thought you replaced is still in effect. show tacacs+ (or show radius) shows the server state, which server is being tried, and counters for requests and timeouts - the first place to look when logins start failing.

For a live test, open a second SSH session while your existing one stays open, so a broken AAA change cannot lock you out entirely. If the new session authenticates and lands in the role you expect, run a few show commands and confirm the accounting records appear in the syslog collector before you close the original session.

Troubleshooting Common Problems

• Logins fall back to local but the server is up. Almost always a key mismatch. Set the same key with the key 7 form on both sides and retest; remember the server silently drops mismatched requests.
• Everything times out. Usually a VRF or source-interface problem. Confirm the server address is reachable from the VRF the switch uses - ping vrf MGMT 192.168.1.1 source Management1 - and that the source-interface statement names the right VRF.
• Authentication works but the user gets no write access. The TACACS+ server is not returning a role attribute, so the session falls back to the default. Check the exec authorization line is present and that the server profile sends the Arista vendor attribute.
• No accounting records. Either the aaa accounting lines are missing, or logging host is not set, or the syslog collector is filtering the facility. Verify with show logging on the switch first.
• Commands take seconds each. Command authorization is being sent to a remote server that is slow or unreachable. On EOS, leave command authorization pointing at local and let the role do the work.

Keep a console session or a documented break-glass local account available throughout any AAA change - it is the only reliable way back if the method list is misconfigured, and it is a one-line insurance policy that has saved many a change window.

Related Guides on This Site

Deciding between the two protocols? See RADIUS vs TACACS+ explained, and compare with the SNMPv3 setup guide for the monitoring side of management access.

原文链接：https://www.arista.com/en/um-eos/eos-user-security