Auto Draft
Networking Technology

Cisco AAA with TACACS+ and ISE on IOS-XE: Authentication, Authorization, and Accounting for Network Engineers

Sarah Chen
11 min read

Every network engineer eventually faces the same uncomfortable question: who can log into your routers and switches, and what can they do when they get there? Default local credentials shared across dozens of devices are a security incident waiting to happen. Cisco’s AAA framework — Authentication, Authorization, and Accounting — combined with a TACACS+ server like Cisco ISE (Identity Services Engine) is the enterprise-grade answer. In this guide, I’ll walk through the complete IOS-XE configuration from scratch, including fallback local authentication, command authorization, and live troubleshooting tips.

What Is AAA and Why Does It Matter?

AAA stands for three distinct control functions:

  • Authentication — Verifies identity (“who are you?”). With ISE/TACACS+, credentials are validated against Active Directory or an internal identity store.
  • Authorization — Determines what an authenticated user can do (“what are you allowed to do?”). ISE can restrict commands per user or per group.
  • Accounting — Records what was done (“what did you do?”). Every command typed is logged centrally — critical for compliance and post-incident forensics.

Without centralized AAA, you’re stuck managing local usernames on each device, resetting shared passwords after staff turnover, and having zero visibility into who typed no shutdown on the wrong interface at 2 AM. TACACS+ (Terminal Access Controller Access-Control System Plus) is the preferred protocol for device administration because it encrypts the entire payload and separates authentication from authorization — unlike RADIUS, which only encrypts the password field and bundles auth and authz together.

If you’re already comfortable with basic Cisco security concepts, you may also want to review our home network security overview and CoPP guide for control plane protection — AAA fits naturally alongside those hardening measures.

TACACS+ vs RADIUS: Why TACACS+ Wins for Device Admin

A quick but important distinction before diving into config: TACACS+ and RADIUS are both AAA protocols, but they serve different use cases and have fundamental architectural differences.

Feature TACACS+ RADIUS
Transport TCP 49 UDP 1812/1813
Encryption Full payload Password only
Auth/Authz separation Yes (separate packets) No (combined)
Per-command authorization Yes Limited
Best use case Device admin (CLI access) Network access (802.1X, VPN)

For network device administration — locking down who can SSH into your routers and what commands they can run — TACACS+ is the right tool. RADIUS is ideal for 802.1X port-based access control and VPN user authentication. ISE supports both and uses them for their respective purposes.

Lab Topology

For this guide, I’m using:

  • Cisco Catalyst 9300 running IOS-XE 17.9.x
  • Cisco ISE 3.3 (can be virtual — ISE Evaluation licenses work fine for lab)
  • A Windows AD domain for user authentication (ISE joins as an AD agent)
  • Management VLAN 10 (192.168.10.0/24), ISE at 192.168.10.50

The same configuration translates directly to ASR 1000, ISR 4000, Nexus (with minor syntax changes), and any other IOS-XE platform.

Phase 1: Configure TACACS+ Servers on IOS-XE

Start by pointing the device at your ISE node(s). ISE acts as the TACACS+ server. You’ll configure a TACACS+ server group so you can specify multiple ISE Policy Service Nodes (PSNs) for redundancy.

! TACACS+ server definitions
tacacs server ISE-PSN1
 address ipv4 192.168.10.50
 key 7 <your-shared-secret>
 timeout 5

tacacs server ISE-PSN2
 address ipv4 192.168.10.51
 key 7 <your-shared-secret>
 timeout 5

! Server group
aaa group server tacacs+ ISE-TACACS
 server name ISE-PSN1
 server name ISE-PSN2
 ip vrf forwarding Mgmt-vrf
 ip tacacs source-interface GigabitEthernet0/0

A few important notes here. The key 7 notation means the key is stored in weak reversible encryption — if you’re copy-pasting a config, use key 0 followed by the plaintext and let IOS-XE encrypt it during write. The ip vrf forwarding Mgmt-vrf line is critical on platforms using a dedicated management VRF (which you should be using). The source interface ensures ISE sees traffic from a consistent, reachable IP rather than a transit interface that might fail.

Verify connectivity before going further:

Switch# test aaa group ISE-TACACS sarah.chen Password123 new-code
Attempting authentication test to server-group ISE-TACACS using tacacs+
User was successfully authenticated.

Switch# show tacacs
Tacacs+ Server : 192.168.10.50/49 [Current]
                 Socket opens:          42
                 Socket closes:         42
                 Total Packets Sent:    84
                 Total Packets Recv:    84
                 Failed to Send:         0
                 Replies Received:
                   Access-Accept:       21
                   Access-Reject:        0

Phase 2: Define AAA Methods

Now configure the actual AAA method lists. Always define a local fallback — this is what saves you from being locked out if ISE goes down during a config change.

! Enable AAA
aaa new-model

! Authentication method lists
aaa authentication login default group ISE-TACACS local
aaa authentication enable default group ISE-TACACS enable

! Authorization method lists
aaa authorization exec default group ISE-TACACS local if-authenticated
aaa authorization commands 1 default group ISE-TACACS local if-authenticated
aaa authorization commands 15 default group ISE-TACACS local if-authenticated
aaa authorization config-commands

! Accounting method lists
aaa accounting exec default start-stop group ISE-TACACS
aaa accounting commands 1 default start-stop group ISE-TACACS
aaa accounting commands 15 default start-stop group ISE-TACACS

Breaking this down:

  • aaa authentication login default group ISE-TACACS local — Try ISE first; fall back to local database if ISE is unreachable. If ISE rejects the user, it does NOT fall to local — fallback only triggers on connectivity failure.
  • aaa authorization exec default ... if-authenticated — Grant exec shell access to anyone ISE already authenticated. Without this, auth succeeds but the user might drop into the shell with no privilege.
  • aaa authorization commands 1 default ...` and `commands 15 default` — All user-level and privileged commands go through ISE for authorization. This is what enables per-command RBAC.
  • aaa authorization config-commands — Also authorize configuration mode commands (not just exec/privilege).
  • start-stop accounting sends a start record when a session begins and a stop record when it ends, capturing every exec session and command.

You also need a local fallback user with privilege 15 in case ISE is completely unavailable:

username localadmin privilege 15 algorithm-type scrypt secret <strong-password>

! Keep the old enable secret as last-resort
enable algorithm-type scrypt secret <strong-enable-secret>

Use algorithm-type scrypt instead of the old MD5-based secret — it’s significantly more resistant to offline cracking.

Phase 3: Apply AAA to VTY Lines and Console

line console 0
 login authentication default
 authorization exec default
 accounting exec default
 exec-timeout 10 0
 transport input none

line vty 0 15
 login authentication default
 authorization exec default
 accounting commands 1 default
 accounting commands 15 default
 accounting exec default
 exec-timeout 15 0
 transport input ssh
 access-class 10 in

A few hardening notes embedded here:

  • transport input ssh — No Telnet. Period.
  • access-class 10 in — Standard ACL limiting SSH access to your management IP range.
  • exec-timeout 15 0 — Idle sessions disconnect after 15 minutes.

For the management ACL referenced above:

ip access-list standard 10
 remark Management access
 permit 192.168.10.0 0.0.0.255
 deny   any log

Phase 4: ISE Configuration — Device Admin Policy Set

On the ISE side, you need to configure the network device (the switch/router), create a Device Admin Policy Set, and build authorization profiles that assign privilege levels. Here’s the high-level ISE workflow:

4.1 Add Network Device to ISE

Navigate to Administration → Network Resources → Network Devices → Add. Enter:

  • Name: Cat9300-Core-01
  • IP: 192.168.10.1
  • Device Type: Cisco → Catalyst 9000
  • TACACS+ Authentication Settings: shared secret (must match IOS-XE config)

4.2 Create Shell Profiles

Under Work Centers → Device Administration → Policy Elements → Results → TACACS Profiles, create two profiles:

  • Priv15-Admin: Default privilege = 15 (full access)
  • Priv1-ReadOnly: Default privilege = 1 (show commands only)

4.3 Create Command Sets (Per-Command RBAC)

Under TACACS Command Sets, create:

  • NetworkAdmin-Commands: Permit all (.*) for senior engineers
  • Helpdesk-Commands: Permit show .*, ping .*, traceroute .*; deny everything else (implicit deny at end)

4.4 Build the Device Admin Policy Set

Under Work Centers → Device Administration → Device Admin Policy Sets, create a policy set with conditions matching your network device group. Within it, create authorization policies:

Policy Name Condition Shell Profile Command Set
Network-Admins AD Group: Network-Admins Priv15-Admin NetworkAdmin-Commands
Helpdesk AD Group: IT-Helpdesk Priv1-ReadOnly Helpdesk-Commands
Default-Deny Any (catch-all) DenyAccess —

Phase 5: Verification and Troubleshooting

After applying, test authentication and check logs from both the IOS-XE side and ISE.

IOS-XE Verification Commands

! Check active AAA sessions
Switch# show aaa sessions
Total sessions since last reload: 47
Session Id: 47
  Unique Id: 1234
  User Name: sarah.chen
  IP Address: 192.168.10.100
  Idle Time: 0
  CT Call Handle: 0

! Check AAA server statistics
Switch# show aaa servers
TACACS+ Server : 192.168.10.50/49 [Current]
 Server is UP
 Requests sent: 142
 Responses received: 142
 Failures: 0

! Debug TACACS (use with caution on production)
Switch# debug tacacs authentication
Switch# debug tacacs authorization
! Watch output in terminal, then:
Switch# undebug all

ISE Live Logs

In ISE, navigate to Operations → TACACS → Live Logs. You’ll see real-time authentication and authorization events. Each entry shows:

  • Username and source IP
  • Policy set matched
  • Authorization result (Permit/Deny)
  • Shell profile applied

For accounting, go to Operations → TACACS → TACACS Accounting to see the command-by-command log. This is your audit trail.

Common Issues and Fixes

Problem: User authenticates but immediately gets permission denied on commands
Usually means command authorization is failing. Check that the ISE command set has a permit rule for the commands being run, and verify the correct command set is assigned to the user’s authorization policy. Also check aaa authorization config-commands is configured if the user needs to enter config mode.

Switch# show privilege
Current privilege level is 15

Switch# debug aaa authorization
AAA/AUTHOR (1234): Method=ISE-TACACS
AAA/AUTHOR/TAC+: Authz failure for user sarah.chen:
  Request: cmd=configure mode=1
  Status: FAIL (no matching permit)

Problem: Authentication falls to local even though ISE is up
Check VRF config. If the management VRF is configured but missing from the TACACS server group config, the switch can’t reach ISE.

Switch# show ip vrf Mgmt-vrf
  Name                             Default RD          Interfaces
  Mgmt-vrf                         <not set>           Gi0/0

! Confirm TACACS source is in the right VRF
Switch# show running-config | section aaa group
aaa group server tacacs+ ISE-TACACS
 server name ISE-PSN1
 ip vrf forwarding Mgmt-vrf       ← must be present
 ip tacacs source-interface GigabitEthernet0/0

Problem: ISE shows “5400 Authentication failed” with no detail
Usually an AD join issue on ISE. Verify under Administration → Identity Management → External Identity Sources → Active Directory → Test User. Also confirm the ISE PSN time is synced — Kerberos (used for AD) fails with >5 minute clock skew.

Bonus: EEM Applet for AAA Failsafe

If ISE goes down during maintenance and someone has accidentally removed the local fallback user, you could get locked out entirely. This EEM applet monitors for AAA failures and alerts via syslog:

event manager applet AAA-FAILURE-ALERT
 event syslog pattern "Authentication failed for user"
 action 1.0 syslog priority critical msg "CRITICAL: AAA auth failure detected - verify ISE connectivity"
 action 2.0 cli command "enable"
 action 3.0 cli command "show aaa servers"
 action 4.0 mail server "192.168.10.200" to "noc@company.com" from "switch@company.com"
       subject "AAA Authentication Failure" body "Authentication failures detected. Check ISE."

For more on EEM scripting, see our complete Cisco EEM guide.

Integrating with Cisco DNA Center / Catalyst Center

If you’re running Catalyst Center (formerly DNA Center), it can manage ISE integration and push AAA configs across your device fleet automatically. Under Design → Network Settings → AAA, you can define the TACACS server group and have it provisioned to all managed devices — eliminating manual per-device configuration entirely.

That said, Catalyst Center still relies on ISE for the actual authentication and policy enforcement. The two work together: Catalyst Center for provisioning and telemetry, ISE for identity and access control.

Production Hardening Checklist

  • ✅ TACACS+ key using strong random string (30+ characters), stored in a vault
  • ✅ At least 2 ISE PSNs in the server group for redundancy
  • ✅ Local fallback user with algorithm-type scrypt
  • ✅ aaa accounting commands 15 enabled — every privileged command logged
  • ✅ SSH-only VTY lines with management ACL
  • ✅ exec-timeout on all lines
  • ✅ ISE AD join verified and NTP synchronized
  • ✅ Separate ISE Device Admin license (TACACS+ requires Device Administration license, not just Base)
  • ✅ Test failover: shut ISE PSN interface, confirm local login still works

Final Thoughts

Centralized AAA with TACACS+ and ISE transforms device access from a liability into an auditable, policy-driven process. The configuration is more involved than a local credential setup, but the payoff is enormous: granular per-user command authorization, full accounting trails for compliance, and instant access revocation by disabling an AD account — no need to touch individual devices.

The most common pitfall is skipping the local fallback or misconfiguring the management VRF. Test your failover scenario explicitly before rolling out to production switches. Once ISE is up and TACACS+ is flowing, your IOS-XE devices become dramatically easier to audit and more resistant to unauthorized access — which is exactly what a hardened network management plane should look like.

AAA is one layer of a complete security posture. Pair it with Python-based network automation to audit your AAA configurations across your fleet and alert on drift — no more devices that somehow missed the TACACS rollout. And if you want to go deeper on OSPF troubleshooting to keep the management path to ISE itself stable, our OSPF troubleshooting guide covers the adjacency failures that most commonly break reachability in the management plane.

Enjoying this post?

Get more guides like this delivered straight to your inbox. No spam, just tech and trails.