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

Hi Guys,

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

TIA

Rgds

Scott

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

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

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#

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

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