Cisco Nexus SNMPv3 User Appears as a CLI Account: Before You Delete It

During an internal vulnerability assessment, one of the requested remediation actions was to remove accounts that appeared to be unnecessary on a Cisco Nexus switch.

While reviewing the configuration, I found that a username used for SNMPv3 also appeared as a local CLI user. My first assumption was that the SNMP identity and the administrative login account should be treated separately. That assumption came from Cisco IOS environments I had handled previously.

Before deleting the account, I verified the behavior more carefully. Cisco NX-OS synchronizes SNMPv3 users with its security user database by default. Deleting what looks like an unused CLI account can therefore also remove the SNMP user and interrupt monitoring.

Environment

Platform: Cisco Nexus C93180YC-FX3
Software: Cisco NX-OS 10.6(1)
Context: Internal vulnerability assessment and account cleanup
Change status: No account was deleted

All usernames, passwords, customer information, and environment-specific details have been omitted.

How the Account Was Found

The initial review used a simple running-configuration filter:

show running-config | include user

The result contained both a local username entry and an snmp-server user entry. The same operational identity was therefore visible in both the CLI account configuration and the SNMP configuration.

A generalized representation of what triggered the investigation is:

username <SNMP-USER> ...
snmp-server user <SNMP-USER> ...

This is only a structural example. It is not the original configuration, and authentication details have intentionally been excluded.

The Initial Assumption

In the Cisco IOS environments I had worked with most often, I treated the SNMPv3 identity and the local administrative login account as separate configuration objects. Based on that experience, the initial remediation recommendation was to remove the apparent SNMP-only account from the local administrator account list.

That recommendation was paused before any deletion was performed.

This distinction matters because Cisco explicitly warns that NX-OS commands and behavior for SNMP can differ from Cisco IOS. Familiarity with IOS should not be used as evidence of how the NX-OS user database behaves.

Why the SNMP User Also Appears as a CLI User

Cisco documents user configuration synchronization between the SNMP and security components in NX-OS. Under the default synchronized behavior:

An authentication passphrase configured with snmp-server user can become the password for the corresponding CLI user.
A password configured with the username command can become the authentication and privacy passphrases for the corresponding SNMP user.
Creating or deleting a user through either SNMP or the CLI can create or delete that user in both user databases.
User-to-role mapping changes are synchronized between SNMP and the CLI.
CLI role changes can also be synchronized to SNMP.

That synchronization explains why an SNMPv3 account can appear during a local account review. Its presence does not, by itself, prove that the account is unused.

Why Blind Deletion Is Risky

If synchronization is active, removing the username from the CLI side can also remove the SNMPv3 identity. The immediate security finding may appear resolved, but the NMS could then lose authenticated SNMP access to the switch.

Possible operational effects include:

SNMP polling failures
Loss of interface, environmental, or performance data
Device-down or authentication alarms in the NMS
A monitoring outage that is discovered only after the account cleanup

In this case, the deletion was not attempted. The review stopped after confirming that the two configurations could be linked.

Account Presence and Administrator Privilege Are Not the Same

Another important distinction is the assigned role. The reviewed accounts did not all have the same role; the environment contained a mixture of roles.

A username appearing in the local account database does not automatically mean that it has network-admin privileges. NX-OS role-based access control determines what the user can do. Before classifying an account as an unnecessary administrator, verify the actual role instead of relying only on the presence of a username line.

Cisco documents show user-account as the command for displaying user account and role information:

show user-account

Verification Commands Before Any Deletion

The following checks provide a safer account-review workflow:

show running-config | include user
show snmp user
show user-account
show running-config security
show running-config snmp

These commands answer different questions:

show running-config | include user provides a quick cross-check of username-related configuration lines.
show snmp user displays configured SNMP users and their SNMP security properties.
show user-account displays local account information and assigned roles.
show running-config security provides the security user configuration.
show running-config snmp provides the SNMP configuration context.

In the original review, the key observation came from the running-configuration filter. The additional commands above are the recommended verification set, not a claim that every command was used during the original incident.

NX-OS Can Disable SNMP and AAA User Synchronization

Starting with Cisco NX-OS Release 10.2(2)F, Cisco provides the following command to disable synchronization between SNMP and the security components:

snmp-server disable snmp-aaa sync

Because the switch in this case was running NX-OS 10.6(1), the documented feature falls within the relevant release family. However, the command was not applied during this incident.

When desynchronization is enabled:

A user created with snmp-server user does not create a corresponding CLI username.
A user created with the username command does not automatically become an SNMP user.

The default synchronized behavior is represented by the no form of the command:

no snmp-server disable snmp-aaa sync

Cisco documents show snmp internal globals as one method to check the synchronization state. The relevant field is SNMP-AAA sync disable.

Do Not Enable Desynchronization as a Quick Fix

The availability of a desynchronization command does not make it an automatic remediation choice. Changing the user-database model can affect account creation, authentication, automation, and controller discovery.

Cisco specifically notes several limitations:

Using desynchronization with DCNM, now Nexus Dashboard Fabric Controller, is not recommended because controller discovery can depend on corresponding SNMP user configuration.
SNMP users may need to be created explicitly after synchronization is disabled.
Cisco warns against re-enabling synchronization while desynchronized users remain, because that combination can cause a configuration replace failure.
Localized-key or encrypted-password configurations have separate synchronization behavior and must be evaluated independently.

Any change should therefore be tested against the exact platform, NX-OS release, NMS credentials, AAA design, and controller dependencies.

A Better Vulnerability-Remediation Workflow

Record the finding without immediately deleting the account.
Identify every reference to the username in the security and SNMP configuration.
Verify the assigned NX-OS role.
Confirm whether the NMS actively uses the SNMPv3 identity.
Check whether SNMP/AAA synchronization is enabled.
Review NDFC, AAA, automation, and monitoring dependencies.
Choose between retention, replacement, privilege reduction, credential rotation, or a planned desynchronization design.
Validate monitoring before and after any approved change.

This turns an account-cleanup request into an impact-based remediation decision.

Final Result

No account was deleted during this review. The important result was discovering the NX-OS synchronization behavior before applying the original remediation recommendation.

The confirmed position at the end of the review was:

The CLI and SNMP user entries can be synchronized.
Deleting the account can remove both representations.
NX-OS provides a desynchronization command on supported releases.
The effect of changing that behavior still requires a separate impact review.

This is a valid outcome for a security assessment. Preventing an unverified deletion is better than creating a monitoring outage and then troubleshooting it afterward.

Key Takeaway

On Cisco NX-OS, an SNMPv3 username appearing as a local CLI account is not necessarily an accidental or unused administrator account. It can be the expected result of SNMP and security user synchronization.

Before deleting it, verify:

username references
→ SNMP user status
→ assigned role
→ synchronization state
→ NMS dependency
→ deletion impact

The most important step in this incident was not a configuration command. It was stopping the deletion long enough to confirm how NX-OS manages the account.

References

Note: This article is based on an operational account review. Usernames, passwords, customer information, hostnames, and other identifying details have been omitted or generalized. No deletion or synchronization change was performed during the incident.

Search This Blog

NetOps Field