First, the essential ideas
- AAA
- Authentication checks identity, authorization decides permitted actions or services, and accounting records activity. A successful identity check does not establish permission or prove that an activity record was received.
- AAA client and server
- For this device-administration exercise, R1 is the AAA client and ISE1 is the policy server. Admin1 is the SSH client to R1, not the device sending R1's AAA requests.
- Local database
- The local database stores accounts on R1 itself. It can provide a carefully controlled recovery method but creates per-device credential-management work and does not automatically centralize audit records.
- TACACS+
- Terminal Access Controller Access-Control System Plus separates AAA exchanges and supports granular device-command authorization. Classic TACACS+ uses TCP 49; its legacy body obfuscation is not a substitute for a protected transport.
- RADIUS
- Remote Authentication Dial-In User Service carries authentication and authorization attributes, with accounting as a related function. This lab uses classic UDP 1812 for access and UDP 1813 for accounting, not TLS-protected RADIUS.
- Method list and group
- A method list is an ordered policy such as server group followed by local. A server group names the selected servers. Defining either does not apply it to a line until the matching line command is used.
- Reject versus error
- A reject is an authoritative negative response. An error or unreachable service can permit trying the next method. Local fallback does not normally override a reachable server's rejection.
- Shared secret
- A shared secret is configured on the AAA client and server for their protocol relationship. It is not the user's login password. Protect it and match it to the exact client source address.
- EXEC authorization and accounting
- EXEC authorization decides whether a shell starts and which attributes it receives. EXEC accounting records session start/stop; it is not a record of every command.
- Console and recovery account
- Open the named GNS3 Console before commands. R1's local-only Console and breakglass account provide authorized recovery; the server-only netop account proves central authentication when it works.
One policy appliance supplies two separate AAA protocols. The netop account exists only on ISE1; breakglass exists only on R1. Their different locations make the tests interpretable. No server, license, user authentication or accounting outcome was executed or measured during authoring.
See the idea
SSH client and AAA client are different roles
Admin1 asks R1 for a shell; R1 asks ISE1 for policy. A server reject is not the same as no answer.
Request the shell
Admin1 opens SSH to R1. SSH protects this connection; it does not automatically protect the separate router-to-server AAA exchange.
What this model leaves out: Logical protocol flow over the shared Switch1 segment. ISE1 supplies both separate services. Classic AAA is isolated; no TLS, external identity store or MFA is shown.
Full visual explanation and references
Admin1 opens SSH to R1, which separately queries ISE1 by TACACS+ or RADIUS. ISE1 returns a decision to R1. All physical traffic crosses Switch1.
Logical protocol flow over the shared Switch1 segment. ISE1 supplies both separate services. Classic AAA is isolated; no TLS, external identity store or MFA is shown.
- Request the shell
Admin1 opens SSH to R1. SSH protects this connection; it does not automatically protect the separate router-to-server AAA exchange.
sec.cloudapps.cisco.com - Ask the policy server
R1 sends from .1 to ISE1 using the selected TACACS+ or RADIUS service. The server matches the device, secret, user and policy.
www.cisco.comwww.cisco.com - Interpret the decision
ISE1's reject ends the login attempt. With no usable server answer, the configured local method may run; authorization and accounting still need checks.
www.cisco.comwww.cisco.comsec.cloudapps.cisco.com
One idea at a time
Start with something familiar.
Follow one login: Admin1 asks R1 for SSH access; R1 asks ISE1 about the user; R1 then decides whether to start the shell under the returned policy. The SSH session and the AAA exchange are different connections.
Why learn this?
A working server address is not enough. The server must recognize the router's source, share the right protocol secret and return an appropriate policy. A password accepted centrally can still be followed by an authorization denial or missing accounting.
An everyday comparison
A receptionist checks a visitor with a central office, receives permission for a particular room and records when the visit starts and ends.
What happens in a network
R1 requests authentication, receives authorization attributes and sends accounting records. These are related but distinct tasks with different evidence.
Where the comparison stopsA network protocol has timeouts, source addresses and cryptographic limitations that the analogy does not model. A recorded visit also does not imply that every action inside was permitted or logged.
Follow one worked example
- Prove local recovery first.
The learner verifies breakglass on a local-only VTY baseline while R1's Console uses a named local authentication list.
Why: Central policy testing should not remove the independent authorized way to recover.
- Verify the server contract.
ISE1 recognizes R1 at 192.0.2.1, has both services enabled, accepts netop and rejects the server-unknown breakglass identity.
Why: Without a real policy fixture, a client command cannot prove success, rejection or authorization behavior.
- Compare both central protocols.
The learner applies TACACS+ first and RADIUS second, checking a server-only login, privilege 1 and actual start/stop records.
Why: Each protocol is configured and verified separately rather than assuming one working service validates the other.
- Separate rejection from outage.
A reachable ISE1 rejects breakglass. During a deliberate ISE1 link suspension, RADIUS can time out and local fallback can accept that same local account.
Why: The changed variable is server availability, not a new password or an override of an explicit deny.
Your first small task
Trace ssh netop@192.0.2.1. Name the source of R1's AAA request, its destination and the account store that must contain netop.
Show a hint
The endpoint accepting the SSH connection is also the client of the central policy service.
Check the expected result
R1 sends from 192.0.2.1 to ISE1 at 192.0.2.20. The account exists in ISE1's internal user store, not on Admin1 or R1.
Pause and explain it in your own words
The method list ends in local. Must a valid local breakglass account work while ISE1 is reachable and rejects it?
Show a hint
Distinguish a definitive negative answer from the absence of an answer.
Show the explanation
No. A reject normally ends authentication. Local fallback is for an earlier method error or unavailability, so the separate local-only Console remains important.
Short answer
What should you understand today?
AAA separates identity, permission and activity records. For router administration, the router is the TACACS+ or RADIUS client even when a workstation starts the SSH session. An ordered method list can fall back to local credentials when a server cannot answer, but not simply because that server rejects a user. Keep a local Console path and verify server-side policy and accounting evidence separately.
Before you begin
Learning targets
- Review SSH identity and local privilege from Days 45 and 47; do not import an existing production AAA configuration.
- Use GNS3 2.2.55, an entitled autonomous C8000v IOS XE 17.12.1a, Ubuntu 24.04 Desktop and an instructor-prepared Cisco ISE 3.3 Patch 4 appliance.
- ISE provisioning, compute resources and valid Device Administration plus appropriate RADIUS entitlements are mandatory prerequisites, not included or assumed free.
- Distinguish authentication, authorization and accounting evidence.
- Identify the workstation SSH client, router AAA client and policy server.
- Configure local users and named TACACS+ and RADIUS client groups.
- Apply named login, EXEC authorization and accounting policies to a bounded VTY range.
- Compare central rejection with unreachable-server fallback and restore the normal method.
Words you will meet
Open a word when you need its meaning. You do not need to memorize the whole list before reading.
AAA
Authentication checks identity, authorization decides permitted actions or services, and accounting records activity. A successful identity check does not establish permission or prove that an activity record was received.
AAA client and server
For this device-administration exercise, R1 is the AAA client and ISE1 is the policy server. Admin1 is the SSH client to R1, not the device sending R1's AAA requests.
Local database
The local database stores accounts on R1 itself. It can provide a carefully controlled recovery method but creates per-device credential-management work and does not automatically centralize audit records.
TACACS+
Terminal Access Controller Access-Control System Plus separates AAA exchanges and supports granular device-command authorization. Classic TACACS+ uses TCP 49; its legacy body obfuscation is not a substitute for a protected transport.
RADIUS
Remote Authentication Dial-In User Service carries authentication and authorization attributes, with accounting as a related function. This lab uses classic UDP 1812 for access and UDP 1813 for accounting, not TLS-protected RADIUS.
Method list and group
A method list is an ordered policy such as server group followed by local. A server group names the selected servers. Defining either does not apply it to a line until the matching line command is used.
Reject versus error
A reject is an authoritative negative response. An error or unreachable service can permit trying the next method. Local fallback does not normally override a reachable server's rejection.
Shared secret
A shared secret is configured on the AAA client and server for their protocol relationship. It is not the user's login password. Protect it and match it to the exact client source address.
EXEC authorization and accounting
EXEC authorization decides whether a shell starts and which attributes it receives. EXEC accounting records session start/stop; it is not a record of every command.
Console and recovery account
Open the named GNS3 Console before commands. R1's local-only Console and breakglass account provide authorized recovery; the server-only netop account proves central authentication when it works.
Three decisions need three kinds of evidence
Authentication answers who the claimant is. Authorization determines what service or permission is granted. Accounting records activity. These can succeed or fail independently. A user authenticated by ISE1 can still be denied an EXEC shell; a shell can start while accounting delivery is unavailable. Do not use a login prompt or green authentication result as proof of all three.
- Check identity, effective privilege and received accounting separately.
- Session accounting is not a complete command transcript.
The router is the AAA client
Admin1 speaks SSH to R1. R1 separately contacts ISE1 using its configured source interface. ISE1 must recognize that source as a network device and use the matching shared secret. The central user's password and the client/server shared secret have different purposes. A correct user password cannot repair a mismatched shared secret or wrong client address.
- Match the server's network-device definition to R1's actual source.
- Do not confuse the SSH workstation with the router's AAA role.
TACACS+ and RADIUS are not the same permission model
TACACS+ separates authentication, authorization and accounting exchanges and is commonly used for detailed device-administration policy. RADIUS access responses can carry authorization attributes such as a privilege level, while its accounting service records sessions. This does not make RADIUS a drop-in replacement for TACACS+ per-command authorization. Either needs supported client and server policy.
- Compare actual services and attributes, not slogans about which protocol encrypts everything.
- Use the disconnected lab only with disposable credentials and no external bridge.
Named method lists avoid accidental scope changes
A method list specifies an order; a group selects servers; a line applies the list. The local-only Console is deliberately independent of the VTY method. Authentication and EXEC authorization each need their own fallback policy. A reachable server's reject is final for that method list; moving to local after no answer is a different case.
- Keep a tested local-only Console instead of depending solely on remote fallback.
- Do not use none or if-authenticated as a shortcut to conceal policy failures.
Prepare the server before testing the clients
This chapter configures network-device clients, not an ISE installation. An instructor must supply the exact ready server contract in the lab setup. On ISE, use Administration > Network Resources > Network Devices for R1's address and protocol secrets; internal users provide netop. Enable Device Admin on the policy-service node and create matching device-administration and network-access policies.
- A preconfigured policy server is a declared prerequisite, not a fabricated lab result.
- Do not weaken an existing production server's security policy to fit this fixture.
Read the server evidence and preserve secrets
For TACACS+, inspect Operations > TACACS > Live Logs and the Device Administration accounting reports. For RADIUS, inspect the RADIUS live-log details and accounting reports for the matching user, network device and session. An access result is not an accounting result. Record sanitized timestamps, result, source and session identifier; do not publish shared keys, passwords or packet payloads.
- Use actual received records rather than expected sample output.
- A central audit outage remains a limitation even when local recovery works.
Limit the coverage claim to the procedure actually offered
v1.1 5.3 covers the local-user configuration and 5.8 the AAA comparison. v2.0 4.1 is addressed by local users and both TACACS+ and RADIUS clients, conditional on the explicit test-server fixture. The RADIUS outage is tested procedurally; TACACS+ outage behavior is explained but not separately exercised. No author-side runtime is claimed.
- Distinguish a complete client procedure from a measured working deployment.
- Do not claim server installation, MFA or per-command policy coverage here.
Real-world walkthrough
The emergency account works only during a real outage
A fictional operator expects a router-local recovery account to bypass a central denial because local appears last in the method list. A reachable policy server rejects the account, so the login fails. The retained local-only Console provides recovery while the operator investigates the actual result.
- Identify the account's store and the exact applied login method before changing credentials.
- Confirm a server-only netop session succeeds and receives the intended privilege through each protocol.
- Attempt the local-only breakglass identity while the server is reachable and confirm a real reject, not a timeout.
- Suspend only the lab ISE1 link, test RADIUS fallback and retain the actual delay and outcome.
- Resume the same link, retest central identity and rejection, then return VTYs to the known local baseline before cleanup.
Guided GNS3 lab
Local recovery plus two named AAA clients
Configure both client protocols against an explicit instructor-provisioned server, compare accept/reject evidence and recover one RADIUS reachability fault. No real server or runtime result was exercised during authoring.
Addressing plan
| Device | Interface | Address | Purpose |
|---|---|---|---|
| R1 | GigabitEthernet1 | 192.0.2.1/24 | SSH destination and explicit AAA client source. |
| Admin1 | ens3 | 192.0.2.10/24 | SSH client and authorized private ISE GUI reader. |
| ISE1 | GigabitEthernet0 | 192.0.2.20/24 | TACACS+ TCP 49; RADIUS UDP 1812/1813; private HTTPS GUI. |
Set up the lab
- Build only the three declared links; no Cloud, NAT or Internet bridge. Use a clean R1 and keep its Console active. Gate the executable profile on VTY 0-15 only: use 0-4 and disable 5-15; stop for instructor adaptation if show line reveals a different usable range.
- ISE1 must already be installed, running and licensed for Device Administration and the required RADIUS sessions, with enough vendor-specified compute. Its single-node services, private GUI trust and internal user store must work offline. Installation, DNS/NTP provisioning and entitlement acquisition occur before this isolated exercise; no external dependency may be required for these internal-user tests.
- Server contract: define R1 as network device 192.0.2.1/32. Enable TACACS+ TCP 49 and RADIUS UDP 1812/1813 with distinct private TAC_KEY and RAD_KEY values. Match those values on R1. Existing server protections must not be disabled; if the old client cannot satisfy them, stop and use the paper alternative.
- Create only the central internal user netop with a private unique secret. TACACS+ authentication accepts netop and its shell profile returns default privilege 1. RADIUS accepts netop with Service-Type NAS-Prompt-User and Cisco AV-pair shell:priv-lvl=1. Other identities, including breakglass, receive explicit rejection. No external directory or MFA is involved.
- Enable server collection of EXEC session accounting and provide authorized access to TACACS/RADIUS live logs and accounting reports. Verify the GUI's certificate through the instructor's trusted fingerprint or CA process; never dismiss an unexplained warning.
- Choose private randomly generated alphanumeric BREAKGLASS_SECRET, TAC_KEY and RAD_KEY values of at least 16 characters. netop's secret is separate. Replace placeholders before typing; no secrets belong in screenshots, chat, command-line test-password arguments or published configurations.
- The SSH host key is new only on this fresh isolated router. Document first-use trust after checking wiring and identity, or use the instructor's verified fingerprint. Stop on an unexpected key change. Classic AAA protocols here are a disconnected learning fixture, not a production recommendation.
- Without entitled ISE1, complete R1's local baseline and draw the two central flows on paper. Client definitions may be inspected, but do not attach central methods or claim accept/reject/accounting tests. Mark central configuration verification and outage behavior unmeasured.
Gate on the prepared server contract
Before central testing, have the instructor show ISE1's enabled services, R1 /32 definition, netop policy, privilege result, explicit reject rule and accounting views through its trusted private GUI. Do not infer these from an IP address or successful ping. If any prerequisite is missing, select the local/paper alternative.
- What you should see
- The server-dependent path is available only after the instructor confirms the complete fixture; no success is invented.
- Why this step matters
- Server provisioning is outside this CCNA client exercise but its exact required behavior cannot be left implicit.
Prepare R1 and inventory lines
In GNS3, right-click R1 and choose Console before typing. Start at > or # on the fresh autonomous router. Check the VTY inventory gate before proceeding. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
enable
show line
configure terminal
hostname R1
interface GigabitEthernet1
ip address 192.0.2.1 255.255.255.0
no shutdown
endWhat each command means
enable- Enter privileged EXEC (#) from user EXEC (>); use only your authorized lab credentials.
show line- Confirm the declared usable VTY range and the independent Console.
configure terminal- Enter global configuration mode from privileged EXEC (#); accepted changes affect the running device.
hostname R1- Set the lab router identity.
interface GigabitEthernet1- Select the only interface to Switch1 Ethernet0.
ip address 192.0.2.1 255.255.255.0- Assign both the management address and the explicit AAA source.
no shutdown- Enable the isolated cable.
end- Return to privileged EXEC (#). This neither saves the configuration nor reverses accepted changes.
- What you should see
- R1 should own .1 and the line inventory must match the setup profile.
- Why this step matters
- The server recognizes the client's source address, so this address is part of the AAA contract.
Prepare Admin1
In GNS3, right-click Admin1 and choose Console before typing. At its Linux shell, configure the private interface only. Use the desktop browser later for the trusted ISE GUI. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
sudo ip address add 192.0.2.10/24 dev ens3
sudo ip link set ens3 up
ping -c 3 192.0.2.1
ping -c 3 192.0.2.20What each command means
sudo ip address add 192.0.2.10/24 dev ens3- Assign the workstation's private address; it is not R1's AAA source.
sudo ip link set ens3 up- Enable the cable to Switch1 Ethernet1.
ping -c 3 192.0.2.1- Check the router path before testing credentials.
ping -c 3 192.0.2.20- Check the appliance path without claiming its AAA services are healthy.
- What you should see
- Both paths should be reachable; service and policy checks remain separate.
- Why this step matters
- A ping result cannot prove that a server recognizes R1 or accepts a user.
Create local recovery and SSH
In GNS3, right-click R1 and choose Console before typing. Start at #. Replace BREAKGLASS_SECRET privately, and retain this Console throughout. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
configure terminal
username breakglass privilege 15 algorithm-type scrypt secret BREAKGLASS_SECRET
ip domain name lab.test
crypto key generate rsa modulus 3072
ip ssh version 2
aaa new-model
aaa authentication login CONSOLE_LOCAL local
line console 0
login authentication CONSOLE_LOCAL
endWhat each command means
configure terminal- Enter global configuration mode from privileged EXEC (#); accepted changes affect the running device.
username breakglass privilege 15 algorithm-type scrypt secret BREAKGLASS_SECRET- Create the disposable local recovery identity with protected secret storage.
ip domain name lab.test- Set the domain used with the hostname for default key naming.
crypto key generate rsa modulus 3072- Generate a fresh SSH host key without replacing an existing identity.
ip ssh version 2- Require SSH version 2 for remote administration.
aaa new-model- Enable AAA processing on this clean lab router.
aaa authentication login CONSOLE_LOCAL local- Define a local-only authentication policy for Console recovery.
line console 0- Select the independent Console.
login authentication CONSOLE_LOCAL- Apply only the local method to future Console logins.
end- Return to privileged EXEC (#). This neither saves the configuration nor reverses accepted changes.
- What you should see
- The local recovery identity and named Console authentication should be configured.
- Why this step matters
- Central method changes later do not replace the Console's deliberate local-only path.
Establish the local VTY baseline
In GNS3, right-click R1 and choose Console before typing. Start at #. This is the known baseline used again during rollback. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
configure terminal
aaa authentication login LOCAL_LOGIN local
aaa authorization exec LOCAL_EXEC local
line vty 0 4
login authentication LOCAL_LOGIN
authorization exec LOCAL_EXEC
transport input ssh
exec-timeout 5 0
line vty 5 15
transport input none
endWhat each command means
configure terminal- Enter global configuration mode from privileged EXEC (#); accepted changes affect the running device.
aaa authentication login LOCAL_LOGIN local- Define local authentication for the initial remote test.
aaa authorization exec LOCAL_EXEC local- Use local attributes to authorize the initial EXEC shell.
line vty 0 4- Select the remote lines used by this exercise.
login authentication LOCAL_LOGIN- Apply the local login list before any central service dependency.
authorization exec LOCAL_EXEC- Apply the local EXEC authorization list.
transport input ssh- Allow protected SSH terminal transport only.
exec-timeout 5 0- End idle remote sessions after five minutes.
line vty 5 15- Select the remaining verified VTY range.
transport input none- Disable unused remote admission paths.
end- Return to privileged EXEC (#). This neither saves the configuration nor reverses accepted changes.
- What you should see
- The declared remote range should use local authentication and authorization.
- Why this step matters
- Defining a method list is not enough; the line needs the intended binding.
Prove the recovery credential
In GNS3, right-click Admin1 and choose Console before typing. At the Linux shell, verify R1's host identity and enter the local secret only at the prompt. The next two commands run inside IOS. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
ssh breakglass@192.0.2.1
show privilege
exitWhat each command means
ssh breakglass@192.0.2.1- Open a new session through the local-only baseline.
show privilege- Verify the deliberate recovery account has privilege 15.
exit- Close the session and return to Admin1's shell.
- What you should see
- The local account should work before any central lists are applied.
- Why this step matters
- Do not proceed to central testing with an unverified recovery credential.
Define the TACACS+ client
In GNS3, right-click R1 and choose Console before typing. Start at # in the Console. Replace TAC_KEY with the same private value configured for R1 on ISE1. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
configure terminal
tacacs server TAC1
address ipv4 192.0.2.20
key TAC_KEY
exit
aaa group server tacacs+ TAC_GRP
server name TAC1
exit
ip tacacs source-interface GigabitEthernet1
endWhat each command means
configure terminal- Enter global configuration mode from privileged EXEC (#); accepted changes affect the running device.
tacacs server TAC1- Create a named TACACS+ server object.
address ipv4 192.0.2.20- Set ISE1 as the TCP 49 service destination.
key TAC_KEY- Set the client/server shared secret, distinct from user passwords.
exit- Leave server-object configuration.
aaa group server tacacs+ TAC_GRP- Create the named group used by method lists.
server name TAC1- Add the server object to this group.
exit- Return to global configuration.
ip tacacs source-interface GigabitEthernet1- Use R1's .1 address so ISE1 matches the declared network device.
end- Return to privileged EXEC (#). This neither saves the configuration nor reverses accepted changes.
- What you should see
- The server object, group and source interface should agree with the server contract.
- Why this step matters
- A key or source mismatch is a protocol relationship failure, not necessarily a bad netop password.
Define the RADIUS client
In GNS3, right-click R1 and choose Console before typing. Start at #. Replace RAD_KEY privately; this is separate from TAC_KEY. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
configure terminal
radius server RAD1
address ipv4 192.0.2.20 auth-port 1812 acct-port 1813
key RAD_KEY
exit
aaa group server radius RAD_GRP
server name RAD1
exit
ip radius source-interface GigabitEthernet1
endWhat each command means
configure terminal- Enter global configuration mode from privileged EXEC (#); accepted changes affect the running device.
radius server RAD1- Create a distinct named RADIUS server object.
address ipv4 192.0.2.20 auth-port 1812 acct-port 1813- Specify ISE1's classic access and accounting destination ports.
key RAD_KEY- Set the RADIUS relationship secret that matches ISE1's R1 definition.
exit- Leave server-object configuration.
aaa group server radius RAD_GRP- Create the RADIUS group referenced by the separate policies.
server name RAD1- Add the RADIUS server object to this group.
exit- Return to global configuration.
ip radius source-interface GigabitEthernet1- Keep the RADIUS client source fixed at the registered .1 address.
end- Return to privileged EXEC (#). This neither saves the configuration nor reverses accepted changes.
- What you should see
- RADIUS has its own named server and group even though ISE1 is the same appliance.
- Why this step matters
- A working TACACS+ service does not validate RADIUS ports, secret or attributes.
Define both complete session policies
In GNS3, right-click R1 and choose Console before typing. Start at #. These named lists do not affect the local Console and are not active on VTYs until explicitly attached. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
configure terminal
aaa authentication login TAC_LOGIN group TAC_GRP local
aaa authorization exec TAC_EXEC group TAC_GRP local
aaa accounting exec TAC_ACCT start-stop group TAC_GRP
aaa authentication login RAD_LOGIN group RAD_GRP local
aaa authorization exec RAD_EXEC group RAD_GRP local
aaa accounting exec RAD_ACCT start-stop group RAD_GRP
endWhat each command means
configure terminal- Enter global configuration mode from privileged EXEC (#); accepted changes affect the running device.
aaa authentication login TAC_LOGIN group TAC_GRP local- Try TACACS+ authentication, then local only if the earlier method cannot supply a usable decision.
aaa authorization exec TAC_EXEC group TAC_GRP local- Request TACACS+ shell authorization with local recovery on method error.
aaa accounting exec TAC_ACCT start-stop group TAC_GRP- Send TACACS+ session start and stop records; this is not command accounting.
aaa authentication login RAD_LOGIN group RAD_GRP local- Define the equivalent RADIUS login order, without treating a reject as an outage.
aaa authorization exec RAD_EXEC group RAD_GRP local- Use RADIUS EXEC attributes with a local error-path fallback.
aaa accounting exec RAD_ACCT start-stop group RAD_GRP- Send session accounting to RADIUS UDP 1813.
end- Return to privileged EXEC (#). This neither saves the configuration nor reverses accepted changes.
- What you should see
- Six named policies should exist with distinct login, authorization and accounting roles.
- Why this step matters
- Authentication fallback alone does not guarantee that shell authorization and accounting behave as intended.
Apply and verify TACACS+
In GNS3, right-click R1 and choose Console before typing. At # apply the first six lines. Then right-click Admin1 > Console and run the remaining lines from its shell; show commands and exit run inside the successful IOS session. Use netop's central secret. The final breakglass attempt must be rejected; allow one password prompt only. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
configure terminal
line vty 0 4
login authentication TAC_LOGIN
authorization exec TAC_EXEC
accounting exec TAC_ACCT
end
ssh netop@192.0.2.1
show privilege
show clock
exit
ssh -o NumberOfPasswordPrompts=1 breakglass@192.0.2.1What each command means
configure terminal- Enter global configuration mode from privileged EXEC (#); accepted changes affect the running device.
line vty 0 4- Select the tested remote line range.
login authentication TAC_LOGIN- Apply central TACACS+ login with the specified error-path fallback.
authorization exec TAC_EXEC- Apply the matching EXEC authorization policy.
accounting exec TAC_ACCT- Apply the TACACS+ session accounting list.
end- Return to privileged EXEC (#). This neither saves the configuration nor reverses accepted changes.
ssh netop@192.0.2.1- From Admin1, test the server-only user; no local netop account exists.
show privilege- Verify the intended central result is privilege 1.
show clock- Perform a harmless permitted user-level command; the displayed time is not proof of synchronization.
exit- Close the session so a stop record can be sent.
ssh -o NumberOfPasswordPrompts=1 breakglass@192.0.2.1- From Admin1, demonstrate that ISE1's explicit rejection is not overridden by the valid local account.
- What you should see
- Require netop success at privilege 1, breakglass rejection and corresponding ISE1 TACACS authentication/authorization and start/stop records.
- Why this step matters
- A missing or wrong server result is a failed test to investigate, not permission to weaken the policy.
Apply and verify RADIUS separately
In GNS3, right-click R1 and choose Console before typing. At # apply the first six lines, then open Admin1's Console for the remaining commands exactly as in the TACACS+ test. Use the central netop secret and only one breakglass attempt. Inspect the RADIUS access and accounting records, not the previous TACACS results. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
configure terminal
line vty 0 4
login authentication RAD_LOGIN
authorization exec RAD_EXEC
accounting exec RAD_ACCT
end
ssh netop@192.0.2.1
show privilege
show clock
exit
ssh -o NumberOfPasswordPrompts=1 breakglass@192.0.2.1What each command means
configure terminal- Enter global configuration mode from privileged EXEC (#); accepted changes affect the running device.
line vty 0 4- Select the same remote lines for a controlled protocol comparison.
login authentication RAD_LOGIN- Switch login authentication to the named RADIUS policy.
authorization exec RAD_EXEC- Switch EXEC authorization to the RADIUS attributes and fallback policy.
accounting exec RAD_ACCT- Switch session accounting to the RADIUS method list.
end- Return to privileged EXEC (#). This neither saves the configuration nor reverses accepted changes.
ssh netop@192.0.2.1- From Admin1, test the same server-only identity through RADIUS.
show privilege- Verify that the returned shell privilege is 1.
show clock- Check a harmless command without claiming per-command RADIUS authorization.
exit- Close the session for its accounting stop event.
ssh -o NumberOfPasswordPrompts=1 breakglass@192.0.2.1- Confirm the reachable server rejects the local-only user in this protocol as well.
- What you should see
- Require a RADIUS accept with the intended privilege, an explicit reject and actual session accounting evidence.
- Why this step matters
- The same username and appliance address do not make the two protocol configurations interchangeable.
Test a bounded RADIUS outage
In GNS3, right-click Admin1 and choose Console before typing. Close remote sessions. In GNS3 right-click only the ISE1 GigabitEthernet0--Switch1 Ethernet2 link and select Suspend; leave both VMs and R1's Console running. At Admin1's Console run these commands and wait for the actual AAA timeout without repeated attempts. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
ssh breakglass@192.0.2.1
show privilege
exitWhat each command means
ssh breakglass@192.0.2.1- Use the local account while the active RADIUS method cannot reach its server; enter only its local secret.
show privilege- If fallback succeeds, verify the intended local recovery privilege is 15.
exit- Close the recovery session and return to Admin1's shell.
- What you should see
- After the server method times out, local authentication and EXEC authorization should allow breakglass. Record actual delay and failure if it does not; remote accounting may be missing.
- Why this step matters
- This is server unavailability, unlike the earlier definitive reject. No password or policy is changed to manufacture the difference.
Restore the same server path and retest
In GNS3, right-click Admin1 and choose Console before typing. In GNS3 resume the same suspended ISE1 link. Open Admin1's Console and wait for actual service reachability. Run the listed tests, then inspect ISE1's new RADIUS results and accounting using its trusted private GUI. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
ssh netop@192.0.2.1
show privilege
exit
ssh -o NumberOfPasswordPrompts=1 breakglass@192.0.2.1What each command means
ssh netop@192.0.2.1- Verify the restored server-only identity can authenticate centrally again.
show privilege- Check the central privilege returns to 1, distinct from the local recovery role.
exit- End the session for its stop record.
ssh -o NumberOfPasswordPrompts=1 breakglass@192.0.2.1- Verify the reachable server again rejects the local-only identity.
- What you should see
- Central netop access should recover and breakglass should again be rejected remotely; do not assume outage accounting was recovered.
- Why this step matters
- Restoration must reestablish the normal policy decision, not leave the device on unintended local-only behavior.
Roll back to the known local baseline
In GNS3, right-click R1 and choose Console before typing. At # in the retained Console, restore the original VTY lists. Then close GUI sessions, stop the isolated project using normal appliance shutdown procedures and revert disposable snapshots; do not hard-power off a retained ISE database. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.
configure terminal
line vty 0 4
login authentication LOCAL_LOGIN
authorization exec LOCAL_EXEC
no accounting exec RAD_ACCT
end
show running-config | section line vtyWhat each command means
configure terminal- Enter global configuration mode from privileged EXEC (#); accepted changes affect the running device.
line vty 0 4- Select only the remote lines changed during the experiment.
login authentication LOCAL_LOGIN- Restore the previously verified local login baseline.
authorization exec LOCAL_EXEC- Restore the local EXEC authorization baseline.
no accounting exec RAD_ACCT- Remove the currently applied RADIUS session accounting list from these lines.
end- Return to privileged EXEC (#). This neither saves the configuration nor reverses accepted changes.
show running-config | section line vty- Verify the final line bindings without publishing the configuration.
- What you should see
- The Console remains local-only and VTYs return to the known local baseline before the disposable credentials are retired.
- Why this step matters
- A rollback names the actual prior policy; it does not disable AAA globally or bypass authentication.
Verify
- For each central protocol, require server-only netop success, privilege 1, explicit breakglass rejection and actual accounting evidence.
- Check ISE1 identifies the network device as R1 at .1, not Admin1 at .10; never include shared secrets in the evidence.
- During the RADIUS link outage, record actual fallback behavior and delay; after resumption require central success and restored rejection.
- Mark TACACS+ outage, per-command authorization/accounting, redundant servers, MFA, TLS/IPsec and server installation untested.
Troubleshoot
- No AAA request appears: verify the applied named list, group membership, destination, source interface and suspended-link state.
- ISE1 rejects netop: read the actual policy and identity-store reason. A reject is not corrected by putting local last.
- Authentication passes but no shell starts: inspect EXEC authorization and returned privilege attributes separately.
- No accounting record: verify the applied accounting list, UDP 1813 or TACACS service and server collection. Do not infer receipt from a successful shell.
- Server demands stronger transport or message authentication than the old fixture supports: stop; use a reviewed compatible platform or the paper alternative, not a weakened production policy.
GNS3 does not provide Cisco software images. Use Cisco images only when the applicable license or entitlement permits this environment. Do not share or redistribute image files. Cisco Modeling Labs is an official alternative; its supplied reference images are licensed for CML, not automatically for export to GNS3. Use the labeled paper alternative when authorized software is unavailable. No emulator execution is claimed by this lesson.
- Restore the named local baseline and resume the one suspended link before retiring the project.
- Use normal ISE shutdown and clean disposable snapshots to retire local accounts, shared secrets and private policy data.
Practice set
Answer before you reveal
01Who is the AAA client when Admin1 uses SSH to R1?
R1 sends the central request from its configured .1 address. The two client roles belong to different protocol relationships.
02Does a successful password check prove authorization?
The lab separately checks the resulting privilege. It does not configure or claim granular per-command authorization.
03Why does breakglass fail while the server is reachable?
The trailing local method is for an earlier method's error or unavailability, not a general override of central policy.
04Is the shared secret netop's password?
User credentials authenticate the user. A matching client address and relationship secret are separate prerequisites.
05What does EXEC accounting record here?
It is not a full command transcript. Actual server receipt must be checked, and outage records cannot be assumed to arrive later.
06What can a learner prove without the server fixture?
The server's identity store, policy and accounting receiver are essential to the full tests; a nonexistent server cannot validate them.
07Does SSH protect the classic AAA hop automatically?
The separate router-to-server protocol needs its own supported protection. This exercise is confined to a disconnected disposable lab.
Knowledge check
Quiz: prove the reasoning
Keep these
Technical takeaways
- AAA identity, permission and records require separate evidence.
- R1 is the AAA client even though Admin1 starts SSH.
- A reject and an unreachable server have different fallback behavior.
- A local-only Console is a deliberate recovery boundary.
- A complete client procedure still requires a real compatible policy server.
- Classic AAA transport in this isolated lab is not a production security endorsement.
