Why Device-Level AAA Is Non-Negotiable in 2026
If you’re still using a shared enable password across fifty Cisco switches, you’re one disgruntled contractor away from a very bad week. Device-level AAA—Authentication, Authorization, and Accounting—is the foundation of network access control, and on Cisco IOS-XE it’s more capable than most engineers give it credit for. This guide walks through configuring TACACS+ with Cisco ISE as the policy server, building in local fallback, and verifying everything works before you lock yourself out.
Whether you’re running Catalyst 9000 series in a campus environment or ASR 1000 routers at WAN edges, the configuration patterns are the same. We’ll use real IOS-XE syntax throughout—17.x syntax, validated against a Catalyst 9300—with actual show command output you can compare against your own gear. No hand-wavy abstractions.
The payoff isn’t just compliance. Per-command authorization means your NOC team can run show commands without accidentally issuing a write erase. Full accounting means that during a 2 AM outage, you can reconstruct exactly which engineer made the config change that broke things. TACACS+ makes both of these possible in ways that shared passwords simply can’t.
AAA Fundamentals: What Each Letter Actually Does
The three components of AAA serve distinct functions, and conflating them leads to misconfigured policies:
- Authentication: Answers “who are you?” — verifies identity via username/password, certificates, or tokens.
- Authorization: Answers “what can you do?” — controls which commands or privilege levels are available after authentication.
- Accounting: Answers “what did you do?” — logs commands, session start/stop times, and exec activity for audit trails.
In IOS-XE, all three are enabled under the aaa new-model umbrella. Without that global command, none of the AAA configuration takes effect—a common gotcha during initial setup. The moment you enter aaa new-model, the default login method immediately becomes AAA-controlled, which is why you must have a working local fallback configured first.
TACACS+ vs RADIUS for Device Administration
Both protocols can handle AAA, but TACACS+ is the right choice for network device administration. Here’s why the distinction matters:
- Per-command authorization: TACACS+ separates authentication, authorization, and accounting into distinct transactions. This lets ISE authorize individual CLI commands, not just privilege levels. RADIUS lumps everything into one response.
- Full packet encryption: TACACS+ encrypts the entire payload, including the username. RADIUS only encrypts the password field, leaving usernames and attributes in the clear.
- TCP vs UDP: TACACS+ uses TCP port 49 (reliable, connection-oriented delivery); RADIUS uses UDP 1812/1813. TCP matters in lossy management networks where UDP retransmits can cause authentication delays.
- Granular authorization control: TACACS+ command authorization is enforced on a per-command basis with regex matching. RADIUS authorization is coarse—privilege levels or VLAN assignments, nothing command-specific.
RADIUS makes sense for 802.1X endpoint authentication—but for SSH sessions to your Catalyst 9K management plane, TACACS+ wins. This also pairs well with the control plane policing you should already have in place to protect against management-plane abuse. CoPP rate-limits what hits the CPU; TACACS+ controls who can do anything once they’re in.
Lab Topology
For this guide, we’re working with:
- IOS-XE device: Cisco Catalyst 9300 (17.9.4a)
- Policy server: Cisco ISE 3.3 (patch 1), with Device Administration licensed
- Management network: 192.168.100.0/24, isolated in a MGMT VRF
- ISE PAN/PSN: 192.168.100.10 (combined deployment)
- Switch management IP: 192.168.100.50 (GigabitEthernet0/0 in MGMT VRF)
One important note on ISE licensing: Device Administration requires the Device Administration license (formerly Plus tier). Basic ISE licenses only cover 802.1X endpoint authentication. Confirm your ISE license before starting — Work Centers > Device Administration > Overview will either show the feature or an “unlicensed” warning.
Before You Start: Secure Your Local Fallback
The biggest risk with TACACS+ misconfiguration is locking yourself out. Before entering aaa new-model, verify a local admin account exists with privilege 15 and a strong password:
! Ensure local fallback account exists BEFORE enabling AAA
username localadmin privilege 15 algorithm-type scrypt secret MySuperSecretPass123!
!
! Enable password encryption for all type-7 passwords in config
service password-encryption
Use algorithm-type scrypt (type 9 hash) on IOS-XE 16.9 or later. If you’re on an older train, use algorithm-type sha256 (type 8). Avoid the legacy secret 5 (MD5) — it’s been crackable for years and will show up on your next vulnerability assessment.
Also verify out-of-band access. If you have a console server or OOBM network, test it before enabling AAA. Physical console access is your last resort if something goes wrong with the VTY configuration.
Step 1: Enable AAA and Define the TACACS+ Server
Start with aaa new-model—this immediately activates AAA on all lines, so have your local fallback ready before proceeding.
! Enable AAA globally
aaa new-model
! Define the TACACS+ server pointing to ISE
tacacs server ISE-PRIMARY
address ipv4 192.168.100.10
key 7 <encrypted-key>
timeout 5
single-connection
!
! Optional secondary ISE node for redundancy
tacacs server ISE-SECONDARY
address ipv4 192.168.100.11
key 7 <encrypted-key>
timeout 5
single-connection
!
! Server group — ordered preference
aaa group server tacacs+ ISE-TACACS
server name ISE-PRIMARY
server name ISE-SECONDARY
ip vrf forwarding MGMT
ip tacacs source-interface GigabitEthernet0/0
!
Key points about this configuration:
single-connectionkeeps a persistent TCP session to ISE instead of opening/closing per request. This reduces authentication latency significantly in high-volume environments and avoids TCP SYN storms during busy periods.- If your management interface is in a VRF (recommended practice), specify it with
ip vrf forwarding. Without this, TACACS+ packets route over the global table, bypassing your management network segmentation entirely. - The
timeout 5means the device waits 5 seconds per server before moving to the next. With two servers and a 5-second timeout, a worst-case scenario takes 10 seconds before local fallback kicks in. Tune this based on your ISE response times — if ISE responds in under 200ms normally, 5 seconds is a generous but safe window.
Step 2: Configure Authentication Policies
Define named method lists for login and enable authentication. The order of methods defines the fallback chain:
! Default login — try ISE first, local as fallback
aaa authentication login default group ISE-TACACS local
!
! Console-only local auth (never tie console to a remote auth server)
aaa authentication login CONSOLE local
!
! Enable authentication via TACACS+, fallback to local enable secret
aaa authentication enable default group ISE-TACACS enable
!
Apply the CONSOLE method list explicitly to line con 0. This is critical — without it, console inherits the default method list, which tries ISE first. If ISE is down during a recovery scenario, you’ll wait 10 seconds per authentication attempt, compounding your outage time:
line con 0
login authentication CONSOLE
exec-timeout 10 0
!
line vty 0 15
login authentication default
transport input ssh
exec-timeout 15 0
!
This design means SSH sessions always hit ISE first, while the physical console always uses local credentials. If your company mandates SSH key-based authentication, replace the password authentication with ip ssh pubkey-chain entries — TACACS+ authentication can still handle the authorization and accounting layers even with SSH key auth.
Step 3: Per-Command Authorization
This is where TACACS+ shines beyond what any shared password scheme can offer. Command authorization lets ISE control which commands each user can run, verified per-command in real time:
! Authorize exec shell — check TACACS+, fallback to local privilege if ISE unreachable
aaa authorization exec default group ISE-TACACS local if-authenticated
!
! Per-command authorization for privilege 15 (admin commands)
aaa authorization commands 15 default group ISE-TACACS local if-authenticated
!
! Per-command authorization for privilege 1 (show commands, ping, traceroute)
aaa authorization commands 1 default group ISE-TACACS local if-authenticated
!
! Ensure console bypasses authorization (prevents out-of-band lockout)
aaa authorization console
!
The if-authenticated keyword is the key to safe local fallback. When ISE is unreachable and a user authenticates locally, if-authenticated tells IOS-XE to skip TACACS+ authorization entirely and grant the user their local privilege level. Without this keyword, a locally-authenticated user hits a TACACS+ authorization request that times out, resulting in a denied exec shell — you’re locked out even though authentication succeeded.
A word on authorization for all privilege levels: some engineers only configure command authorization for privilege 15. Don’t. A privilege-1 user can still run show running-config all, which exposes your entire config including encrypted passwords. Authorize privilege 1 commands explicitly with a command set that permits only what NOC users need.
Step 4: Accounting Configuration
Accounting is often skipped or half-configured. Don’t skip it — this is what feeds your SIEM and satisfies your security auditors:
! Log exec session start/stop with full session details
aaa accounting exec default start-stop group ISE-TACACS
!
! Log every command at privilege 15
aaa accounting commands 15 default start-stop group ISE-TACACS
!
! Log every command at privilege 1
aaa accounting commands 1 default start-stop group ISE-TACACS
!
! System-level events: reloads, AAA failures, config register changes
aaa accounting system default start-stop group ISE-TACACS
!
! Keep session accounting records fresh every 48 hours
aaa accounting update newinfo periodic 2880
!
The start-stop keyword sends an accounting record when a session or command starts AND when it stops. This captures both the intent and the completion. stop-only is lighter on ISE but loses start timestamps — if a device reloads mid-session, you lose the record entirely. For compliance environments, always use start-stop.
ISE’s accounting logs also matter for network security posture reporting. Most SIEM integrations pull directly from ISE’s syslog or API — what you configure here determines what your SOC can query during an incident.
Step 5: ISE Configuration — Device Admin Policy Sets
On the ISE side, navigate to Work Centers > Device Administration > Policy Sets. Before touching policy sets, you need to add your device and configure the building blocks.
Add the Network Device
Go to Administration > Network Resources > Network Devices > Add:
- Name:
CAT9300-CORE01 - IP Address:
192.168.100.50/32 - TACACS Authentication Settings: check “TACACS+”, enter your shared secret
- Device Type:
Cisco > Catalyst 9000(create the hierarchy under Network Device Groups if it doesn’t exist)
Build Command Sets
Before creating policy sets, define your command sets under Work Centers > Device Administration > Policy Elements > Results > TACACS Command Sets:
PermitAllCommands: Add one rule: Match .* (regex), Action: Permit. This is your full-admin set.
ShowCommandsOnly: Add rules:
- Match
show, Arguments.*, Action: Permit - Match
ping, Arguments.*, Action: Permit - Match
traceroute, Arguments.*, Action: Permit - Default: Deny (checked at bottom of the command set)
Create Shell Profiles
Under Work Centers > Device Administration > Policy Elements > Results > TACACS Profiles:
- Priv-15: Default Privilege = 15, Maximum Privilege = 15
- Priv-1: Default Privilege = 1, Maximum Privilege = 1
Authorization Policy
In your Device Admin policy set, create authorization rules matching AD group membership:
| Rule Name | Condition | Command Sets | Shell Profile |
|---|---|---|---|
| Network Admins | AD:ExternalGroups EQUALS corp.local/Network-Admins | PermitAllCommands | Priv-15 |
| NOC Read-Only | AD:ExternalGroups EQUALS corp.local/NOC-ReadOnly | ShowCommandsOnly | Priv-1 |
| Deny All | Default | DenyAllCommands | Priv-0 |
The AD group condition uses the full distinguished name format. If your condition isn’t matching, open Operations > TACACS > Live Logs and click a failed auth event — ISE shows which groups it retrieved from AD for that user, so you can verify the group name exactly.
Step 6: Verify Connectivity and Authentication
Before cutting over, test TACACS+ reachability from the device without committing to a production change:
CAT9300# test aaa group ISE-TACACS jsmith P@ssw0rd! legacy
Attempting authentication test to server-group ISE-TACACS using tacacs+
User was successfully authenticated.
The legacy keyword suppresses the new-style interactive prompt and sends credentials inline — useful for scripted verification. If you get User was NOT successfully authenticated, troubleshoot in this order:
- Confirm IP reachability:
ping vrf MGMT 192.168.100.10 repeat 5 - Check shared secret mismatch (most common cause): ISE Live Logs shows
Authentication failed: Invalid shared secret— the key on the device must match the key in the ISE Network Device entry exactly, including case - Verify Device Administration service is enabled on ISE PSN: Administration > System > Deployment > [PSN node] > Policy Services > Enable Device Admin Service
- Confirm TCP/49 is not blocked:
telnet 192.168.100.10 49from the switch should open a connection (even if it immediately disconnects)
Step 7: Verify Authorization and Accounting
! Show active AAA sessions and connected users
CAT9300# show aaa sessions
Total sessions since last reload: 47
Session Id : 31
Unique Id : 47
User Name : jsmith
IP Address : 192.168.100.25
Idle Time : 0
CT Call Handle : 0
! Check TACACS+ server health and packet counters
CAT9300# show tacacs
Tacacs+ Server : 192.168.100.10/49
Socket opens: 23
Socket closes: 23
Total packets sent: 89
Total packets recv: 88
Reference count: 0
Use count: 0
Server is up
Single connection: Yes
Watch the packet counters. If Total packets sent is incrementing but Total packets recv is not, TACACS+ requests are going out but responses aren’t coming back — usually a firewall or ACL issue between the management network and ISE.
! Debug TACACS+ (use in a change window — output is verbose)
CAT9300# debug tacacs authentication
CAT9300# debug tacacs authorization
*Sep 28 14:23:11.441: TPLUS: Queuing AAA Authentication request 12 for processing
*Sep 28 14:23:11.441: TPLUS: Authentication start packet created for 12(jsmith)
*Sep 28 14:23:11.442: TPLUS: Using server 192.168.100.10
*Sep 28 14:23:11.444: TPLUS(00000012): Connected to server 192.168.100.10 (port 49)
*Sep 28 14:23:11.447: TPLUS(00000012): received authen response status GET_USER
*Sep 28 14:23:11.631: TPLUS(00000012): received authen response status PASS
CAT9300# undebug all
A clean PASS response means the full authentication exchange completed. The timestamp delta between the first and last debug line is your actual TACACS+ latency — anything under 500ms is acceptable; over 1 second suggests network or ISE performance issues worth investigating. For accounting validation, check Operations > TACACS > Live Logs in ISE — auth and accounting records should appear in real time.
Troubleshooting Common Issues
Issue: Authorization Rejected After Successful Authentication
ISE Live Logs will show Command Authorization Failed. Work through this checklist:
- Verify the user’s AD group in ISE Live Logs — click the event to see which groups ISE retrieved; the condition in your policy set might be using the wrong group DN format
- Check the command set — open it in ISE and use the Command Set simulator to test whether a specific command matches your permit rules
- Verify shell profile privilege level — if set to 1, the user lands in user EXEC mode and won’t get enable mode automatically; they must
enableand re-authenticate - Check authorization ordering in the policy set — if “Deny All” rule matches before your group-specific rules, reorder them (more specific conditions should appear higher)
Issue: Fallback to Local Not Working
! Verify local user exists with correct privilege
CAT9300# show running-config | include username
username localadmin privilege 15 secret 9 $9$3IUJHp...
If the local user exists but fallback still fails, check that aaa authentication login default group ISE-TACACS local includes local at the end. If ISE timeouts cause the authentication to take longer than your terminal emulator’s connect timeout, the session may drop before local auth kicks in — reduce the TACACS+ server timeout to 3 seconds if needed.
Issue: Accounting Records Missing from ISE
! Check if accounting events are being generated locally
CAT9300# show aaa accounting
! Verify TACACS+ accounting packets are being sent
CAT9300# show tacacs statistics
If no accounting events show in ISE but authentication works, verify aaa accounting exec default start-stop group ISE-TACACS is present — it’s easy to configure command accounting but forget exec accounting. Also check that your ISE PSN has enough disk space; a full disk causes ISE to drop accounting records silently.
Hardening Recommendations
Once AAA is working, layer in these additional controls to close the remaining attack surface on the management plane:
! Restrict VTY access to management subnet only
ip access-list standard MGMT-ACCESS
permit 192.168.100.0 0.0.0.255
deny any log
line vty 0 15
access-class MGMT-ACCESS in
! Enforce SSH version 2 and remove weak ciphers
ip ssh version 2
ip ssh authentication-retries 3
ip ssh time-out 60
ip ssh server algorithm encryption aes256-ctr aes192-ctr aes128-ctr
ip ssh server algorithm mac hmac-sha2-256 hmac-sha2-512
ip ssh server algorithm kex ecdh-sha2-nistp256 diffie-hellman-group14-sha1
! Disable services that expand attack surface
no service finger
no service udp-small-servers
no service tcp-small-servers
no ip http server
no ip http secure-server
! Disable CDP/LLDP globally, then re-enable only on internal trunk interfaces
no cdp run
no lldp run
The SSH cipher hardening removes legacy CBC-mode ciphers and MD5/SHA1-based MACs that trigger findings on Nessus and Qualys scans. The KEX (key exchange) line removes Diffie-Hellman groups below 2048-bit. Disabling CDP/LLDP globally stops device fingerprinting on all interfaces; re-enable per-interface with cdp enable and lldp transmit / lldp receive on internal trunk ports where you need phone discovery. For a complete management plane hardening checklist, the IOS-XE platform reference covers feature availability by software train.
Automating Device Onboarding with Python
Once your TACACS+ template is solid, pushing it to dozens of devices manually is error-prone and slow. A Netmiko-based script can push the AAA config block consistently across your entire fleet, catching devices that have drifted from the standard config:
from netmiko import ConnectHandler
from jinja2 import Environment, FileSystemLoader
AAA_TEMPLATE = """
aaa new-model
tacacs server ISE-PRIMARY
address ipv4 {{ ise_primary }}
key 7 {{ encrypted_key }}
timeout 5
single-connection
aaa group server tacacs+ ISE-TACACS
server name ISE-PRIMARY
ip vrf forwarding {{ mgmt_vrf }}
ip tacacs source-interface {{ mgmt_interface }}
aaa authentication login default group ISE-TACACS local
aaa authentication login CONSOLE local
aaa authorization exec default group ISE-TACACS local if-authenticated
aaa authorization commands 15 default group ISE-TACACS local if-authenticated
"""
device = {
"device_type": "cisco_ios",
"host": "192.168.100.50",
"username": "localadmin",
"password": "...",
"secret": "...",
}
config_params = {
"ise_primary": "192.168.100.10",
"encrypted_key": "...",
"mgmt_vrf": "MGMT",
"mgmt_interface": "GigabitEthernet0/0"
}
The network automation guide with Netmiko and NAPALM covers the full framework setup, including how to handle devices that are offline during the push and how to validate configurations were applied correctly using NAPALM’s config diff capabilities.
Summary
A properly configured TACACS+ AAA setup on IOS-XE gives you four things that shared passwords can’t:
- Per-user authentication — individual accountability for every login, fully auditable
- Per-command authorization — NOC can’t accidentally
write erasea core switch; admins get full access scoped by AD group - Full accounting — every command logged with username, timestamp, source IP, and session context
- Safe local fallback — ISE maintenance windows and outages don’t lock you out of physical hardware
The investment in ISE Device Administration licensing pays for itself the first time you need to audit who made a config change during an outage — or the first time you need to prove to a compliance team that only authorized personnel accessed a production router. With accounting logs flowing into your SIEM, you get incident response traceability that’s actually useful, not a box-ticking exercise three auditors can quietly ignore.
Leave a Reply