RBAC with AAA Authentication

A earlier post introduced the Cisco Nexus concept of User Roles, which is a local command authorization method. There are some default system user roles.

RBAC (Role-Based Access Control) is the name/ability to create custom user roles locally on a Cisco Nexus. This gives the administrator the flexibility to define a group of certain commands to be allowed or denied for a selected role. Users can then be designated to belong to certain user roles. This designation can either be done locally on each switch or by using TACACS.

As discussed in the earlier post, AAA authorization and the user roles are mutually exclusive, since AAA Authorization overrides the permissions allowed with user roles. But using RBAC along with AAA Authentication (not Authorization), does bring some neat options to the table, depending obviously on a given network design and requirements.

How does RBAC work?

Custom user roles are defined by giving the role a name and by creating rules within the role. Each rule has a number, to decide the order in which the rules are applied. Rules are applied in descending order. I.e., rule 3 is applied before rule 2, which is applied before rule 1. This means a rule with a higher number overrides a rule with a lower number. Each role may have up to 256 rules configured. All the rules combined within a role determine what operations the role allows the associated user to perform.

Rules can be applied for the following parameters:

• Command — A command or group of commands defined in a regular expression.
• Feature — Commands that apply to a function provided by the Cisco Nexus switch.
• Feature group — Default or user-defined group of features.

The Command rule indicates a single command that could used to match a single command or include a variety of sub-commands. Examples of this will follow below.

The Feature rule refers to a grouping of commands as designated by Cisco. The different role features can be seen with “sh role feature”:

To see the commands within a single feature use “sh role feature name {FEATURE}”; or to see all commands in all feature use “sh role feature detail”.

User roles may also contain User Role Policies, which is used to limit the switch resources that the user roles may access. Currently with user role policies, access can be limited to subset of interfaces, VLANs and VSANs. But user role policies cannot be used without matching rules. For example, if you define an interface policy to permit access to specific interfaces, the user will not have access to the interfaces unless you configure a command rule for the role to permit the interface command.

Let me take you through some of the CLI configuration options, as the RBAC examples on the DOC-CD are elusive and occasionally incorrect. Firstly lets create a role named RBAC that only allows “show” commands. With RBAC ONLY the allowed commands are shown with CLI help (?).

role name RBAC
 rule 20 permit command show *

As mentioned earlier, the order of commands make a difference to allow one command overwriting another. Let say we want to prohibit users from issuing the “show version” command while still allowing all other “show” commands. A deny statement is thus added with a higher rule number to accomplish the request.

role name RBAC
 rule 21 deny command show version*
 rule 20 permit command show *

Now lets look at using User Role Policies. With this particular role we only want to allow the users to create VLAN 10-19. The “vlan xxx” configuration command is allowed as it is required. The VLAN user policy then denies all VLANs, while allowing only VLAN 10-19 to be created.

role name RBAC
 rule 21 deny command show version*
 rule 20 permit command show *
 rule 10 permit command configure ; vlan * ; *
 vlan policy deny
   permit vlan 10-19

To test this see the output below:

Lastly, lets add an interface role policy to only allow access to certain interface. Access here is limited to SVI interfaces 10-19, two physical interface (eth1/3 and eth1/4) and two FEX* interfaces (eth119/1/5-6). Access to configure other interfaces will be denied. Rule 7 is just another indication of the rule order to deny certain overlapping actions.

*FEX (Fabric Extender) is the Nexus 2000 series device. I will cover these in future posts.

Below is the full user role configuration created to far:

username ruhann password bob role RBAC
!
role name RBAC
  rule 21 deny command show version*
  rule 20 permit command show *
  rule 10 permit command configure ; vlan * ; *
  rule 7 deny command configure ; interface Vlan* ; description*
  rule 6 permit command configure ; interface Vlan* ; *
  rule 5 permit command configure ; interface Ethernet* ; *
  vlan policy deny
    permit vlan 10-19
  interface policy deny
    permit interface Vlan10-19
    permit interface Ethernet1/3-4
    permit interface Ethernet118/1/1-24
    permit interface Ethernet119/1/5-6
    permit interface Ethernet119/1/10-24

To test the output see below:

RBAC with AAA Authentication

Using RBAC with AAA Authentication instead of relying on local usernames, or using different AAA Authorization profiles, makes way for favorable designs is certain networks. All user accounts are managed centrally on a TACACS server. The TACACS server is also used to assign the nexus user roles (as described in a previous port). Provided the TACACS assigned user roles match local user roles, different command authorization profiles are possible across different device functions using the same TACACS configuration. If the TACACS assigned user role does not match any local user role, the default Network-Operator role will be applied.

Pro’s, Con’s and Limitations

Many might ask why the above solution is required at all, when full AAA can be used. Firstly TAC+ has a limitation of not being able to do device groupings, secondly Config-Sync and AAA Authorization together do not co-operate well with current releases of NX-OS as AAA Authorization blocks system CFSoIP messages used by Config-Sync. A TAC-case for this was logged some time ago, which should hopefully be resolved soon.

When RBAC is used, only the intended and allowed commands are showed in the CLI help (?), which in my opinion removes unnecessary screen clutter and confusion for operational staff. I have found this aids configuration time and leads to less question on NX-OS.

RBAC does not yet make distinction between different configuration modes in NX-OS, “config term” and “config sync”. This lack of distinction bypasses some intended security purposes when using Config-Sync. A feature enhancement request for this was logged with Cisco.

RBAC configuration is local to each Nexus switch, which means this solution is not scalable to hundreds of devices, but this has proved useful in particular networks designs.

I hope this post was informative. :)