A post on techexams.net recently made me look into parser views in more detail.
I read the section in the CCNA: Security Official Certification Guide about them a while back (the entire one page of it), and never really gave it much thought, but I was prompted by the post on the forum to look into them in more detail.
Parser views are a useful way to control exactly what commands a user can use on the device, and are more granular than custom privilege levels.
The first thing that is needed for parser views to work is AAA set up on the router (or switch or whatever, but I’m using a router).
R1#conf t
R1(config)#aaa new-model
R1(config)#aaa authentication login default local
R1(config)#aaa authorization exec default local
Not only do you have to turn AAA on, you have to enable authentication and authorization, otherwise IOS won’t automatically put a user into a view when they log in.
Next, an enable secret must be configured.
R1(config)#enable secret cisco
And then, before configuring any views, you must enter the root view.
R1(config)#exit
R1#enable view
Password:
Now all the preliminary stuff is taken care of, it’s time to create a custom parser view. Although the scenario’s I’m going to use aren’t realistic, they will serve to prove the capabilities of parser views. First, we have an “interface technician” – his job is to configure the interfaces.
R1(config)#parser view INTERFACE_TECH
R1(config-view)#
*Mar 1 00:04:24.351: %PARSER-6-VIEW_CREATED: view 'INTERFACE_TECH' successfully created.
R1(config-view)#secret cisco
R1(config-view)#commands configure include all interface
R1(config-view)#commands exec include configure terminal
So there’s a view, called INTERFACE_TECH. The first thing that has to be done, before anything else, it to create a secret for that view. Clearly, that has to be “cisco”!
Next, we have assigned all interface sub configuration commands to the view. The keyword “configure” means that we are looking at commands that would be entered from configuration mode. “include all” is as specified in the following table, found here: Cisco IOS Security Command Reference
include Adds a specified command or a specified interface to the view and allows the same command or interface to be added to a view. include-exclusive Adds a specified command or a specified interface to the view and excludes the same command or interface from being added to all other views. exclude Denies access to commands in the specified parser mode. Note: This keyword is available only for command-based views. all (Optional) A “wildcard” that allows every command in a specified configuration mode that begins with the same keyword or every subinterface within a specified interface to be part of the view.
The final command refers to commands that are allowed in “exec” mode – this is just “configure terminal” – as otherwise the tech couldn’t enter configuration mode!
Interestingly, when you look at this in the running-config, it looks like this:
R1#sh run | s parser
parser view INTERFACE_TECH
secret 5 $1$PD72$5k9/McCP4Ak3NEQsdKU0o/
commands configure include all interface
commands exec include configure terminal
commands exec include configure
The extra line is because “configure terminal” is a sub-command for “configure”…if you don’t have access to “configure” then you wouldn’t be able to use it, so IOS adds it in for you.
Next I’ll apply that to a user account…
So now I’ll create a user account that uses that parser view. I could just test it by entering “enable view INTERFACE_TECH” from exec mode, but that would be no fun.
R1(config)#username interfaceguy view INTERFACE_TECH secret cisco
If I telnet into myself and log in as interfaceguy, I get this:
R1#?
Exec commands:
<1-99>Â Â Â Â Â Session number to resume
configure  Enter configuration mode
credential load the credential info from file system
enable     Turn on privileged commands
exit       Exit from the EXEC
show       Show running system information
parser Show parser commands
R1#
This user can’t do anything! But, that’s what we wanted. Just to verify:
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#?
Configure commands:
do        To run exec commands in config mode
exit      Exit from configure mode
R1(config)#int fa0/0
R1(config-if)#?
Interface configuration commands:
access-expression      Build a bridge boolean access expression
arp                    Set arp type (arpa, probe, snap) or timeout or log
options
auto                   Configure Automation
backup                 Modify backup parameters
bandwidth              Set bandwidth informational parameter
bgp-policy             Apply policy propagated by bgp community string
bridge-group           Transparent bridging interface parameters
carrier-delay          Specify delay for interface transitions
cdp                    CDP interface subcommands
channel-group          Add this interface to an Etherchannel group
clns                   CLNS interface subcommands
.........etc
So as planned, interfaceguy can do everything under interface configuration mode, but not much else.
Now I’ll add my routerguy and my showguy – one configures routing protocols and one can do show commands. Unrealistic, I know – but it serves a purpose.
parser view ROUTER_TECH
secret 5 $1$V0j4$GMnkVte/zKiDtecjLeCOE/
commands configure include all router
commands exec include configure terminal
commands exec include configure
!
parser view SHOW_TECH
secret 5 $1$9G2s$rFilAS6WS.I3SNJjoS4Jd.
commands exec include all show
username routerguy view ROUTER_TECH secret 5 $1$yx//$UuvVaeFXqQinLfukb1QOq1
username showguy view SHOW_TECH secret 5 $1$y.jc$t2jUVxMZr9T.Jdg07ss9F1
A quick test confirms that routerguy can do nothing in exec mode but can enter config mode and configure anything under “router”. showguy can’t enter config, but can do all show commands.
OK, so I have interfaceguy, routerguy and showguy all working as planned. A new guy starts the company, and he’s a genius. He knows how to configure routing protocols AND interfaces! (He’s useless with show commands though, so we’ll not allow that).
Now, if you use the context help when creating a user account it will lead you to believe that you can have multiple views associated with a user:
R1(config)#username geniusguy view INTERFACE_TECH ?
aaa                 AAA directive
access-class        Restrict access by access-class
autocommand         Automatically issue a command after the user logs in
callback-dialstring Callback dialstring
callback-line       Associate a specific line with this callback
callback-rotary     Associate a rotary group with this callback
dnis                Do not require password when obtained via DNIS
nocallback-verify   Do not require authentication after callback
noescape            Prevent the user from using an escape character
nohangup            Do not disconnect after an automatic command
nopassword          No password is required for the user to log in
one-time            Specify that the username/password is valid for only one
time
password            Specify the password for the user
privilege           Set user privilege level
secret              Specify the secret for the user
user-maxlinks       Limit the user's number of inbound links
view                Set view name
 <cr>
R1(config)#$niusguy view INTERFACE_TECH view ROUTER_TECH secret cisco
R1(config)#do sh run | i username genius
username geniusguy view ROUTER_TECH secret 5 $1$Q4GG$IEWFvAPAcUlvmZGyoEB0q/
R1(config)#
I personally think this is very misleading. As you can see, the context help invited me to enter a second view, and the command was accepted with no errors. However, when you look at the running config, the only view is the LAST ONE THAT WAS ENTERED.
So how am I going to assign two views to the user? Enter the superview.
We can create a superview, which contains multiple views, then assign that to a user, like this:
parser view GENIUS_TECH superview
secret 5 $1$t0QA$VWtaAt2EYmBWQDgySPdb8/
view INTERFACE_TECH
view ROUTER_TECH
username geniusguy view GENIUS_TECH secret cisco
It’s actually worth noting here that if you try and use an invalid view name here, it will throw an error:
R1(config-view)#view TEABARGUY
% Invalid view name TEABARGUY
There will be no such error if you assign an invalid view to the user; instead, the user will just be dumped into priv level 1 with no view.
For completeness, here is the output from geniusguy’s login:
R1#telnet 10.0.0.1
Trying 10.0.0.1 ... Open
User Access Verification
Username: geniusguy
Password:
R1#?
Exec commands:
<1-99>Â Â Â Â Â Session number to resume
configure  Enter configuration mode
credential load the credential info from file system
enable     Turn on privileged commands
exit       Exit from the EXEC
show       Show running system information
R1#sh ?
parser Show parser commands
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#?
Configure commands:
do        To run exec commands in config mode
exit      Exit from configure mode
interface Select an interface to configure
router    Enable a routing process
Exactly as intended.
The only other point that I found interesting is that this doesn’t apply to the console port:
R1 con0 is now available
Press RETURN to get started.
User Access Verification
Username: routerguy
Password:
R1>sh priv
Current privilege level is 1
R1>sh parser view
No view is active ! Currently in Privilege Level Context
R1>
This is because aaa new-model by default only applies authentication to the console line and not authorization. To rectify this, type:
aaa authorization console
Thanks for reading, hope it’s useful!
