A game studio's Nexus switches still accept a local network-admin login after both TACACS+ servers become unreachable. The AAA login method list names the TACACS+ group and then local. Why does that login succeed?
Select an answer to reveal the explanation.
Short Explanation
The AAA list is a line of cashiers, and local is the cashier at the end. You still get in with the local network-admin account because the list tries TACACS+ and then falls through to the local database when those servers stay silent. Accounting caches and routing keys are not the password store.
Full Explanation
An NX-OS authentication method list is tried in order. With the TACACS+ group first and local next, a timeout or an unreachable server causes the switch to try the local user database. The studio login succeeds because that local method is on the list and the local network-admin account exists, not because TACACS+ is still working. TACACS+ accounting records what happened. It does not cache passwords on the switch for later logins, so accounting cannot answer an authentication request during the outage. MACsec encrypts frames on a link after the session keys are negotiated. It does not authenticate a CLI user and it is not a fallback AAA method. A key chain holds keys for a protocol such as OSPF. It is not the user database AAA consults when an operator logs in. Caveat: if the method list had stopped at the TACACS+ group, the same outage would lock operators out, including the local account, so the local method has to be present on purpose. Operational check: with the TACACS+ servers unreachable, log in with the local account, then restore the servers and confirm a TACACS+ user is authenticated by the servers again.