Role Based Access Control in IOS

I don’t believe this is well known: Cisco IOS has Role Based Access Control (RBAC) which can be used to create and assign different levels of privileged access to the device. Without RBAC there are two access levels in IOS: a read-only mode with limited access to commands and no ability to modify the running config (also called privilege level 1) and enable mode with full administrative access. There is no middle ground; it’s all or nothing. RBAC allows creation of access levels somewhere between nothing and everything. A common use case is creating a role for the first line NOC analyst which might allow them to view the running config, configure interfaces, and configure named access-lists.

A “role” in IOS is called a “view” and since views control which commands are available in the command line parser, they are configured under the parser. A view can be assigned a password which allows users to “enable” into the view. More typically, the view is assigned by the RADIUS/TACACS server as part of the authorization process when a user is logging into the device.

A view is configured with the “parser view <view-name>” config command after which commands are added/removed to/from the view.

(config)# parser view <view-name>
(config-view)# commands <cmd-context> { include | exclude |
                    include-exclusive } [all] <command>
  • <cmd-context> – Indicates which CLI mode the <command> is allowed in. Eg, “exec”, “configure”, “interface”.
  • include – includes the <command> in the view
  • exclude – excludes the <command> from the view
  • include-exclusive – makes <command> exclusive to this view and not usable by other views
  • all – enables use of all sub-commands of <command> (see example below)

A password can be assigned to the view by using the “secret” command:

(config-view)# secret <password>

To manually test a view, log in to the device and use the command “enable view <view-name>”. This will place your session in the view with access only to those commands included in the view. You can always confirm which view you’re in by using the “show parser view” command. For what it’s worth, there is a default view called “root” which is the equivalent to enable level access.

Here’s an example of a view for the NOC users that allows viewing the running config, configuring interfaces, and configuring named access-lists:

parser view NOC
 secret 5 $1$TDy.$kquP9EdEYGJ0.oQE3cJaN.
 commands configure include all ip access-list
 commands configure include all interface
 commands configure include ip
 commands exec include configure terminal
 commands exec include configure
 commands exec include show running-config
 commands exec include show

A few things of note:

  • The command “commands exec include show” is automatically added to the config in order to allow the user to run “show running-config”. Same with “configure” and “ip”; each element of the command is added separately, it’s just how the parser works
  • In order to allow the user to shut/no shut an interface, they first have to be allowed to get into config mode, then allowed to get to interface config mode. The relevant commands are included in the view.
  • The “all” option is specified on the “ip access-list” and “interface” lines. Without “all”, the parser would be expecting the user to run “ip access-list” as a literal command. However there is no such command. Real commands are things like “ip access-list standard BLOCK_STUFF”. The “all” option allows all subcommands of “ip access-list” and all interfaces after the command “interface”.

Now to test it. In this example, I’m not using RADIUS or TACACS and instead will manually enable into the view.

R12>enable view NOC
Password:

R12#show parser view
Current view is 'NOC'

One of the first things to see once you’ve taken on a view is that the context-sensitive help will only show the commands that you have access to run:

R12#?
Exec commands:
  <1-99>      Session number to resume
  configure   Enter configuration mode
  credential  load the credential info from file system
  do-exec     Mode-independent "do-exec" prefix support
  enable      Turn on privileged commands
  exit        Exit from the EXEC
  show        Show running system information

Things work smoothly though and we can configure a new ACL and apply it to an interface.

R12#config t
Enter configuration commands, one per line.  End with CNTL/Z.
R12(config)#ip access-list extended BLOCK_STUFF
R12(config-ext-nacl)#deny tcp any any eq 23
R12(config-ext-nacl)#permit ospf any any
R12(config-ext-nacl)#permit ip any any
R12(config-ext-nacl)#interface e1/0
R12(config-if)#ip access-group BLOCK_STUFF in
R12(config-if)#^Z

However when we look at the running config, the view restricts the output to only those areas of the config that we’re allowed to configure. In this case, we can see interfaces and named ACLs.

R12#show run
Building configuration...

Current configuration : 2747 bytes
!
! Last configuration change at 20:35:30 MST Thu Mar 12 2015 by admin
!
!   <<<
!   <<< normal stuff like AAA, enable secret, hostname, etc, not shown
!   <<<
!
!
interface Loopback0
 ip address 10.1.12.12 255.255.255.0
 ipv6 address 3000:10:1:12::12/128
[...]
ip access-list extended BLOCK_STUFF
 deny   tcp any any eq telnet
 permit ospf any any
 permit ip any any

More information:

Disclaimer: The opinions and information expressed in this blog article are my own and not necessarily those of Cisco Systems.

5 thoughts on “Role Based Access Control in IOS”

    1. Hi Erjol,

      Not sure I understand your question. In the view above, all interfaces are part of the view by way of this command:

      commands configure include all interface

      This allows all interfaces to be configured, subject to whatever other interface subcommands are permitted in the view.

      1. Hi Joel,
        correct, but that command includes all interfaces: vlan. gig, fastether.

        what i want is to include, for example, only this range gig1/0/1 – 48 and nothing else. that’s because i have some switches which are in stack and adding them manually would really take a long time.

        thanks.

        1. Oh ok, that makes more sense. As far as I can see, the CLI based RBAC cannot handle regex or wildcards so you would not be able to allow access to only some interfaces and not others.

          You’d have to look at AAA and command authorization. For example, ISE will allow wildcards and regex when creating command authorization rules. Check out fact #4 in this post: https://www.packetmischief.ca/2015/11/10/five-functional-facts-about-tacacs-in-ise-2-0/

Leave a Reply

Your email address will not be published. Required fields are marked *

Would you like to subscribe to email notification of new comments? You can also subscribe without commenting.