08-11-2011 11:41 AM - edited 03-04-2019 01:15 PM
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!
Solved! Go to Solution.
08-11-2011 02:25 PM
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
08-11-2011 10:59 PM
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
08-11-2011 12:32 PM
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.
08-11-2011 01:59 PM
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!
08-11-2011 02:17 PM
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.
08-11-2011 02:25 PM
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
08-11-2011 02:38 PM
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!
08-11-2011 02:39 PM
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!!
08-11-2011 06:44 PM
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.
08-11-2011 10:59 PM
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
09-22-2011 08:16 AM
Jeff,
Tested it the other day.. works! does not allow the user to login at all
Thanks again!!
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: