Airport network admins must authenticate to network devices using a central TACACS+ server, yet still log in during WAN outages that isolate the AAA servers. Which AAA authentication pattern fits?
Select an answer to reveal the explanation.
Short Explanation
TACACS+ first keeps the airport on central identity; local fallback is the generator when the WAN to AAA dies. No whiteboard enable secrets, please.
Full Explanation
Airport network admins must authenticate to network devices using a central TACACS+ server, yet still log in during WAN outages that isolate the AAA servers. The AAA authentication pattern that fits is a method list that tries TACACS+ first and falls back to local: primary authentication is centralized for accountability and policy, while local usernames provide break-glass access when the WAN path to TACACS+ is down—exactly the outage scenario airports face when management traffic depends on the same WAN.
RADIUS accounting only with Telnet permitted without usernames fails by concept—accounting is not authentication, and Telnet without usernames weakens security. Disabling AAA entirely and sharing a single enable secret on a whiteboard removes centralized control and creates credential sprawl. ERSPAN of login prompts to a collector instead of authenticating users captures prompts; it does not authenticate administrators.
Exam caveat: authentication method lists are ordered; put TACACS+ (or RADIUS) first and local last for resilience. Ensure local users exist before you need them, and remember accounting/authorization are separate AAA legs.
Operational check for the airport: authenticate normally via TACACS+, then isolate AAA reachability in a controlled test and confirm local fallback succeeds on VTYs/console as designed, without permitting unauthenticated or Telnet-only access.