Cisco Nexus SNMPv3 User Appears as a CLI Account: Before You Delete It
An internal vulnerability assessment called for removing apparently unnecessary accounts from a Cisco Nexus switch. I found an SNMPv3 username listed as a local CLI user. From my experience with Cisco IOS, I initially treated the monitoring identity and the administrative login as separate objects. I paused the deletion to check NX-OS behavior. By default, NX-OS synchronizes SNMPv3 users with its security user database, so deleting the CLI account can 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
Usernames, passwords, customer information, and environment-specific details have been omitted.
How I found the account
I found the entries with:
show running-config | include userThe output included a local username and an snmp-server user entry for the same identity. The entries had this structure:
username <SNMP-USER> ...
snmp-server user <SNMP-USER> ...This is a generalized structural example with authentication details removed.
Why I considered deleting it
Based on the IOS environments I had worked with, the initial recommendation was to remove the apparent SNMP-only identity from the local administrator account list. No deletion took place. Cisco warns that NX-OS SNMP commands and behavior can differ from IOS. I needed to verify how NX-OS handled the user before acting on that recommendation.
How NX-OS synchronizes the users
Cisco documents the following behavior when SNMP and security user synchronization is active:
- An authentication passphrase configured with
snmp-server usercan become the password for the corresponding CLI user. - A password configured with the
usernamecommand 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.
An SNMPv3 username can therefore appear in a local account review because the databases are synchronized. The entry alone does not establish that the account is unused.
What deletion could affect
Removing the CLI username while synchronization is active can also remove the SNMPv3 identity, leaving the NMS without authenticated SNMP access. Possible 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
These are possible consequences of deletion. In this review, the account was retained after the synchronization behavior was confirmed.
Check the assigned role
The accounts under review had a mixture of assigned roles. A local username does not automatically have network-admin privileges. NX-OS role-based access control determines its permissions, so check the role before classifying a username entry as an unnecessary administrator. Display account and role information with show user-account:
show user-accountVerification commands before deletion
For an account review, use:
show running-config | include user
show snmp user
show user-account
show running-config security
show running-config snmpEach command checks a different part of the configuration:
show running-config | include userprovides a quick cross-check of username-related configuration lines.show snmp userdisplays configured SNMP users and their SNMP security properties.show user-accountdisplays local account information and assigned roles.show running-config securityprovides the security user configuration.show running-config snmpprovides the SNMP configuration context.
The running-configuration filter produced the original observation. The other commands are recommended checks; they were not all recorded as steps in this incident.
The same evidence-first approach is useful for other Nexus security settings. See Cisco Nexus ICMP Unreachable: Why the Command Does Not Appear in Running-Config for a separate investigation of configuration display, defaults, and operational interface state.
Disabling SNMP and AAA user synchronization
Cisco introduced this command in NX-OS 10.2(2)F to disable synchronization between SNMP and the security components:
snmp-server disable snmp-aaa syncThe switch ran NX-OS 10.6(1), within the documented release family. I did not apply the command. With synchronization disabled:
- A user created with
snmp-server userdoes not create a corresponding CLI username. - A user created with the
usernamecommand does not automatically become an SNMP user.
The default synchronized behavior uses the no form:
no snmp-server disable snmp-aaa syncTo check the state, Cisco documents show snmp internal globals and its SNMP-AAA sync disable field.
Dependencies to review before changing synchronization
Changing synchronization affects how accounts are created and can affect authentication, automation, and controller discovery. Review those dependencies before choosing it as remediation. Cisco documents these 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.
Test any proposed change against the exact platform, NX-OS release, NMS credentials, AAA design, and controller dependencies.
If the review also raises questions about local password storage, see our comparison of Cisco Nexus password type 5 and IOS password types before interpreting the configuration marker.
Account review 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.
Review outcome
I retained the account after confirming the synchronization behavior. The original deletion recommendation was not applied, and the effect of a synchronization change still required a separate review.
Checks before deletion
Before removing an SNMPv3 identity that appears as a CLI account, check:
username references
→ SNMP user status
→ assigned role
→ synchronization state
→ NMS dependency
→ deletion impactRelated security review: In a separate Cisco IOS/IOS XE review, we examined whether login and configuration-change logs could satisfy an AAA-related audit requirement. Read Cisco AAA and Audit Logging: Why Authorization Changed Our Decision for the alternatives we considered and why authorization-denial evidence drove the decision to use AAA.
References
- Cisco Nexus 9000 Series NX-OS System Management Configuration Guide, Release 10.6(x) - Simple Network Management Protocol
- Cisco Nexus 9000 Series NX-OS Security Configuration Guide, Release 10.6(x) - Configuring User Accounts and RBAC
This case describes an operational account review. Usernames, passwords, customer information, hostnames, and other identifying details have been omitted or generalized. No account deletion or synchronization change was performed.
Comments
Post a Comment