Configuring User Accounts and RBAC on Cisco Nexus Switches (NX-OS Guide)

Understanding User Access on Cisco Nexus Switches

Managing user access is a fundamental aspect of network security and administration. While many network engineers are familiar with the privilege level system in Cisco IOS, the Cisco Nexus platform (running NX-OS) uses a more granular and powerful method called Role-Based Access Control (RBAC). This guide will walk you through the core concepts of NX-OS user accounts and RBAC, showing you how to secure your devices effectively.

While the examples here were originally demonstrated on a Nexus 7000 series switch, the core principles of RBAC are foundational to the NX-OS architecture and remain relevant across the Nexus family, including the modern Nexus 9000 series.

NX-OS User Roles vs. IOS Privilege Levels

In the classic Cisco IOS, access control is managed through privilege levels, a numeric system from 0 to 15 that defines what commands a user can execute.

• Privilege Level 1: The default user-level access, typically providing basic monitoring commands at the router> prompt.
• Privilege Level 15: Full administrative access, equivalent to the “enable” mode at the router# prompt.

NX-OS replaces this rigid system with User Roles. A role is a collection of rules that explicitly define the permissions granted to any user assigned to that role. This allows for much more flexible and detailed control over user capabilities.

Default User Roles in NX-OS

NX-OS comes with several predefined roles that serve common administrative needs. The roles you see depend on whether you are working in the default administrative Virtual Device Context (VDC) or a user-created VDC.

• network-admin: The highest level of privilege, offering complete read-and-write access to the entire physical device. This role is only available in the default VDC and is roughly equivalent to a root administrator.
• network-operator: Provides complete read-only access across the entire device. This is the default role assigned to new users if no other role is specified.
• vdc-admin: Provides full read-and-write access, but only within the specific VDC to which the user is logged in.
• vdc-operator: Provides read-only access limited to the scope of the current VDC.

A Note on Virtual Device Contexts (VDCs)

Virtual Device Contexts (VDCs) are a powerful feature exclusive to the Cisco Nexus 7000 series platform. They allow you to partition a single physical switch into multiple logical switches, each with its own separate configuration, management, and data planes. This is excellent for creating administrative separation, isolating failure domains, and segmenting resources like VLANs and VRFs.

It’s important to note that VDCs were never a feature on other platforms like the now End-of-Life Nexus 5000 series. When you create a new user, their default role will be ‘network-operator’ in the system VDC or ‘vdc-operator’ if created within a non-default VDC.

Creating and Configuring Custom Roles

Beyond the default roles, the true power of RBAC lies in creating custom roles tailored to specific job functions. Let’s create a custom role named “AFROZ” for a network engineer who needs to manage Layer 3 routing protocols but should have limited access to other features.

Step 1: Create the Role and Assign Privileges

First, we’ll create the role and grant it read-write permissions for the “l3-route” feature group, which contains commands related to routing protocols like OSPF and BGP.

N7K(config)# role name AFROZ
N7K(config-role)# rule 1 permit read-write feature-group l3-route
N7K(config-role)# show role name AFROZ

Role: AFROZ
  Description: 
  Vlan policy: permit (default)
  Vrf policy: permit (default)
  Interface policy: permit (default)
  ------------------------------------------------------------------
  Rule    Perm    Type        Scope               Entity
  ------------------------------------------------------------------
  1       permit  read-write  feature-group       l3-route

Step 2: Deny Access to Specific Features

Now, let’s refine the role. We’ll deny access to all VLANs except for the range 1-100, deny access to all VRF instances except “INTERSWITCH”, and restrict interface configuration to only the first two 1-Gigabit Ethernet ports and all port-channels.

N7K(config-role)# rule 2 deny feature vlan
N7K(config-role)# rule 3 permit feature vlan 1-100
N7K(config-role)# rule 4 deny feature vrf
N7K(config-role)# rule 5 permit feature vrf INTERSWITCH
N7K(config-role)# rule 6 deny feature interface
N7K(config-role)# rule 7 permit feature interface Ethernet1/1-2
N7K(config-role)# rule 8 permit feature interface port-channel
N7K(config-role)# show role name AFROZ

Role: AFROZ
  Description: 
  ------------------------------------------------------------------
  Rule    Perm    Type        Scope               Entity
  ------------------------------------------------------------------
  1       permit  read-write  feature-group       l3-route
  2       deny    read-write  feature             vlan
  3       permit  read-write  feature             vlan 1-100
  4       deny    read-write  feature             vrf
  5       permit  read-write  feature             vrf INTERSWITCH
  6       deny    read-write  feature             interface
  7       permit  read-write  feature             interface Ethernet1/1-2
  8       permit  read-write  feature             interface port-channel

Notice how NX-OS processes rules in order. We first deny a broad feature and then permit a specific subset of it.

Applying and Verifying a New Role

With our custom role created, let’s assign it to a new user. We’ll also ensure password strength checking is enabled to enforce strong passwords.

N7K(config)# password strength-check

N7K(config)# username afroz password admin123
Weak password. To override, re-enter the password.

N7K(config)# username afroz password Rbac@AFROZ role AFROZ

N7K(config)# show user-account afroz
user: afroz
    this user account has no expiry date
    roles: AFROZ

N7K(config)# role distribute
This command will distribute the user/role configuration to all linecards.
This will also save the current configuration. Continue (y/n)? [yes] y

The password strength-check command prevents the use of a weak password. We then create the user “afroz” with a strong password and assign our custom role. Finally, the role distribute command pushes this RBAC configuration to all line cards, ensuring consistency across the chassis.

RBAC Best Practices and Modern Context

While local RBAC is powerful, in most enterprise environments, it’s used in conjunction with centralized authentication, authorization, and accounting (AAA) servers like TACACS+ or RADIUS. In such a setup, roles can be defined on the AAA server and assigned to users upon login, providing centralized control across your entire network.

Key best practices include:

• Principle of Least Privilege: Always grant users the minimum level of access required to perform their jobs. Avoid using broad roles like network-admin for daily tasks.
• Use Centralized AAA: For scalability and auditability, integrate with TACACS+ or RADIUS to manage roles and user access from a central location.
• Audit Regularly: Periodically review user accounts and role definitions to ensure they are still appropriate and to remove stale accounts.

In modern data centers running Cisco ACI or using automation tools like Ansible, these RBAC principles are extended. Access policies are often defined in code or within the fabric controller, ensuring that security and access control are an integral part of your automated infrastructure.

Conclusion

We’ve explored how Cisco NX-OS moves beyond simple privilege levels to a sophisticated Role-Based Access Control system. By defining default roles and allowing for the creation of highly specific custom roles, NX-OS gives you granular control over user permissions. Mastering RBAC is a critical skill for any engineer managing a Cisco Nexus data center, providing a robust foundation for a secure and well-managed network.

Original Lab Hardware (Legacy Context)

For historical context, the original 2013 exercise was performed on a Nexus 7010 chassis with the following components:

• Dual supervisor modules, dual power supplies, dual system fans, dual fabric fans, and three fabric modules per chassis.
• One 48-port 1 Gigabit Ethernet I/O module per chassis.
• One 32-port 10 Gigabit Ethernet I/O module per chassis with SFP+ SR optical transceivers installed.
• Cisco NX-OS LAN Enterprise License.
• Cisco NX-OS LAN Advanced Services License.

• About
• Latest Posts

Afroz Ahmad

I'm Afroz, a Network Engineer and CCIE with more than18 years of experience in Computer Networking, Data Centers, Telecom, Internet Services and ISPs. Currently, I work as a Network Designer for a leading ISP equipment vendor. I share my expertise through my blog and courses, aiming to share my knowledge and simplify complex networking concepts for both beginners and experienced professionals.

Latest posts by Afroz Ahmad (see all)

• How to Configure a Secure Site-to-Site VPN on Cisco Firepower Complete Guide - December 3, 2025
• Jobs for Network Engineers: Roles, Skills & Pay - December 3, 2025
• How to Change WiFi Password on Any Router : The Last Guide You Need - December 1, 2025