Cisco Catalyst 9200L Local AAA Migration: Planning and Verification on IOS XE 17.18.4

After choosing AAA during a security review, we needed a migration plan that kept the existing source of login authentication. The target was a Catalyst 9200L on IOS XE 17.18.4 using local accounts, with no RADIUS or TACACS+ server. AAA was disabled. The VTY configuration was recalled as login local, pending confirmation. The proposal moves login authentication into AAA while retaining local accounts. It has not been applied or tested on the target switch.

Environment and change status

• Platform: Cisco Catalyst C9200L-24P-4G.
• Target software: Cisco IOS XE 17.18.4.
• Existing AAA state: Disabled.
• Identity source: Local user accounts on the switch.
• External authentication servers: None.
• Existing VTY authentication: Recalled as login local; configuration confirmation is required.
• Change status: Planning only, not deployed or tested on the target switch.

Cisco's Catalyst 9200 IOS XE 17.18.x documentation supports the approach. Validation is still required on the actual 17.18.4 device.

Scope of the local AAA plan

The decision originated from a security review of administrative access and audit requirements. The background is explained in Cisco AAA and Audit Logging: Why Authorization Changed Our Decision.

The scope is login authentication against the local user database.

Command authorization and retained authorization-denial records need separate design and validation. A successful local AAA login does not satisfy those requirements.

Confirm the baseline

This represents the recalled starting point. The VTY range remains a placeholder until the configuration is checked:

no aaa new-model
!
line vty <FIRST-LINE> <LAST-LINE>
 login local

Review the actual configurations locally before finalizing the change:

show version
show running-config
show startup-config

The commands inspect configuration, which can contain sensitive information. Sanitize output before sharing it in public tickets or articles. Identify:

• Every VTY range and its current login configuration.
• The console authentication configuration.
• The local account intended for testing and its assigned privilege.
• The current method of reaching privileged EXEC mode.
• Existing SSH transport restrictions, access lists, and session timeouts.
• Any difference between the running and startup configurations that would affect recovery.

Check every VTY block used for remote access.

The local default method list

The local method uses the switch's username database. This design does not require an external authentication server. The proposed default list is:

aaa authentication login default local

The default list applies where no named list has been explicitly selected. Review the console and other affected management paths as well as the VTY lines.

A named list provides an alternative where explicit assignment is required, but this plan uses a single local default list. See Cisco IOS XE 17.18.x — Configuring Authentication.

Proposed login configuration

Review this candidate fragment before execution. Replace the VTY placeholders with confirmed ranges and account for every applicable VTY block.

configure terminal
 aaa new-model
 aaa authentication login default local
 line vty <FIRST-LINE> <LAST-LINE>
  login authentication default
 exit
end

aaa new-model enables AAA. The method list uses the local database, and login authentication default selects it on the specified lines. A valid local account must already exist. This fragment does not create users, change passwords, or configure an external server. Preserve the existing SSH transport settings, access restrictions, and timeouts when changing the login method. These commands change the running configuration immediately and can prevent new administrative logins if authentication is wrong. Use verified console or recovery access and an approved maintenance plan.

Test authentication and privilege

Test the new session's administrative access as well as its ability to log in.

Cisco treats local authentication and authorization separately. EXEC and command authorization are outside this login fragment. See Configuring Local Authentication and Authorization.

In the new session, check:

show privilege

Compare the privilege level with the test account's intended role. Test the separate privileged EXEC path if the administrative workflow requires it. Resolve privilege mismatches against the approved design; do not give every account privilege 15 to make the test pass.

Validation before saving

Proposed validation:

1. Keep the verified recovery session available.
2. Inspect the resulting AAA and line configuration after the change.
3. Open a separate SSH connection using the intended local account.
4. Confirm that a fresh login succeeds, rather than relying on the original session remaining connected.
5. Check the session's privilege level and perform an approved read-only administrative check.
6. Perform a controlled invalid-credential test, accounting for any existing login-block or account-lockout policy.
7. Verify console access and any other management path affected by the authentication design.
8. Confirm that the reviewed authentication settings cover all intended VTY ranges.

Save only after the agreed checks pass:

copy running-config startup-config

Saving also includes other unsaved running-configuration changes. Review the complete change set first.

Prepare recovery access

Protect the known-good configuration, verify the credentials, and establish console or other approved recovery access before enabling AAA.

Do not assume that entering no aaa new-model will recreate the exact previous configuration. Cisco's 17.18.x command reference documents a VTY behavior caveat when removing AAA and explicitly discourages removing the command. See Catalyst 9200 Security Command Reference.

If validation fails, inspect authentication and line settings through the retained recovery session. Follow a restoration procedure based on the captured baseline and tested before production use. This plan does not use reboot as routine rollback. A reboot can interrupt forwarding and requires its own operational decision.

Acceptance criteria

• A fresh remote login succeeds with the intended local account.
• Invalid credentials are rejected during the controlled test.
• The account receives the intended privilege and administrative access.
• Console and recovery access remain usable.
• All intended VTY ranges have the reviewed authentication configuration.
• The validated configuration is saved after checking for unrelated changes.

Command authorization, accounting, and retained denial records still need separate acceptance criteria.

Deployment status

The proposal introduces AAA login while keeping authentication local, without an external server. Before deployment, confirm the baseline and default-list scope, preserve recovery access, and test a fresh login with the intended privilege. The migration remains unimplemented. A successful production result requires completing the target-device configuration and acceptance checks.

Related change-planning example

For a separate example of planning forwarding changes and validating their results, see Cisco Catalyst 9300 HQoS and Static BFD: Configuration Order and Verification. That guide covers Catalyst 9300 WAN QoS and static routing; its forwarding checks complement, rather than replace, the fresh-login and recovery-access checks in this Catalyst 9200L authentication plan.

References

• Cisco Catalyst 9200 Security Configuration Guide, IOS XE 17.18.x — Configuring Authentication
• Cisco Catalyst 9200 Security Configuration Guide, IOS XE 17.18.x — Configuring Local Authentication and Authorization
• Cisco Catalyst 9200 Command Reference, IOS XE 17.18.x — Security