AAA with TACACS+ Lab: Configure and Troubleshoot

What you'll build

A router that authenticates administrators against a TACACS+ server, with a local account as the safety net. You'll build it one step at a time with a verify command after every step, prove a server-only user can log in, then break it three ways and read each fault straight from debug tacacs.

The one card to memorize

AAA login fails at exactly three layers, and each has its own signature in debug tacacs:

Think like the defender first

Before you type, answer three questions about the router's management plane:

• What happens if the TACACS+ server is unreachable? If the answer is "nobody can log in", you've built a denial of service into your own network. That's why every method list here ends with local.
• What happens if someone types the wrong password? It should fail, and a reachable server's "no" must be final. If a reject fell through to the local database, an attacker could keep guessing against your weakest password store.
• How will you know it works before you depend on it? You test the server with test aaa before you point the login lines at it, and you keep your console session open the whole time.

Where to run this lab

This lab needs real IOS behavior: an actual TACACS+ exchange, real rejects, and debug tacacs output. Packet Tracer can configure basic AAA with its AAA server device, but it has no debug tacacs, so the troubleshooting half of the lab doesn't work there.

If you build your own server, the classic open-source tac_plus daemon needs only a few lines. This matches the lab's accounts (classic tac_plus syntax; tac_plus-ng uses a different format):

key = "Cisco!23"

user = user1 {
    login = cleartext "Cisco!23"
    service = exec {
        priv-lvl = 1
    }
}

user = admin1 {
    login = cleartext "Cisco!23"
    service = exec {
        priv-lvl = 15
    }
}

Then add the router as a client. With tac_plus the shared key above covers every client; on ISE, add the router under Network Devices with its IP and the same shared secret, and enable the Device Administration service.

Lab values only. Cisco!23, the IPs and the cleartext Telnet login in this lab come from a training sandbox. Never reuse them on real equipment. The production version of this configuration is at the end of the lab.

Topology and accounts

                         TCP 49 (TACACS+, body encrypted with the shared key)
   +--------------+  -------------------------------------->  +--------------------+
   |  Router R8   |                                            |  TACACS+ server    |
   |              |        shared key: Cisco!23                |  192.168.1.100     |
   |  Loopback0   |                                            |                    |
   |  8.8.8.8     |                                            |  admin1 (also      |
   |              |                                            |   local on R8)     |
   |  VTY 0-15 <--+-- telnet 8.8.8.8 from R8 itself            |  user1 (server     |
   |  Console 0   |                                            |   only)            |
   +--------------+                                            +--------------------+

Why two accounts? admin1 exists on the server and locally, so a successful admin1 login can't prove which one answered. user1 exists only on the server. If user1 logs in, TACACS+ did the work. That's the whole proof.

Why telnet 8.8.8.8? It's a quick way to open a VTY session on the same router from the console, without a second device. In production you'd use SSH from an admin workstation; the hardening section shows how.

Part 1: baseline (prove AAA is off)

Capture the "before" state. It's what makes the "after" convincing.

show run | include aaa
show run | include username
show privilege

Read the output:

• no aaa new-model: AAA is off. Some images print nothing here instead; both mean the same thing.
• No username lines: there's no local account yet. If you turned on AAA right now, you could lock yourself out.
• Current privilege level is 15: you're on the console at full privilege. Keep this console session open for the entire lab. It's your way back in if a later step goes wrong.

Part 2: build it, verifying every step

Step 1: local lifeboat account, then AAA on

aaa new-model makes AAA authoritative for every login path the moment you press Enter. Create the local fallback account first.

configure terminal
 username admin1 privilege 15 secret Cisco!23
 aaa new-model
end
show run | include aaa new-model
show run | include username

Read the output:

• aaa new-model is now in the running config.
• username admin1 privilege 15 secret 5 $1$...: the password is stored as a hash, not in cleartext. Type 5 is MD5, which is old. On modern IOS XE, CIS Benchmarks expect a stronger hash: username admin1 privilege 15 algorithm-type scrypt secret <password> stores it as type 9.
• %SYS-5-CONFIG_I: Configured from console by admin1: every configuration change is logged with who made it. That log line is what drift detection and accounting build on.

Step 2: define the TACACS+ server

configure terminal
 tacacs server Our-TACACS
  address ipv4 192.168.1.100
  key Cisco!23
end
show run | section tacacs server
show tacacs
show aaa servers

Read the output:

• Our-TACACS is only a local name for the server. The address and port (49) are what matter.
• key Cisco!23 shows in cleartext in the running config. Anyone who sees a config backup sees the key. CIS Benchmarks call for encrypting stored secrets: service password-encryption (weak type 7), or on IOS XE, key config-key password-encrypt plus password encryption aes, which stores the key as type 6.
• show tacacs counters are all 0: the router hasn't talked to the server yet. Remember these zeros; Step 3 makes them move.
• show aaa servers printed nothing. That's not a fault. On classic IOS and IOSv it barely reports TACACS+ servers. show tacacs is the reliable counter view on this router. (show aaa servers fills in after a test using the new-code path, and it's the main view on IOS XE.)

Step 3: prove the server answers before you rely on it

This is the habit the exam rewards: never point login lines at a server you haven't tested. First reachability:

ping 192.168.1.100

Success rate is 100 percent: IP reachability works. But ping uses ICMP, not TCP 49. A firewall can allow one and block the other, so a good ping doesn't prove TACACS+ reachability. The next command does.

test aaa group tacacs+ admin1 Cisco!23 legacy
test aaa group tacacs+ user1 Cisco!23 legacy

Read the output:

• User was successfully authenticated for both users.
• user1 succeeding is the proof: it has no local account, so only the server could have said yes.
• test aaa authenticates without changing your login configuration. It's a safe dry run you can repeat as often as you like.
• legacy uses the older, most compatible test path. new-code runs through the full server-group machinery (and updates show aaa servers). If your release doesn't accept legacy, use new-code.

show tacacs

Read the output: Socket opens 2, Socket closes 2: each test opened one TCP session to port 49 and closed it cleanly. Packets sent 4, received 4: two exchanges per login (the start and the password). Compared with the zeros in Step 2, this is hard evidence that R8 talked to the server.

Step 4: point the VTY lines at TACACS+, with a fallback

configure terminal
 aaa authentication login TAC-Login group tacacs+ local
 line vty 0 15
  login authentication TAC-Login
end
show run | section line vty
show run | section aaa

Read the method list left to right: try the TACACS+ servers first; if none answers, use the local database.

Read the output:

• login authentication TAC-Login appears under both line vty 0 4 and line vty 5 15. IOS splits the range, but one command covered all 16 lines.
• aaa authentication login TAC-Login group tacacs+ local is in the AAA section. The name on the line and the name of the list match exactly; a one-letter difference would silently break it.
• transport input all and exec-timeout 60 0 are lab defaults a CIS audit would flag: production needs transport input ssh and an idle timeout of 10 minutes or less.
• aaa session-id common is a default that appears with AAA; leave it.

Two traps live in this one line:

1. No local = lockout. With only group tacacs+, a dead server means nobody logs in.
2. local is used only when no server answers, never after a reject. A wrong password from a reachable server is final.

Step 5: set enable secret

TACACS+ authenticated the login, but privileged EXEC is a separate check. A TACACS+ user lands at privilege 1, and enable needs its own password. Without one, enable fails.

configure terminal
 enable secret Cisco!23
end

This is the simplest fix and what the lab uses. The better production options are to authenticate enable against the server (aaa authentication enable default group tacacs+ enable) or to have the server hand out privilege 15 at login (aaa authorization exec, Part 6).

Part 3: prove remote login uses TACACS+

From the console:

telnet 8.8.8.8
  Username: user1
  Password: Cisco!23
enable
  Password: Cisco!23
show users
show run | include username

Read the output:

• con 0 belongs to admin1: your safety session on the console.
• vty 0 belongs to user1, connected from 8.8.8.8. A user with no local account just logged in to a VTY line. Only the TACACS+ server could have authenticated it.
• show run | include username still lists only admin1, confirming user1 is purely a server identity.

Type exit to leave the VTY session and return to the console.

Part 4: break it three ways, then fix it

Every break uses the same loop: turn on the debug, run the test, read the one key line, fix, test again.

debug tacacs
test aaa group tacacs+ user1 Cisco!23 legacy
...
undebug all

Break 1: wrong shared key (device trust)

configure terminal
 tacacs server Our-TACACS
  key Cisco
end
debug tacacs
test aaa group tacacs+ user1 Cisco!23 legacy

Read the output, line by line:

1. Opening TCP/IP to 192.168.1.100/49 then Opened TCP/IP handle: the TCP connection succeeded. Reachability is fine.
2. AUTHEN/START/LOGIN/ASCII queued and processed: the router sent its request, encrypted with the wrong key.
3. received bad AUTHEN packet: type = 0, expected 1: the reply decrypted to garbage.
4. Invalid AUTHEN/START/LOGIN/ASCII packet (check keys): IOS names the cause for you. Trust failed.

Read the debug, not the summary. The test aaa result says No authoritative response from any server, which sounds like a reachability problem. If you trusted that line, you'd waste time on routing and firewalls. The debug shows the connection opened and the key failed. Always check the debug before you choose a fix.

Fix it: put the key back and test again.

configure terminal
 tacacs server Our-TACACS
  key Cisco!23
end
test aaa group tacacs+ user1 Cisco!23 legacy

This is what a healthy exchange looks like: connection opened → GETPASS (the server asks for the password) → send AUTHEN/CONT (the router sends it) → status = PASS → connection closed. Compare every failure against this.

Break 2: wrong password (user credentials)

test aaa group tacacs+ user1 WrongPass legacy

Read the output: the exchange gets further than Break 1. The connection opens, the key is fine (no "check keys"), the server asks for the password (GETPASS), and then answers status = FAIL. The summary line says it plainly: User authentication request was rejected by server.

The server is healthy and understood the request; it chose to say no. That's layer 3, the user's credentials. And because this is a reject, not an error, the local fallback in TAC-Login would not be tried on a real login.

Fix it: use the right password.

Break 3: wrong server IP (reachability)

configure terminal
 tacacs server Our-TACACS
  address ipv4 192.168.1.10
end
debug tacacs
test aaa group tacacs+ user1 Cisco!23 legacy

Read the output: Opening TCP/IP to 192.168.1.10/49 timeout=5, then nothing comes back. After 5 seconds: Connection timed out; remote host not responding and No authoritative response from any server. Unlike Break 1, there's no Opened TCP/IP handle line: the connection never existed.

This is layer 1, reachability. The possible causes: wrong IP (this case), routing, a firewall or ACL dropping TCP 49, or the server is down. Two variations worth knowing:

On a real login, this is where local saves you: no server answered, so IOS moves to the next method and admin1 can still log in.

Fix it:

configure terminal
 tacacs server Our-TACACS
  address ipv4 192.168.1.100
end
test aaa group tacacs+ user1 Cisco!23 legacy
undebug all

status = PASS again. (The first command in the screenshot has a typo, user 1, and IOS rejects it before anything is sent. A useful reminder to read error markers before blaming the server.)

Check the counters

show tacacs

Read the output:

• Socket opens = Socket closes: every session that opened was closed cleanly.
• Failed Connect Attempts 1: the wrong-IP test from Break 3, recorded against this server entry. On a production router, a climbing value here is an early warning that the server or the path to it is failing.
• The wrong key and wrong password tests don't show up as failures here: the TCP connection worked in both. Those faults live in the debug and the server's logs, not in the socket counters.

The debug decoder

Part 5: more breaks to try

The three breaks above are the headline cases. These are the faults that catch people in production. Try them with your console session open.

The money diagnostic (case 5): test aaa works but real logins never reach the server. test aaa talks to the server group directly and ignores your line configuration, so a working test plus a silent debug on login means the method-list binding is wrong, not the server.

Case 7 safely: set the list to aaa authentication login TAC-Login group tacacs+ (no local), point the server at 192.168.1.10, and try telnet 8.8.8.8 as admin1. You're denied, because there's no second method. Add local back and the same outage lets admin1 in. Keep the console open: it's your way back.

Part 6 (stretch): authorization and accounting

Authentication answers "who are you". Authorization and accounting answer "what may you do" and "what did you do".

configure terminal
 aaa authorization exec TAC-Exec group tacacs+ local
 aaa authorization commands 15 TAC-Cmd group tacacs+ local
 aaa accounting exec default start-stop group tacacs+
 aaa accounting commands 15 default start-stop group tacacs+
 line vty 0 15
  authorization exec TAC-Exec
  authorization commands 15 TAC-Cmd
end
show run | section aaa
show aaa sessions

Lockout risk: if command authorization points only at an unreachable server, an admin can log in and then have every command denied. Keep local (or if-authenticated) at the end of authorization lists too, and test with the console open.

Harden it for production

The lab uses Telnet, a cleartext key and one server to keep things simple. A CIS-aligned version looks like this:

username admin1 privilege 15 algorithm-type scrypt secret <strong-local-password>
aaa new-model
!
tacacs server ISE-1
 address ipv4 10.10.99.10
 key <long-unique-shared-secret>
tacacs server ISE-2
 address ipv4 10.10.99.11
 key <long-unique-shared-secret>
aaa group server tacacs+ ADMIN-TAC
 server name ISE-1
 server name ISE-2
 ip tacacs source-interface Loopback0
!
aaa authentication login VTY-AUTH group ADMIN-TAC local
aaa authorization exec VTY-AUTHZ group ADMIN-TAC local
aaa authorization commands 15 VTY-CMD group ADMIN-TAC local
aaa accounting exec default start-stop group ADMIN-TAC
aaa accounting commands 15 default start-stop group ADMIN-TAC
!
ip ssh version 2
line vty 0 15
 login authentication VTY-AUTH
 authorization exec VTY-AUTHZ
 authorization commands 15 VTY-CMD
 transport input ssh
 exec-timeout 10 0
 access-class MGMT-ONLY in

Check yourself

Answer config

username admin1 privilege 15 secret Cisco!23
aaa new-model
!
tacacs server Our-TACACS
 address ipv4 192.168.1.100
 key Cisco!23
!
aaa authentication login TAC-Login group tacacs+ local
!
enable secret Cisco!23
!
line vty 0 15
 login authentication TAC-Login
!
! Stretch (Part 6)
aaa authorization exec TAC-Exec group tacacs+ local
aaa authorization commands 15 TAC-Cmd group tacacs+ local
aaa accounting exec default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+
line vty 0 15
 authorization exec TAC-Exec
 authorization commands 15 TAC-Cmd

Exam mapping

Drill it with the flashcards and the mock exam.