Cisco AAA with TACACS+ and ISE: Centralized Authentication and Authorization for IOS-XE Devices

If you’re still relying on local usernames and enable passwords to control access to your Cisco routers and switches, you’re one compromised credential away from a very bad day. Centralized AAA — Authentication, Authorization, and Accounting — is the standard for managing network device access in any environment that takes security seriously. In this guide, I’ll walk through configuring TACACS+ on IOS-XE from scratch and then integrate it with Cisco Identity Services Engine (ISE), including real command output so you know exactly what to expect.

What AAA Actually Does (and Why It Matters)

AAA is three separate functions bundled under one umbrella:

• Authentication — who are you? Validates credentials against a central directory.
• Authorization — what can you do? Controls which commands a user can execute.
• Accounting — what did you do? Logs every command typed, login event, and session duration.

Without AAA, you’re stuck with shared enable passwords, no per-user accountability, and no way to revoke access quickly when someone leaves the team. With centralized AAA via TACACS+ or RADIUS, you get a single pane of glass: one place to add/remove users, set privilege levels, and audit what happened on every device in your network.

TACACS+ vs RADIUS: Choose Wisely

Both protocols are widely supported on Cisco IOS-XE, but they serve different use cases:

Feature	TACACS+	RADIUS
Transport	TCP 49	UDP 1812/1813
Encryption	Full packet body	Password only
AAA separation	Yes (independent)	No (combined)
Command authorization	Native, per-command	Limited
Typical use	Network device admin	802.1X, VPN, WLAN

For managing CLI access to routers and switches, TACACS+ is the right choice. It separates authentication from authorization, supports per-command authorization (so you can restrict a NOC operator to read-only show commands), and encrypts the entire packet payload. RADIUS is better suited for 802.1X endpoint authentication — a topic for another day.

Lab Topology

For this guide, I’m using:

• Cisco Catalyst 9300 running IOS-XE 17.12.3
• Cisco ISE 3.3 (patch 2) as the TACACS+ server
• Management interface on VLAN 10 (192.168.10.0/24)
• ISE policy node at 192.168.10.50

If you don’t have ISE, you can test the IOS-XE configuration against a free TACACS+ server like tac_plus (open source) or TACACS.net. The IOS-XE commands are identical regardless of the server — only the server-side policy configuration differs.

Phase 1: Basic IOS-XE AAA Configuration

Step 1: Enable AAA

AAA is disabled by default. Enable it globally first — this command alone doesn’t change any login behavior yet:

Cat9300# conf t
Cat9300(config)# aaa new-model

Warning: Once you type aaa new-model, the device immediately falls back to local authentication for console access. Make sure you have a local fallback user configured before enabling AAA — otherwise you risk locking yourself out if the TACACS+ server is unreachable.

Cat9300(config)# username admin privilege 15 secret Str0ng!LocalPass
Cat9300(config)# username netops privilege 5 secret R3adOnly!Pass

Step 2: Define the TACACS+ Server

IOS-XE 16.3+ uses the newer tacacs server named-object syntax rather than the legacy tacacs-server host command:

Cat9300(config)# tacacs server ISE-PRIMARY
Cat9300(config-server-tacacs)# address ipv4 192.168.10.50
Cat9300(config-server-tacacs)# port 49
Cat9300(config-server-tacacs)# key 0 Tac@cs$ecr3tK3y!
Cat9300(config-server-tacacs)# timeout 5
Cat9300(config-server-tacacs)# exit

Cat9300(config)# tacacs server ISE-SECONDARY
Cat9300(config-server-tacacs)# address ipv4 192.168.10.51
Cat9300(config-server-tacacs)# port 49
Cat9300(config-server-tacacs)# key 0 Tac@cs$ecr3tK3y!
Cat9300(config-server-tacacs)# timeout 5
Cat9300(config-server-tacacs)# exit

Group the servers into a named AAA server group:

Cat9300(config)# aaa group server tacacs+ ISE-GROUP
Cat9300(config-sg-tacacs+)# server name ISE-PRIMARY
Cat9300(config-sg-tacacs+)# server name ISE-SECONDARY
Cat9300(config-sg-tacacs+)# ip tacacs source-interface Vlan10
Cat9300(config-sg-tacacs+)# exit

The source-interface directive ensures TACACS+ packets always originate from the management VLAN interface. This is critical when ISE has a device access policy restricting which IPs are allowed — consistent sourcing prevents intermittent auth failures. This is the kind of subtle issue that gets overlooked during troubleshooting sessions until you check the ISE live logs.

Step 3: Configure AAA Authentication

Cat9300(config)# aaa authentication login default group ISE-GROUP local
Cat9300(config)# aaa authentication login CONSOLE local
Cat9300(config)# aaa authentication enable default group ISE-GROUP enable

Breaking this down:

• login default — applies to all VTY lines (SSH/Telnet) by default. Tries ISE first, falls back to local if ISE is unreachable.
• login CONSOLE — separate named method list for the console, using local-only auth. Console should never depend on a TACACS+ server being up.
• enable default — controls who can enter privileged EXEC. ISE can return a privilege-15 attribute to skip the enable password entirely.

Apply the console method list to the console line:

Cat9300(config)# line con 0
Cat9300(config-line)# login authentication CONSOLE
Cat9300(config-line)# exit

Cat9300(config)# line vty 0 15
Cat9300(config-line)# login authentication default
Cat9300(config-line)# transport input ssh
Cat9300(config-line)# exit

Step 4: Configure AAA Authorization

Authorization controls what authenticated users can do. This is where TACACS+ really shines over RADIUS:

Cat9300(config)# aaa authorization exec default group ISE-GROUP local
Cat9300(config)# aaa authorization commands 1 default group ISE-GROUP local
Cat9300(config)# aaa authorization commands 15 default group ISE-GROUP local
Cat9300(config)# aaa authorization config-commands

• exec default — authorizes EXEC shell access (privilege level assignment).
• commands 1/15 — authorizes individual commands at privilege levels 1 and 15.
• config-commands — also authorizes commands typed in configuration mode (without this, config mode commands bypass authorization).

Step 5: Configure AAA Accounting

Cat9300(config)# aaa accounting exec default start-stop group ISE-GROUP
Cat9300(config)# aaa accounting commands 1 default start-stop group ISE-GROUP
Cat9300(config)# aaa accounting commands 15 default start-stop group ISE-GROUP
Cat9300(config)# aaa accounting connection default start-stop group ISE-GROUP

start-stop sends an accounting record when a session or command begins AND when it ends. This gives you full audit trail data in ISE — every command typed, by whom, on which device, with timestamps. This is invaluable for compliance (PCI-DSS, SOC 2) and incident response.

Phase 2: Cisco ISE Configuration

Adding the Network Device

In ISE, navigate to Administration → Network Resources → Network Devices → Add. Configure:

• Name: Cat9300-Core
• IP Address: 192.168.10.1 (or a /32 subnet for the specific device)
• Device Profile: Cisco
• TACACS+ Authentication Settings: Enable, set shared secret to match Tac@cs$ecr3tK3y!

For production environments, use Device Groups (Administration → Network Resources → Network Device Groups) to organize switches, routers, and firewalls. This lets you apply different TACACS+ policies per device type.

Creating TACACS+ Command Sets

Navigate to Work Centers → Device Administration → Policy Elements → Results → TACACS Command Sets.

Create two command sets:

Full-Access (for network engineers):

• Permit: .* (regex matching all commands)

NOC-ReadOnly (for helpdesk/NOC staff):

• Permit: show .*
• Permit: ping .*
• Permit: traceroute .*
• Deny: everything else (set default to Deny)

TACACS+ Profiles

Navigate to Work Centers → Device Administration → Policy Elements → Results → TACACS Profiles.

Engineer-Profile:

• Default Privilege: 15
• Maximum Privilege: 15

NOC-Profile:

• Default Privilege: 1
• Maximum Privilege: 5

The privilege level returned by ISE is automatically applied to the user’s EXEC session — no need to type enable if ISE returns priv 15.

Device Admin Policy Set

Navigate to Work Centers → Device Administration → Device Admin Policy Sets. Create a new policy set:

• Policy Set Condition: Device Type equals Network-Devices (or your device group)
• Authentication Policy: AD or Internal Users, protocol TACACS+
• Authorization Policy rules:
  • If group = Network-Engineers → Engineer-Profile + Full-Access command set
  • If group = NOC → NOC-Profile + NOC-ReadOnly command set
  • Default → DenyAccess

This layered policy approach mirrors how you’d approach VLAN segmentation — define explicit trust zones, and treat everything outside those zones as untrusted by default. The principle is the same whether you’re segmenting traffic at Layer 2 or constraining administrative privileges at Layer 7.

Verification and Testing

Test TACACS+ Connectivity

Cat9300# test aaa group ISE-GROUP sarah.chen TestPass123 new-code
Trying to authenticate with servergroup ISE-GROUP
User was successfully authenticated.

Check TACACS+ Server Status

Cat9300# show tacacs

Tacacs+ Server : 192.168.10.50/49  AdminState:UP   State:ALIVE
   Socket Opens:         47    Socket Closes:        47
   Total Packets Sent:  142    Total Packets Recv:  142
   Reference Count:       0    Single Connect:    FALSE
   Packets Dropped:       0

Tacacs+ Server : 192.168.10.51/49  AdminState:UP   State:ALIVE
   Socket Opens:          3    Socket Closes:         3
   Total Packets Sent:    9    Total Packets Recv:    9
   Reference Count:       0    Single Connect:    FALSE
   Packets Dropped:       0

Debug Authentication (use carefully in production)

Cat9300# debug tacacs
Cat9300# debug aaa authentication
Cat9300# debug aaa authorization

! SSH in as a test user, then:
Cat9300# undebug all

Typical successful auth debug output:

*Jun 20 14:23:11.445: AAA/AUTHEN/LOGIN (0x7F3E2A): Pick method list 'default'
*Jun 20 14:23:11.446: TPLUS: Queuing AAA Authentication request 47 for processing
*Jun 20 14:23:11.447: TPLUS: Authentication start packet created for 47
*Jun 20 14:23:11.448: TPLUS: Using server 192.168.10.50
*Jun 20 14:23:11.453: TPLUS: Received authen response status GET_PASSWORD
*Jun 20 14:23:11.461: TPLUS: Received authen response status PASS
*Jun 20 14:23:11.461: AAA/AUTHEN (47): status = PASS

Verify Accounting Records

Cat9300# show aaa sessions
Total sessions since last reload: 23
Session Id: 23
   Unique Id: 49
   User Name: sarah.chen
   IP Address: 10.0.0.55
   Idle Time: 00:00:12
   CT Call Handle: 0

In ISE, check Operations → TACACS → Live Logs to see real-time authentication and authorization events. The accounting logs under Operations → Reports → Device Administration → TACACS Accounting show every command typed per user per device.

Hardening and Best Practices

1. Secure the TACACS+ Key

Use key 0 followed by your plain-text key in the config — IOS-XE will encrypt it with Type 7 when you save. Better yet, use password encryption aes for Type 6 encryption (requires a master key configured with key config-key password-encrypt). Type 7 is trivially reversible; Type 6 is not.

Cat9300(config)# key config-key password-encrypt MyAESMasterKey123!
Cat9300(config)# password encryption aes

2. Restrict Management Access to a Dedicated VRF

If your network uses a management VRF (a standard practice aligned with what’s covered in our network security fundamentals guide), place the management interface in the VRF and then point your TACACS+ source-interface at it:

! Place management interface in the Mgmt VRF
Cat9300(config)# interface GigabitEthernet0/0
Cat9300(config-if)# ip vrf forwarding Mgmt-vrf
Cat9300(config-if)# ip address 192.168.10.1 255.255.255.0
Cat9300(config-if)# exit

! Tie TACACS+ traffic to that interface
Cat9300(config)# aaa group server tacacs+ ISE-GROUP
Cat9300(config-sg-tacacs+)# ip tacacs source-interface GigabitEthernet0/0
Cat9300(config-sg-tacacs+)# ip vrf forwarding Mgmt-vrf

3. Configure Fallback Carefully

The local fallback in your method lists only activates when the TACACS+ server is unreachable, not when authentication fails. A user with wrong credentials will get a FAIL from TACACS+ — they won’t silently fall through to local auth. This is the intended behavior.

4. Set Appropriate Timeouts

The default TACACS+ timeout is 5 seconds. If ISE takes longer than this (e.g., during heavy load or AD lookups), the device will try the next server in the group. Tune this based on your environment:

Cat9300(config-server-tacacs)# timeout 3
Cat9300(config-server-tacacs)# single-connection

single-connection keeps a persistent TCP session open to the TACACS+ server rather than opening/closing a new connection per authentication request. This reduces latency significantly on busy devices.

5. Monitor with EEM

You can use Cisco EEM scripts to alert when TACACS+ server state changes:

Cat9300(config)# event manager applet TACACS-DOWN
Cat9300(config-applet)# event syslog pattern "TPLUS.*unreachable"
Cat9300(config-applet)# action 1.0 syslog priority critical msg "TACACS+ server unreachable - falling back to local auth"
Cat9300(config-applet)# action 2.0 cli command "enable"
Cat9300(config-applet)# action 3.0 cli command "show tacacs" pattern "prompt"

Common Troubleshooting Scenarios

“Authentication failed” but credentials are correct

Check ISE Live Logs first. Common causes: device not in ISE network device list, shared secret mismatch, source IP not matching the device entry, or the ISE node handling TACACS+ is in a different PSN group than your policy.

Users authenticated but can’t run commands

Authorization is likely failing separately from authentication. Run debug aaa authorization and check for command set denials in ISE. Ensure aaa authorization config-commands is present if users need to enter configuration mode.

Sessions dropping randomly

Check show tacacs for “Packets Dropped” — this often indicates MTU issues on the management path. Also verify single-connection isn’t enabled if your ISE version doesn’t handle it reliably (ISE 3.x handles it fine; older versions had bugs).

Conclusion

Centralized AAA with TACACS+ and Cisco ISE is the baseline for any production network. It gives you per-user authentication, fine-grained command authorization, and complete accounting — the three pillars of a defensible network access strategy. The IOS-XE configuration is straightforward once you understand the method list model: define your servers, group them, then attach the groups to authentication, authorization, and accounting policies.

The ISE side requires more upfront work to configure device groups, command sets, and policy sets, but that investment pays dividends when you need to instantly revoke access, audit what a specific engineer did during a maintenance window, or demonstrate compliance to an auditor.

If you’re also looking to lock down what traffic can reach your router’s control plane in the first place, pair this AAA configuration with a solid Control Plane Policing policy — together, they form a layered defense that protects both who can log in and what can reach the device in the first place. Combined, these controls satisfy the management-plane requirements you’ll encounter in CIS Benchmarks for IOS-XE and most enterprise security frameworks.