AAA with TACACS+ Configuration

When a network grows beyond a handful of devices, managing local usernames on every router and switch becomes unscalable. A password change for one engineer means logging in to every device individually. A terminated employee's access must be revoked device by device — and one missed device leaves a permanent security gap. AAA (Authentication, Authorisation, and Accounting) solves this by centralising all three functions on a dedicated server, allowing a single policy change to instantly affect access across hundreds of devices.

TACACS+ (Terminal Access Controller Access-Control System Plus) is Cisco's preferred AAA protocol for device administration. It separates authentication, authorisation, and accounting into independent transactions, encrypts the entire payload (not just the password), and provides granular per-command authorisation — an engineer can be permitted to run show commands but denied configure terminal without any local IOS configuration changes. For port-based network access control using AAA, see 802.1X Port Authentication.

Before starting, ensure IP reachability from the router to the TACACS+ server — AAA uses TCP port 49 and requires a routed path. Complete Static Route Configuration or OSPF Single-Area Configuration for the routing prerequisite. For securing the VTY lines that AAA will protect, review SSH Configuration. For existing local authentication method knowledge, see AAA Authentication Methods.

1. AAA — Core Concepts

The Three AAA Components

Component	Question Answered	Example
Authentication	"Who are you?" — Verifies identity using credentials (username + password, certificate, token)	Engineer enters username jsmith and password — TACACS+ server validates credentials against its user database
Authorisation	"What are you allowed to do?" — Determines what commands, privilege levels, or resources the authenticated user may access	TACACS+ server returns privilege level 15 for jsmith but privilege level 7 (limited) for a junior engineer — each gets different IOS command access
Accounting	"What did you do?" — Records every session, command, and action for audit and compliance	TACACS+ logs: jsmith logged in at 09:14 from 192.168.10.5, ran `show running-config` at 09:15, ran `no shutdown` on Gi0/1 at 09:17, logged out at 09:32

TACACS+ vs RADIUS — Protocol Comparison

For a broader overview of AAA concepts and the RADIUS protocol, see AAA Overview and AAA RADIUS Configuration.

Feature	TACACS+	RADIUS
Transport	TCP port 49 — reliable, connection-oriented	UDP ports 1812 (auth) / 1813 (accounting)
Encryption	Entire payload encrypted	Only the password encrypted — other attributes in clear text
AAA separation	Authentication, Authorisation, and Accounting are fully separate — can use different servers for each	Authentication and Authorisation combined in a single response
Per-command authorisation	✅ Yes — can permit or deny individual IOS commands per user	❌ No — only privilege-level based authorisation
Primary use	Network device administration (routers, switches)	Network access control (VPN, wireless, dial-up users)
Vendor	Cisco proprietary (extended from original TACACS)	Open standard (RFC 2865)

AAA Method Lists — How They Work

A method list defines the ordered sequence of AAA methods IOS tries when authenticating or authorising a user. Methods are tried left to right — if the first method is unreachable (server down), IOS automatically falls back to the next:

  aaa authentication login VTY-AUTH group tacacs+ local

  User attempts SSH login to router VTY line
       ↓
  Method 1: group tacacs+ — query TACACS+ server(s)
       ↓ (if TACACS+ server unreachable)
  Method 2: local — check router's local username database
       ↓ (if no local user matches)
  Access DENIED

  Key: fallback only triggers on SERVER UNREACHABLE — not on wrong password.
       If the server responds with "wrong password", the login fails
       immediately. Fallback is not a second chance after a bad password.

Critical safety rule — always configure local fallback. If aaa new-model is enabled and the TACACS+ server becomes unreachable with no local fallback configured, no one can log in to the router — including the console. Always include local as the last method in authentication lists and ensure at least one privileged local user (privilege 15) exists before enabling AAA. If locked out, physical ROMMON password recovery is the only remedy.

Default vs Named Method Lists

Type	Name	Applied With	Scope
Default	`default`	Automatically — applies to all lines without an explicit method list	All VTY and console lines that don't have a named list assigned
Named	Any string (e.g., `VTY-AUTH`)	Explicitly: `login authentication VTY-AUTH` under `line vty`	Only the lines where the named list is explicitly applied

2. Lab Topology & Scenario

NetsTuts_R1 is the edge router and the device being secured. A Cisco ISE (Identity Services Engine) server acts as the TACACS+ server at 192.168.10.50. All remote management sessions to R1 (SSH on VTY lines) must authenticate via TACACS+. A local account is maintained as a fallback for when the TACACS+ server is unreachable. The console line uses local authentication only — a safeguard ensuring physical access always works:

         [Admin PC]              [TACACS+ Server]
         192.168.10.5            192.168.10.50 (Cisco ISE)
               |                       |
               └──────────┬────────────┘
                          |
                   192.168.10.0/24
                          |
                     Gi0/1 (INSIDE)
                     192.168.10.1
               ┌─────────────────────────────┐
               │        NetsTuts_R1           │
               │  aaa new-model               │
               │  TACACS+ server: .10.50      │
               │  VTY: TACACS+ → local        │
               │  CON: local only             │
               │  Local fallback: admin/priv15│
               └─────────────────────────────┘
                     Gi0/0 (WAN)
                     203.0.113.2

  Authentication flow:
  Admin PC → SSH to R1 → AAA method list → TACACS+ server (TCP/49)
  If TACACS+ unreachable → fallback to local username database

Line	Method List	Primary Method	Fallback	Reason
VTY 0–4 (SSH/Telnet)	VTY-AUTH	TACACS+	local	All remote logins centralised via TACACS+ with local emergency backup
Console (CON 0)	CON-AUTH	local	—	Physical access uses local accounts only — no server dependency for out-of-band access

3. Step 1 — Create Local Fallback Account First

This step must be completed before enabling aaa new-model. Once AAA is active, IOS immediately applies method lists to all lines. If no local user exists and the TACACS+ server is unreachable, all access — including console — is locked out. See Console & VTY Line Configuration for line-level prerequisites:

NetsTuts_R1>en
NetsTuts_R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

! ── Create local admin with privilege 15 BEFORE aaa new-model
NetsTuts_R1(config)#username admin privilege 15 secret NetsTuts@2026
NetsTuts_R1(config)#username noc    privilege 7  secret NOCread@2026

! ── Verify local users exist before proceeding ───────────
NetsTuts_R1(config)#do show running-config | include username
username admin privilege 15 secret 9 $9$...
username noc privilege 7 secret 9 $9$...

Two local users are created: admin at privilege 15 (full access — equivalent to enable mode) and noc at privilege 7 (limited read-only commands). The secret keyword uses MD5 (or Type 9 on newer IOS-XE) hashing — never use password for production accounts as it stores credentials in weaker encoding. These accounts serve two purposes: TACACS+ fallback when the server is unreachable, and console access that never depends on a network server.

4. Step 2 — Define the TACACS+ Server

IOS supports two syntax generations for defining TACACS+ servers — the legacy global command and the newer server-group model introduced in IOS 12.3+. The server-group model is preferred in modern deployments as it supports redundant servers, per-server timeout tuning, and cleaner configuration:

Method A — Legacy Global Command (older IOS)

! ── Legacy syntax — single server ────────────────────────
NetsTuts_R1(config)#tacacs-server host 192.168.10.50 key NetsTutsAAA@2026
NetsTuts_R1(config)#tacacs-server timeout 5

Method B — Server Group Model (preferred, IOS 12.3+)

! ── Define individual TACACS+ server ─────────────────────
NetsTuts_R1(config)#tacacs server ISE-PRIMARY
NetsTuts_R1(config-server-tacacs)#address ipv4 192.168.10.50
NetsTuts_R1(config-server-tacacs)#key NetsTutsAAA@2026
NetsTuts_R1(config-server-tacacs)#timeout 5
NetsTuts_R1(config-server-tacacs)#exit

! ── Optional: define a secondary server for redundancy ───
NetsTuts_R1(config)#tacacs server ISE-SECONDARY
NetsTuts_R1(config-server-tacacs)#address ipv4 192.168.10.51
NetsTuts_R1(config-server-tacacs)#key NetsTutsAAA@2026
NetsTuts_R1(config-server-tacacs)#timeout 5
NetsTuts_R1(config-server-tacacs)#exit

! ── Create a server group containing both servers ────────
NetsTuts_R1(config)#aaa group server tacacs+ TACACS-SERVERS
NetsTuts_R1(config-sg-tacacs+)#server name ISE-PRIMARY
NetsTuts_R1(config-sg-tacacs+)#server name ISE-SECONDARY
NetsTuts_R1(config-sg-tacacs+)#exit

The server group TACACS-SERVERS contains both servers — IOS queries them in order, failing over to the secondary if the primary does not respond within the timeout (5 seconds). The pre-shared key (key NetsTutsAAA@2026) must match exactly on both the router and the TACACS+ server configuration — this key encrypts the TACACS+ payload. A mismatch causes all AAA requests to fail with no informative error on the router.

TACACS+ Server Configuration Parameters

Parameter	Command	Default	Notes
Server IP	`address ipv4 [IP]`	—	The management IP of the TACACS+ server (ISE, ACS, FreeRADIUS with TACACS+ plugin)
Shared key	`key [string]`	—	Must match exactly on router and server — case-sensitive
Timeout	`timeout [seconds]`	5 seconds	How long IOS waits for a response before trying the next server or fallback
Port	`port [number]`	TCP 49	Only change if the TACACS+ server uses a non-standard port
Source interface	`ip tacacs source-interface [int]`	Outgoing interface	Set to loopback for consistent source IP in server logs — critical for IP-based whitelisting on the server

5. Step 3 — Enable AAA New Model

aaa new-model is the global command that activates the AAA framework on the router. This single command immediately changes how all authentication works — VTY and console lines no longer use their configured login / password settings and instead fall under AAA control:

! ── Enable AAA — do this AFTER local user and server are set
NetsTuts_R1(config)#aaa new-model

aaa new-model takes effect immediately. As soon as this command is entered, the default AAA behaviour applies — all lines require AAA authentication. If no method list is configured yet, IOS uses the built-in default which attempts local authentication. However, if a default method list is configured with only group tacacs+ and the server is unreachable, access is immediately locked out. Configure method lists immediately after aaa new-model in the same configuration session — do not save the config until the full AAA setup (server + method lists + line assignment) is complete and tested.

6. Step 4 — Create AAA Method Lists

Method lists define the authentication and authorisation sequence for each access scenario. Each list specifies an ordered set of methods IOS tries in sequence. Three types of AAA lists are configured here: login authentication, exec authorisation, and command authorisation:

Authentication Method Lists

! ── VTY authentication: TACACS+ first, local fallback ────
NetsTuts_R1(config)#aaa authentication login VTY-AUTH group TACACS-SERVERS local

! ── Console authentication: local only — no server dep ───
NetsTuts_R1(config)#aaa authentication login CON-AUTH local

! ── Default list: catches any line without explicit list ─
NetsTuts_R1(config)#aaa authentication login default group TACACS-SERVERS local

Three authentication lists are defined. VTY-AUTH: for SSH/Telnet — tries TACACS+ first, falls back to local if the server group is unreachable. CON-AUTH: console only — uses local accounts, never queries the network server. This ensures physical access always works even during a total network outage. default: a safety net — any line without an explicit method list assignment uses TACACS+ with local fallback.

Exec (Privilege Level) Authorisation

! ── Authorise exec (privilege level) via TACACS+ ─────────
! ── TACACS+ server assigns privilege level after login ───
NetsTuts_R1(config)#aaa authorization exec VTY-AUTHZ group TACACS-SERVERS local

The exec authorisation list determines what privilege level a user receives after successful authentication. The TACACS+ server can return privilege level 15 (full access) for senior engineers and privilege level 7 for read-only NOC staff — without any per-device configuration change. The local fallback assigns the privilege level defined in the local username command when the server is unreachable.

Command Authorisation (Per-Command Control)

! ── Authorise every privilege-15 command via TACACS+ ─────
NetsTuts_R1(config)#aaa authorization commands 15 VTY-CMD-AUTHZ group TACACS-SERVERS local

! ── Authorise privilege-1 commands (show commands) ───────
NetsTuts_R1(config)#aaa authorization commands 1 VTY-CMD-AUTHZ group TACACS-SERVERS local

Per-command authorisation is TACACS+'s most powerful feature — unavailable with RADIUS or local authentication. The TACACS+ server maintains a list of permitted commands per user. When an engineer runs configure terminal, the router sends the command to the TACACS+ server before executing it — the server approves or denies it based on the user's profile. This provides a complete audit trail of every command run on every device, satisfying compliance requirements.

Accounting (Session and Command Logging)

! ── Log exec session start and stop ─────────────────────
NetsTuts_R1(config)#aaa accounting exec default start-stop group TACACS-SERVERS

! ── Log every command run at privilege level 15 ──────────
NetsTuts_R1(config)#aaa accounting commands 15 default start-stop group TACACS-SERVERS

Accounting sends start and stop records to the TACACS+ server for each session and each command. start-stop sends a record when the session begins and when it ends — including the duration. Command accounting creates a log entry for every privileged command executed. This data is stored on the TACACS+ server and provides a complete audit trail for compliance (PCI-DSS, HIPAA, SOX) — "who ran what command, on which device, at what time." For additional login hardening, see Login Security & Brute-Force Protection.

Method List Reference Table

Command	Type	What It Controls	Applied To
`aaa authentication login [list] [methods]`	Authentication	Who can log in — validates username/password	VTY lines, console: `login authentication [list]`
`aaa authorization exec [list] [methods]`	Authorisation	What privilege level the user receives after login	VTY lines: `authorization exec [list]`
`aaa authorization commands [level] [list] [methods]`	Authorisation	Which specific IOS commands the user may run	VTY lines: `authorization commands [level] [list]`
`aaa accounting exec [list] start-stop [methods]`	Accounting	Records session start and stop events with timestamps	Applied globally via default list or per-line
`aaa accounting commands [level] [list] start-stop [methods]`	Accounting	Records every command executed at the specified privilege level	Applied globally via default list or per-line

7. Step 5 — Apply Method Lists to VTY and Console Lines

Creating method lists does not activate them — they must be explicitly applied to the relevant lines. VTY lines receive the TACACS+-backed lists. The console receives local-only authentication to guarantee out-of-band access never depends on network connectivity:

! ── VTY lines: TACACS+ auth, exec authz, cmd authz ───────
NetsTuts_R1(config)#line vty 0 4
NetsTuts_R1(config-line)#login authentication VTY-AUTH
NetsTuts_R1(config-line)#authorization exec VTY-AUTHZ
NetsTuts_R1(config-line)#authorization commands 15 VTY-CMD-AUTHZ
NetsTuts_R1(config-line)#transport input ssh
NetsTuts_R1(config-line)#exit

! ── Console line: local auth only ────────────────────────
NetsTuts_R1(config)#line console 0
NetsTuts_R1(config-line)#login authentication CON-AUTH
NetsTuts_R1(config-line)#exit

! ── Set TACACS+ source interface to loopback ─────────────
NetsTuts_R1(config)#ip tacacs source-interface Loopback0

NetsTuts_R1(config)#end
NetsTuts_R1#wr
Building configuration...
[OK]
NetsTuts_R1#

The three commands under line vty 0 4 link the method lists to the VTY lines. login authentication VTY-AUTH activates the authentication list. authorization exec VTY-AUTHZ enables privilege level assignment from TACACS+ after login. authorization commands 15 VTY-CMD-AUTHZ enables per-command checking for all privilege-15 operations. The ip tacacs source-interface Loopback0 global command ensures AAA requests always originate from the loopback IP — consistent regardless of which physical interface the packet exits.

8. Step 6 — Testing AAA and the Local Fallback

Testing both the primary (TACACS+) path and the fallback (local) path is essential before finalising the configuration. Test the fallback deliberately by temporarily making the server unreachable:

Test 1 — Normal TACACS+ Authentication

! ── From Admin PC — SSH to R1 ────────────────────────────
admin@adminPC:~$ ssh [email protected]
Password: [TACACS+ server validates jsmith's password]
NetsTuts_R1>
NetsTuts_R1>show privilege
Current privilege level is 15
NetsTuts_R1#

! ── On R1: verify the authentication method used ─────────
NetsTuts_R1#show aaa sessions
Total sessions since last reload: 4
Session Id: 4
  Unique Id: 7
  User Name: jsmith
  IP Address: 192.168.10.5
  Idle Time: 00:00:05
  CT Call Handle: 0

The user jsmith is authenticated by the TACACS+ server and receives privilege level 15 (assigned by the server's user profile). The session appears in show aaa sessions with the source IP and username — confirming AAA is active and attributing the session to a named user rather than an anonymous connection.

Test 2 — Fallback to Local Account

! ── Simulate TACACS+ server failure ─────────────────────
! ── (temporarily point to an unreachable IP for testing) ─
NetsTuts_R1(config)#tacacs server ISE-PRIMARY
NetsTuts_R1(config-server-tacacs)#address ipv4 192.168.10.99
NetsTuts_R1(config-server-tacacs)#exit

! ── From Admin PC — SSH attempt with local account ───────
admin@adminPC:~$ ssh [email protected]
Password: [TACACS+ timeout after 5 sec — falls back to local]
NetsTuts_R1#
NetsTuts_R1#show privilege
Current privilege level is 15

! ── Confirm fallback was used ────────────────────────────
NetsTuts_R1#show aaa local user lockout
No Locked Users

! ── Restore correct TACACS+ server IP ────────────────────
NetsTuts_R1(config)#tacacs server ISE-PRIMARY
NetsTuts_R1(config-server-tacacs)#address ipv4 192.168.10.50
NetsTuts_R1(config-server-tacacs)#exit

When the TACACS+ server IP is changed to 192.168.10.99 (unreachable), IOS waits the configured timeout (5 seconds), receives no response, and falls back to the local method. The local admin account logs in successfully with privilege 15. This confirms the fallback is working — without it, the login would fail with "Access denied" after the timeout. Always test this before deploying to production.

9. Verification

show aaa servers

NetsTuts_R1#show aaa servers
TACACS+ Server - public:
  Server name: ISE-PRIMARY
  Server address: 192.168.10.50/49
  Current status: UP
  Number of queries:      42
  Number of responses:    42
  Number of timeouts:      0
  Average response time:  12 ms

TACACS+ Server - public:
  Server name: ISE-SECONDARY
  Server address: 192.168.10.51/49
  Current status: UP
  Number of queries:       0
  Number of responses:     0
  Number of timeouts:      0

Current status: UP confirms the TACACS+ server is reachable. 42 queries / 42 responses / 0 timeouts confirms all 42 AAA requests received responses — no timeouts or failures. ISE-SECONDARY shows 0 queries — it has not been used yet, which means the primary is handling all requests correctly. Average response time of 12ms is healthy.

show aaa method-lists authentication

NetsTuts_R1#show aaa method-lists authentication
authen queue=AAA_ML_AUTHEN_LOGIN
  name=default      :  state=ALIVE :  ACTION_IF_ALIVE=PROCEED : ACTION_IF_DEAD=PROCEED : ACTION_IF_DENY=STOP
      Method list:   1. TACACS-SERVERS group
                     2. LOCAL
  name=VTY-AUTH     :  state=ALIVE :
      Method list:   1. TACACS-SERVERS group
                     2. LOCAL
  name=CON-AUTH     :  state=ALIVE :
      Method list:   1. LOCAL

All three authentication method lists are confirmed active — VTY-AUTH (TACACS+ then local), CON-AUTH (local only), and the default list. Status ALIVE means the methods are currently operational. This command is the authoritative view of what AAA method lists exist and their configured fallback order.

show tacacs

NetsTuts_R1#show tacacs
Tacacs+ Server - public:
Server name: ISE-PRIMARY
Server address: 192.168.10.50
Server port: 49
Socket opens:    8
Socket closes:   8
Total packets in: 42
Total packets out: 42
Reference count: 0

test aaa group — Live AAA Test

! ── Test authentication against TACACS+ without logging in
NetsTuts_R1#test aaa group TACACS-SERVERS jsmith NetsTutsPass123 legacy
Attempting authentication test to server-group TACACS-SERVERS using tacacs+
User was successfully authenticated.

test aaa group is the most direct way to verify TACACS+ authentication is working — it tests credentials against the server group without creating an actual management session. The keyword legacy is required for TACACS+ tests. "User was successfully authenticated" confirms the TACACS+ server received the query, validated the credentials, and returned a success response — end-to-end AAA verification in one command.

debug aaa authentication

NetsTuts_R1#debug aaa authentication
AAA Authentication debugging is on

AAA/BIND(00000009): Bind i/f
AAA/AUTHEN/LOGIN(00000009): Pick method list 'VTY-AUTH'
TPLUS: Queuing AAA Authentication request 9 for processing
TPLUS: send AUTHEN request to 192.168.10.50
TPLUS: recv AUTHEN response from 192.168.10.50 status=PASS
AAA/AUTHEN(00000009): status = PASS

NetsTuts_R1#undebug all

The debug trace shows the complete authentication transaction: the VTY-AUTH method list was selected, a TACACS+ request was sent to 192.168.10.50, and the server responded with PASS. This debug is the most granular AAA troubleshooting tool — it reveals which method list was used, which server was queried, and the exact response. Always disable after use: undebug all.

Verification Command Summary

Command	What It Shows	Primary Use
`show aaa servers`	TACACS+ server status (UP/DOWN), query/response/timeout counters, average response time	Verify server reachability and query success rate — UP + 0 timeouts = healthy
`show aaa method-lists authentication`	All authentication method lists with ordered methods and state	Confirm method lists exist and fallback order is correct
`show aaa sessions`	Active AAA-managed sessions — username, source IP, session duration	Confirm active sessions are attributed to named users (not anonymous)
`show tacacs`	TACACS+ server connection statistics — packets in/out, socket opens	Verify TACACS+ TCP connections are being established successfully
`test aaa group [group] [user] [pass] legacy`	Live credential test against a server group — reports pass/fail	End-to-end AAA test without creating a management session
`show line vty 0 4`	VTY line configuration including `login authentication` list assignment	Confirm method lists are applied to VTY lines

10. Troubleshooting AAA / TACACS+ Issues

Problem	Symptom	Cause	Fix
All logins denied after aaa new-model	SSH and console both reject all login attempts immediately after enabling AAA	No local user was created before `aaa new-model`, or the default method list only references TACACS+ with no local fallback and the server is unreachable	Access via console with physical access, use password recovery procedure to reset. Going forward: always create privileged local user first, configure local fallback, test before saving with `wr`
TACACS+ authentication fails — server UP	`show aaa servers` shows server UP but logins fail with "Access denied"	Pre-shared key mismatch — router and TACACS+ server have different keys. Or the user account does not exist on the TACACS+ server	Verify key: `show running-config \| include key` and compare with server config. Run `debug aaa authentication` — if server responds with FAIL (not timeout), it's a credentials issue. If TPLUS response shows error, suspect key mismatch
TACACS+ timeout — falling back every login	Every login takes 5+ seconds before succeeding with local account — TACACS+ always times out	TACACS+ server unreachable — wrong IP, UDP/TCP 49 blocked by ACL, routing issue, or server down	Ping the TACACS+ server IP: `ping 192.168.10.50 source Loopback0`. Check ACLs for TCP/49 blocking. Verify routing with `show ip route` 192.168.10.50. Check if the TACACS+ service is running on the server
Privilege level 1 after TACACS+ login	User authenticates successfully but drops to `Router>` (privilege 1) instead of `Router#` (privilege 15)	Exec authorisation not configured — TACACS+ assigns privilege level but IOS is not requesting it. Or the TACACS+ server user profile is returning privilege 1	Verify `aaa authorization exec` method list is configured and applied under `line vty`. Check the TACACS+ server user profile — confirm it returns `priv-lvl=15` for this user
Commands rejected after TACACS+ login	User has privilege 15 but specific commands are denied — "Command authorisation failed"	Per-command authorisation is enabled (`aaa authorization commands 15`) and the TACACS+ server is denying the specific command for this user's profile	Review the user's command permit list on the TACACS+ server. Use `debug aaa authorization` to see which commands are being sent for authorisation and what the server returns. Add the required commands to the user's profile on the server
Console locked out — CON-AUTH not working	Console login fails — the console prompts for credentials but local accounts are rejected	`login authentication CON-AUTH` under `line console 0` references a non-existent method list, or the local user was deleted	Use password recovery (break sequence at boot) to access ROMMON. Verify `show running-config \| section line con` — confirm the method list name matches. Ensure the local user exists: `show running-config \| include username`

Key Points & Exam Tips

AAA stands for Authentication (who are you), Authorisation (what can you do), and Accounting (what did you do). Each is a separate transaction in TACACS+ — they can use different servers.
TACACS+ uses TCP port 49 and encrypts the entire payload. RADIUS uses UDP and only encrypts the password. TACACS+ is preferred for device administration; RADIUS is preferred for network access control (VPN, wireless). See the full comparison in AAA RADIUS Configuration.
Create a privileged local user BEFORE enabling aaa new-model — once AAA is active, all lines fall under its control. No local fallback + unreachable server = complete lockout including console. Recovery requires ROMMON password recovery.
Method lists define the ordered sequence of AAA methods: aaa authentication login [name] group tacacs+ local. Fallback to local only triggers on server unreachable — not on wrong credentials.
The default method list applies automatically to all lines that do not have a named method list explicitly assigned — always configure it as a safety net.
Apply method lists to lines with login authentication [list] under the line — not ip access-group. Exec and command authorisation lists use authorization exec and authorization commands [level] under the line.
The console line should use local-only authentication — never make physical/out-of-band access dependent on a network server that may be unreachable during the exact moment you need emergency access.
test aaa group [group] [user] [pass] legacy is the quickest end-to-end AAA verification — tests credentials against the server group without creating a management session.
TACACS+ per-command authorisation is the protocol's most powerful feature — the TACACS+ server approves or denies each individual IOS command before it executes, providing complete audit control unavailable with RADIUS or local auth.
On the CCNA exam: know the difference between TACACS+ and RADIUS, what aaa new-model does, the method list fallback logic, the lockout risk, and the commands to apply method lists to VTY and console lines. Also ensure NTP is configured — accurate timestamps are essential for meaningful AAA accounting logs.

Next Steps: With AAA centralised on a TACACS+ server, every login and command is logged. To review what AAA events are being recorded on the router, check show logging and configure Syslog to forward these events to a central server. For the SSH configuration that AAA is protecting, revisit SSH Configuration. For adding Standard ACL source-IP restrictions on top of AAA for defence in depth, see Standard ACL Configuration — combining ACLs with AAA ensures only authorised source IPs can even attempt a login. For SNMP management traffic that also needs securing, see SNMP v2c/v3 Configuration.

TEST WHAT YOU LEARNED

1. An engineer enables `aaa new-model` on a production router without first creating a local user or configuring a method list with local fallback. The TACACS+ server is then restarted for maintenance. What happens?

A. All current SSH sessions are disconnected but new logins using local accounts still work B. IOS automatically reverts to pre-AAA authentication until the TACACS+ server recovers C. All logins — including console — are denied. With no local fallback configured and the TACACS+ server unreachable, there is no valid authentication method remaining. The router requires password recovery via physical ROMMON access to regain entry D. Only VTY logins fail — console access continues to work using the last successful login credentials

Correct answer is C. This is the most dangerous mistake in AAA deployment. Once aaa new-model is enabled, all lines — including the console — fall under AAA control. If the only method is group tacacs+ with no local fallback, and the TACACS+ server becomes unreachable, IOS has no valid authentication method and denies all logins. The console does not have a special bypass — it also uses AAA method lists after aaa new-model is enabled. Recovery requires physical access and ROMMON password recovery. The correct procedure is always: (1) create local privileged user, (2) configure method lists with local fallback, (3) apply to lines, (4) test, (5) only then enable TACACS+ as primary.

2. What is the key difference between TACACS+ and RADIUS that makes TACACS+ the preferred choice for Cisco device administration?

A. TACACS+ separates Authentication, Authorisation, and Accounting into independent transactions and encrypts the entire payload — most critically, it supports per-command authorisation allowing the server to approve or deny individual IOS commands. RADIUS combines auth and authorisation and only encrypts the password B. TACACS+ uses UDP which is faster than RADIUS's TCP connection — response times are lower C. TACACS+ is an open standard supported by all vendors — RADIUS is Cisco-proprietary D. RADIUS cannot authenticate network devices — it is only for end-user authentication

Correct answer is A. The defining advantage of TACACS+ for device administration is per-command authorisation — the ability to control exactly which IOS commands each user can execute. A junior engineer might be permitted show commands but denied configure terminal or reload. This granularity is impossible with RADIUS (which only assigns privilege levels) or local authentication. Additionally, TACACS+ full-payload encryption is more secure than RADIUS's password-only encryption. TACACS+ uses TCP (not UDP) providing reliable delivery. RADIUS is the open standard (RFC 2865); TACACS+ is Cisco's proprietary extension of the original TACACS protocol.

3. A method list is configured as: `aaa authentication login VTY-AUTH group TACACS-SERVERS local`. An engineer attempts SSH with a valid TACACS+ username but types the wrong password. Which method is tried next?

A. The local database is checked — wrong password triggers fallback to the next method B. The secondary TACACS+ server in the group is tried with the same credentials C. The login fails and IOS waits 3 seconds before allowing another attempt D. The login fails immediately — fallback only triggers when a server is unreachable (no response / timeout), not when the server responds with authentication failure. A FAIL response from TACACS+ is a definitive answer — wrong credentials. IOS does not try the next method.

Correct answer is D. This is one of the most misunderstood aspects of AAA method lists. The fallback sequence (e.g., TACACS+ → local) only advances to the next method when the current method is unreachable — no TCP connection established, timeout waiting for response. When the TACACS+ server responds with authentication failure (wrong password), that is a definitive answer — the user typed the wrong credentials. IOS does not try the local database as a second chance. If it did, an attacker could bypass TACACS+ by simply using a local account password after the TACACS+ rejection. The local fallback is strictly for server unavailability, not credential failure.

4. After configuring AAA, a user successfully authenticates via TACACS+ but lands at privilege level 1 (Router> prompt) instead of privilege level 15. What is the most likely cause?

A. The TACACS+ server is assigning privilege 1 to all users — this is the default until manually changed on the server B. The aaa authorization exec method list is not configured or not applied to the VTY line — IOS authenticated the user but never asked the TACACS+ server for the privilege level to assign. Without exec authorisation, IOS defaults to privilege 1 C. The user must manually type enable after logging in — TACACS+ never directly assigns privilege 15 D. Privilege level assignment requires RADIUS — TACACS+ only handles authentication

Correct answer is B. Authentication and exec authorisation are two separate AAA transactions in TACACS+. Authentication verifies the user's credentials. Exec authorisation asks the server "what privilege level should this user receive?" If aaa authorization exec [list] group tacacs+ is not configured and applied to the VTY line with authorization exec [list], IOS skips the privilege-level query and assigns the default (privilege 1). The fix is to add the exec authorisation list: aaa authorization exec VTY-AUTHZ group TACACS-SERVERS local and apply it under line vty with authorization exec VTY-AUTHZ. The TACACS+ server user profile must also return priv-lvl=15 for the authorised user.

5. Why is it a security best practice to configure the console line with local-only authentication rather than TACACS+?

A. Console lines do not support TACACS+ — only VTY lines can use server-based authentication B. Local authentication is faster than TACACS+ on the console due to baud rate limitations C. TACACS+ keys cannot be configured on console-accessible routers — the key would be visible during console logging D. The console is the out-of-band emergency access path — if TACACS+ becomes unreachable during a network emergency (exactly when physical access is most needed), a console that depends on TACACS+ for authentication would also be inaccessible. Local-only console auth ensures physical access always works regardless of network state

Correct answer is D. The console is the "break glass" access method — it is used precisely when network-based access (SSH, Telnet) is unavailable. A network outage, TACACS+ server crash, or misconfigured ACL might prevent SSH login — the console is the fallback. If the console also requires TACACS+ and the TACACS+ server is unreachable (which it will be during a network outage), the console becomes unusable at the exact moment it is most needed. By using local-only authentication on the console, physical access to the device always works with local credentials, independent of any network service. This is a fundamental security architecture principle: maintain an independent, network-free emergency access path.

6. What is the purpose of the `ip tacacs source-interface Loopback0` command?

A. Forces all TACACS+ requests to originate from the loopback IP address — ensuring a consistent source IP regardless of which physical interface the packet exits. The TACACS+ server can whitelist a single IP (the loopback). Without this, the source IP changes depending on routing — the server may reject requests from unexpected source IPs B. Routes TACACS+ traffic exclusively through the loopback interface — preventing it from using WAN links C. Enables TACACS+ to authenticate loopback interface management sessions D. Binds the TACACS+ server to the loopback address of the router — the server must be on the same device

Correct answer is A. This is the same loopback source principle used for NTP, DHCP relay, and OSPF. Without specifying a source interface, IOS uses the outgoing interface's IP as the source address in TACACS+ packets — this IP changes if routing changes or a link fails. The TACACS+ server (ISE, ACS) typically uses the source IP of AAA requests to identify the network device. If the source IP changes unexpectedly, the server may not recognise the device, reject the request, or fail to apply the correct device policy. Using the loopback ensures a stable, permanent IP for all AAA communications. The TACACS+ server's network device entry is configured with the loopback IP.

7. What does the `default` keyword mean in `aaa authentication login default group TACACS-SERVERS local`?

A. It sets the default password to use when all authentication methods fail B. It creates the factory-default AAA configuration that is restored on reload C. It creates the default method list — automatically applied to all lines (VTY, console, aux) that do not have a named method list explicitly assigned with login authentication [name]. It is a safety net ensuring every unassigned line still has an AAA policy D. It sets the default privilege level for authenticated users to the value defined in the TACACS+ server policy

Correct answer is C. The default method list has special behaviour — it is automatically applied to all lines that don't have an explicit method list assigned. Named lists (like VTY-AUTH or CON-AUTH) only apply where explicitly configured with login authentication [name]. Any line without a named list assignment falls back to the default list. This is important for security: if a new VTY line range (e.g., VTY 5–15) is added without an explicit method list, the default list ensures it still requires TACACS+ authentication rather than having no authentication. Always configure the default list as a comprehensive policy.

8. How does the `test aaa group TACACS-SERVERS jsmith pass123 legacy` command differ from simply SSHing into the router to test AAA?

A. The test command tests RADIUS only — SSH tests TACACS+ B. test aaa group validates credentials against the TACACS+ server without creating an actual management session — it is non-disruptive, can be run from within the router CLI (no second device needed), and reports a clear pass/fail for specific credentials. SSH testing requires a separate client, creates session overhead, and may be affected by other factors like ACLs or SSH keys C. The test command bypasses the method list — it directly queries the server even if the method list has not been applied to any line D. SSH testing is more reliable because it tests the complete stack — test aaa group only tests the network path to the server

Correct answer is B. test aaa group is a targeted diagnostic tool that isolates the AAA server query from all other factors. It tests: can the router reach the TACACS+ server, is the pre-shared key correct, and does the specified username/password authenticate successfully — all without opening a new management session. This is invaluable when testing during a maintenance window. SSH testing introduces variables: the SSH connection itself, ACLs on VTY lines, the method list application, and TACACS+ server response — any of these could cause failure. If SSH fails, you don't know which layer failed. If test aaa group passes but SSH fails, you've isolated the problem to SSH configuration or VTY ACLs, not AAA itself.

9. Per-command authorisation is configured with `aaa authorization commands 15 VTY-CMD-AUTHZ group TACACS-SERVERS local`. An engineer with privilege 15 runs `show version`. The TACACS+ server's profile for this user does not include `show version` in the permitted commands list. What happens?

A. The command runs — show commands are always permitted by default regardless of per-command authorisation B. The command is held pending until a TACACS+ admin adds it to the permitted list C. IOS falls back to the local database — since the local admin account is privilege 15, the command runs D. The command is denied with "Command authorisation failed" — when per-command authorisation is active, the TACACS+ server must explicitly permit each command. If the server's permit list does not include the command, it returns FAIL. The local fallback in the method list only applies if the server is unreachable, not if it returns a FAIL response

Correct answer is D. Per-command authorisation is a whitelist model — only explicitly permitted commands are allowed. The TACACS+ server must have each command in the user's permit list. If show version is not listed, the server returns FAIL (command not authorised). IOS displays "Command authorisation failed" and does not execute the command. The local fallback only activates on server unreachability — not on FAIL responses. This is intentional: if the fallback activated on command rejections, users could bypass the server's restrictions by waiting for a timeout. TACACS+ per-command authorisation requires careful configuration of the command whitelist on the server — often using regex patterns (e.g., permit "show .*" to allow all show commands).

10. `show aaa servers` shows the TACACS+ server status as DOWN with 47 timeouts. Logins are falling back to local accounts. What are the two most likely causes and what commands verify them?

A. Wrong username format and expired TACACS+ license — check show license B. Too many simultaneous sessions overwhelming the server — check show aaa sessions C. Two most likely causes: (1) No IP route to the TACACS+ server or an ACL blocking TCP/49 — verify with ping 192.168.10.50 source Loopback0 and show ip route 192.168.10.50. (2) Pre-shared key mismatch — verify with show running-config | include key and compare to server config. A key mismatch causes the server to silently ignore the encrypted request, appearing as a timeout D. The TACACS+ server's AAA process has crashed — check debug tacacs and restart the server process

Correct answer is C. When TACACS+ shows DOWN with timeouts (not FAIL responses), it means requests are being sent but no response is received. The two most common causes: (1) Network unreachability — the router cannot reach the TACACS+ server's IP on TCP/49. Verify with ping 192.168.10.50 source Loopback0 (must use the source interface configured for TACACS+). If ping fails, check routing with show ip route 192.168.10.50 and ACLs blocking TCP/49. (2) Key mismatch — a wrong pre-shared key causes the TACACS+ server to receive the packet but discard it (the encrypted payload cannot be decrypted), which appears from the router's perspective as a timeout (no response). Compare the key in running-config to the server-side configuration carefully — keys are case-sensitive.

Back to Home