861 SSH / Telnet privilege exec level 15 enable not working

[philcisco2]

I have a customer with a 861 ISR.

I want to block all the privilege 0 users from access the enable command

If i telnet into the device, as a priv=0, enable does not work

If i telnet into the device, as a priv=15, enable does work

If i telnet into the device, as a priv=0, enable does not work

If i telnet into the device, as a priv=15, enable does not work

I have issued the command:

privilege exec level 15 enable

Should block everyone except 15's from accessing the enable command

SSH and TELNET are on the same vty:

line con 0

login authentication local_authen

no modem enable

line aux 0

line vty 0 3

login authentication local_authen

transport input telnet ssh

line vty 4

transport input none

!

Basically TELNET is following the rules ( priv=0 not allowed to access enable ) but SSH is not following the rules ( both priv=15 and priv=0 cannot access the command )

Any ideas? this problem is driving me crazy.

Side note:

is there a way from blocking somes users from login in completely?

Thanks!

Thanks!

[cadet alain]

Hi,

Could you post your AAA config as well as your users config.

Telnet is not using user/password but ssh does so the configs from above could help sort out the problem.

Side note: if you want a user not to login just don't configure it in the local database or radius/tacacs server so he won't be able to authenticate.

Regards.

Alain.

[philcisco2]

Hi Alain:

enable secret 5 xxxxxxxxxxxxxxxxxxxxxxx

!

aaa new-model

!

aaa authentication login local_authen local

aaa authorization exec local_author local

aaa authorization network groupauthor local

aaa session-id common

memory-size iomem 10

username vpnuser privilege 0 secret 5 xxxxxxxxxxxxx

username router privilege 15 secret 5 xxxxxxxxxxx

username keller privilege 0 secret 5 $xxxxxxxxxxxxxxx

Not sure what you mean by telnet is not using the user/password?

Thanks again for you help!

[cadet alain]

Hi,

forget about the telnet/ssh it was a stupid remark, in fact you can use telnet without a user/password but ssh requires it but if you've got authentication against user/password then telnet will use it indeed.

That's what happenning when you write stupid things and click send without rereading carefully what you wrote

Now let's talk about your issue:

I don't see any authorization  exec configured on the lines in your previous post but I don't see why it affects only one protocol.

Could you debug aaa authentication as well as debug aaa authorization while doing both.

Regards.

Alain.

[jeffkolbash · Accepted solution]

Your line configuration is set to check the local_authen policy for logging in only.  You will also need a statement that checks users for thier priviledge level .  Try adding thisto your line config:

line vty 0 3

authorization exec local_author

[philcisco2]

ok so adding:

authorization exec local_author

takes me right to priv=15 ( with username router )

take me right to priv=1 ( with username vpnuser )

typing in enable as vpnuser gives me invaild input.. ( perfect! )

I guess what i got hung up on was loggin in as router and having to type enable to get to priv=15

This solution does work.

line vty 0 3

access-class 2 in

authorization exec local_author

login authentication local_authen

transport input telnet ssh

line vty 4

Thanks for all the help.. i can now re-glue all the hair i have pulled out from my head!

[philcisco2]

side note: is there anyway to block vpnuser from logging in all together ( the vpnsuer does need to vpn in via a crypto map ).

Thanks again!!

[jeffkolbash]

HMM... interesting.   

I've never done this but it seems that you could do this by using aaa attributes.  I'm going to test this out in my lab.  It seems that there may be a couple of different ways to achieve the same goal... I will get back to you.

[jeffkolbash · Accepted solution]

phil - It took some digging around but I have been able to prevent the 'vpnuser' from loggin in while still allowing the 'router' and 'keller' users to maintain the appropriate shell privileges.  I do not have the means to test the VPN funtionality.  Perhaps you can post back your results. 

This was accomplished by changing the privilege level of the vpnuser during a shell login to an unacceptable value.  Anythig outside the scope of 0-15 will fail authorization.  in this case it was changed to 666

aaa attribute list NO_SHELL

attribute type priv-lvl 666 service shell mandatory

exit

username vpnuser aaa attribute list NO_SHELL

There are literally hundreds of attributes that can be configured but documentation was difficult to find.  Thesimplest reference that I discovered for your situation was here:

http://inetpro.org/wiki/AAA:_Attributes_for_local_user_database

Hope that helps!

-Jeff

[philcisco2]

Jeff,

Tested it the other day.. works! does not allow the user to login at all

Thanks again!!