Cisco Nexus User Roles

IOS relies on privilege levels.  Privilege levels (0-15) defines locally what level of access a user has when logged into an IOS device, i.e. what commands are permitted. This only applies in the absence of AAA being configured. There are 3 default privilege levels on IOS, but really only two that are relevant:

• Privilege Level 1 — Normal level on Telnet; includes all user-level commands at the router> prompt.
• Privilege Level 15 — Includes all enable-level commands at the router# prompt.

NX-OS uses a different concept for the same purpose, known as User Roles. User Roles contain rules that define the operations allowed for a particular user assigned to a role. There are default User Roles:

• Network-Admin—Complete read-and-write access to the entire NX-OS device (only available in the default VDC).
• Network-Operator—Complete read access to the entire NX-OS device (Default User Role).
• VDC-Admin—Read-and-write access limited to a VDC (VDCs are not yet available on Nexus 5000).
• VDC-Operator—Read access limited to a VDC (Default User Role).

A VDC (Virtual Device Context) is a logical separation of control plane hardware resources into virtualized layer3 switches. Don’t worry to much about what a VDC is for now, it is not really relevant to the purpose of this post.

When a NX-OS device is setup for the first time, during the first login, a Network-Admin account must be specified and subsequently be used to login. Arguably a bit more secure that IOS. Any additional users created locally after that will by default receive the User Role “Network-Operator“, unless specified differently:

User Roles are local to a switch and only relevant in the absence of AAA Authorization being configured. To see the permissions of a particular User Role use:

N5K-2# sh role name network-operator
Role: network-operator
  Description: Predefined network operator role has access to all read
  commands on the switch
  -------------------------------------------------------------------
  Rule    Perm    Type        Scope               Entity
  -------------------------------------------------------------------
  1       permit  read

By default when logging into a Nexus with no AAA configured, or when only AAA Authentication is configured, the user will be issued a default User-Role if a Role was not provided during the authentication process.The default User-Role assigned depends on the Nexus system logged into. When logging into a N5K or a N7K system VDC, the default User-Roles assigned is “network-operator”. When logging into a VDC, the default User-Roles is “vdc-operator”

The default User Roles are limited to only certain commands.  One such example, see what happens to user TEST4 when attempting to change a system level command:

N5K-2(config)# snmp-server community 123
     cannot make changes for SNMP community

N5K-2(config)# sh user-account test4
user:test4
        roles:network-operator
account created through REMOTE authentication
Credentials such as ssh server key will be cached temporarily only for this user  account

When no AAA is configured the role is retrieved from the local “username” command, if configured. If AAA with Authentication only was configured, a Nexus switch expects the TACACS or RADIUS server to issue a Role along with the user credentials within the response, else a default User-Role is used. AAA with Authentication and Authorization overwrites the use of the default User Roles and custom User Roles. RBAC (Role-Based Access Control) is the ability on a Nexus to configure Custom User Roles and their permissions.

So there are two implementation of authorization supported on a Nexus.

1. Full AAA with Authentication and Authorization.
2. AAA with Authentication and no AAA Authorization relying on local RBAC.

Option number 1 is straight forward, but not always desired. Example would be when RBAC is more desired than AAA Authorization. RBAC allows each device to have its own set of authorization instructions and commands for the same user. Another example is when using Shrubbery’s TACPLUS instead of Cisco ACS since TACLUS does not support devices to be grouped and a group-to-acl applied to device groups.

Option number 2 is done by specifying AAA authentication and relying on the User Role designation, which can be assigned based on the default User-Roles or by specifying the User-Role to be offered during the authentication process. By using the VSA (Vendor-Specific Attributes) ‘cisco-av-pair’ parameter on AAA servers you can specify User Role mappings for the Cisco Nexus Series switches using the following Cisco documented format.

shell:roles="roleA roleB …"

The only catch, the VSA role specified in TACACS must be valid on the local boxes, else a default User Role will still be applied. I’ll show how to apply this in TACPLUS and it should make more sense then. Firstly edit the following file:

/usr/local/etc/tacacs/tacacs.conf

Then under the appropriate TACACS User Group add the ‘shell role’ :

  group = GROUPNAME {
       default service = permit
       acl = LEVELBASED-ACL
       service = exec {
               idletime = 5
               timeout = 15
               shell:roles="network-admin"
       }
}

The outcome of option 2 should yield the following result. When user TEST4 logs into the same N5K switch, instead of the N5K assigning a default User Role, TEST4 will be logged in with the User Role provided by the TACACS server which allows TEST4 to perform all the required functions on the NX-OS device:

N5K-2(config)# sh user-account test4
user:test4
        roles:network-admin
account created through REMOTE authentication
Credentials such as ssh server key will be cached temporarily only for this user account

N5K-2(config)# snmp-server community 123
N5K-2(config)#

Two things to be aware of

1- VDCs: If you using the same TACACS server for your Nexus 7000 and you running VDCs,  you will have to use multiple shell roles. i.e.:

shell:roles="network-admin vdc-admin"

The reason for this is that within a VDC there is no default Network-Admin User Role, only a VDC-Admin. If the assigned TACACS User Roles is not recognized within a VDC, the Nexus series switch will apply a default User-Role VDC-Operator.

– – UPDATE 28 August ’11- –

The multiple role format specified above, and as it is specified in Cisco Online Documentation only applies to the CISCO ACS software. For TACPLUS the following format is required to achieve the same result of assigning multiple roles. Refer to this POST  for more details.

shell:roles="\"network-admin vdc-admin\""

2- Cisco GSR routers: Even thought the Cisco GSR routers do not natively rely on user roles or RBAC, pushing a User Role to a Cisco GSR (12k) causes authentication problems. The authentication credentials are accepted, but the connection is disconnect once the GSR receives a Shell Role being pushed from the TACACS server, that it does not recognize resulting in a login failure. Thus if you have Cisco GSR routers using the same TACACS server, I strongly recommend the creation of separate device groups for your Nexus devices. (This is not possible with TACPLUS).

I trust this post was useful, in saving you some time sorting the AAA/TACACS vs NEXUS integration issues out.