topic Re: CLI based Roles/Views in Network Security

CLI based Roles/Views

Scott Cannon — Fri, 21 Feb 2020 12:04:48 GMT

Hi Guys,

I'm trying to configure a view that will allow a user access to do a few mundane tasks such as read the startup conifg, a few show commands, change the terminal settings, etc.

I've configure a view called RO and assigned a few exec commands (see below):

parser view RO
secret 5 $1$m3Iz$ltDKR58NxImIZEEwX/vbV0
commands exec include terminal length
commands exec include terminal
commands exec include show startup-config
commands exec include show

I've also created a user and assigned it to this view

username sc view RO password 0 sc

Now, when I login with the user sc I am unable to move from user mode to privliged mode, I get an access denied error as seen below:

R1>en
Password:
% Access denied

Have I done something wrong? How do I configure the router so that I can create a role with the required commands and assign it to users? I thought I had it down pat but it isnt working.

Any advice you have would be greatly appreciated

TIA

Rgds

Scott

Re: CLI based Roles/Views

Panos Kampanakis — Fri, 10 Sep 2010 14:40:33 GMT

Scott,

Your user probably does have priv level to be in enable mode.

IF he is in priv 15, does it work?

Re: CLI based Roles/Views

Scott Cannon — Mon, 13 Sep 2010 22:34:44 GMT

Hi PK,

Thanks for your input.

If I give the account privilege 15 it works but then the view does not (ie. the account can run all commands). I suspect this is how it should be since priv15 is akin to god-mode access and you shouldnt be able to restrict it. Also means, giving privilege 15 isnt a solution. I've scoured the web with no luck.

Can any one offer further insight into my issue?

TIA

Rgds

Scott

Re: CLI based Roles/Views

Scott Cannon — Mon, 20 Sep 2010 05:20:28 GMT

Hi Guys,

This issue persists. Is anyone able to offer some insight/suggestion on my problem?

TIA

Rgds

Scott

Re: CLI based Roles/Views

wzhang — Fri, 08 Oct 2010 16:45:13 GMT

Hi,

The "Access denied" error comes from aaa authentication, and in theory shouldn't have much to do with role based view access. Does this work if you don't assign the RO view to this user "sc"? Also, if you assign both a parser view and the privilege level to an user, the parser view should take precedence, ie., the users should still only be able to see commands assigned to the view, and not all commands under level 15. To better understand what's going on, could you post your aaa configuration, along with a "debug aaa authen" when it's not working?

Thanks,

Wen

Re: CLI based Roles/Views

Scott Cannon — Tue, 19 Oct 2010 04:44:53 GMT

Hi wzhang,

Thanks for coming back to me on this. The fix for this problem still eludes me.

If I dont assign the RO view to the user and enable it fails authentication (wrong passowrd) If I then manually tell the user to enable (into) the RO view then it works.

If I assign priviledge level 15 to the line the user is automatically logged into exec mode and has access to all commands, regardless of what view is assigned to the user.

I think whats happening is this:

When the view is assigned to the user SC, I login as SC and type enable at the user prompt. Instead of enabling the view assigned to the user (in this case RO) it enables the root view and as such fails authentication. If I manually enable the RO view via enable view RO it works as expected.

I suppose my question now is: How do I change this behaviour so that when a user with a view assigned o them types enable, it moves them into the view assigned to them (and not the root view)?

TIA

Rgds

Scott

Re: CLI based Roles/Views

wzhang — Tue, 19 Oct 2010 14:06:06 GMT

Hi, Scott:

Could you share your aaa configuration? A couple of things to note here:

1. With aaa authorization enabled, when an user logs into the router he should automatically be assigned the view that the user belongs to. You shouldn't have to enable into the view manually.

2. When the user is in the view he/she's assigned to and he/she types "enable", then he will be put into the privileged mode, and not the root view as in the following:

R1#telnet 1.1.1.1

Trying 1.1.1.1 ... Open

User Access Verification

Username: cisco

Password:

R2#sh parser view

Current view is 'MYVIEW'

R2#

R2#enable

Password:

R2#

R2#sh parser view

No view is active ! Currently in Privilege Level Context

R2#

3. You typically don't want to assign privilege levels to the line, but instead you want to do it for the user either through AAA or assign it locally, although with role based CLI access, it's somewhat of a moot point since the commands the user has access to is controlled by the view and not the privilege level.

Thanks,

Wen

Re: CLI based Roles/Views

Scott Cannon — Wed, 20 Oct 2010 04:14:49 GMT

Hi Wen,

See config extract below:

VIEWS_R1#sho run
Building configuration...

Current configuration : 1218 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname VIEWS_R1
!
boot-start-marker
boot-end-marker
!
enable password password
!
aaa new-model
!
!
aaa authentication login default local
aaa authorization exec default if-authenticated
!
!
no ip domain lookup
ip auth-proxy max-nodata-conns 3
ip admission max-nodata-conns 3
!
username sc privilege 15 password 0 abc123
username sc2 view RO password 0 abc123
!
interface FastEthernet0/0
ip address 10.0.0.1 255.0.0.0
duplex auto
speed auto
!
!
line con 0
logging synchronous
line aux 0
line vty 0 4
transport input telnet
line vty 5 14
transport input telnet
line vty 15
transport input telnet
parser view RO
secret 5 $1$E6ex$JrkjcJd94q4vM/QrQL9F31
commands exec include terminal length
commands exec include terminal
commands exec include show startup-config
commands exec include show
!
!
!
end

Note: This config differs slightly from that mentioned in my previous posts. I've had to rebuild it as I lost my test environment. In the above config, the user sc2 is assigned the view RO. I'm doing all this testing in GNS3, happy to upload the configs for you if you prefer.

A difference I have noticed between your output and what I get is that my user "sc2" is not logged into privilged mode. I guess this is because I dont have it set on the vty lines. If I do set it, as already stated, the view doesnt take affect and the user gets all commands available to that priv level.

Heres what I see (I've added the passwords so you can see waht I'm doing):

User Access Verification

Username: sc2 (this user has the RO view assigned to them)
Password: abc123

VIEWS_R1>en
Password: RO (the RO view enable password)
% Access denied

VIEWS_R1>en
Password: password (the root view enable password)
VIEWS_R1#sho parser view
No view is active ! Currently in Privilege Level Context
VIEWS_R1#sho run | i sc2
username sc2 view RO password 0 abc123
VIEWS_R1#

Any idea why my view isnt taking affect?

Rgds

Scott

Re: CLI based Roles/Views

wzhang — Wed, 20 Oct 2010 13:34:18 GMT

Hi, Scott:

I think the problem is that your aaa authorization is not taking effect, thus not putting the user into the parser view assigned to him. With your authorization configuration, if-authenticated means don't authorize if the user is authenticated already. Try changing that to "aaa authorization exec default local" and that _should_ fix it. The reason that my user goes into the privileged mode right away is because I've assigned privilege 15 to the user. But then again, with role based cli access, the parser view should take precedence over the privilege level, so it's somewhat of a moot point. Hope this helps.

Thanks,

Wen

CLI based Roles/Views

Rowell Dionicio — Thu, 11 Oct 2012 12:55:21 GMT

I know this is an old post but I came across the same issue. The way I resolved it is to not have the user do an enable after inputting their credentials. At user mode they need to type:

R1> enable view RO

Password: RO-password

R1#

*Oct 11 05:54:26.523: %PARSER-6-VIEW_SWITCH: successfully set to view 'RO'.

Re: CLI based Roles/Views

SohelJapanwala — Sun, 28 Jan 2024 10:20:07 GMT

Hello,

Please do note that the client or user on which view has to be applied will NOT be using the enable command. Doing so will enable priviledge levels.
Strangely enough, the client / user on whom view is applied will enter the view assigned commands directly in the default mode(user exec) that the user logs in.

#RoleBasedAccessControl #RBAC