11-15-2021 02:49 AM
Using Firepower with ASA code. I would like some users to not enter config mode on the firewall. We have RADIUS with privilege level 7, which cannot enter config mode on routers on switches. But the same users can enter config mode (and make changes) on the firewalls.
Does the privilege setup work differently on firewalls?
Is there an easy way to restrict priv level 7 users out of config mode on firewalls?
Solved! Go to Solution.
11-16-2021 05:09 AM - edited 11-16-2021 05:55 AM
What is your RADIUS server sending for the 'Service-Type' attribute? It needs to be 'Administrative'.
I've just done some testing and the 'shell:priv-lvl=x' is ignored if the 'Service-Type' attribute is not set to 'Administrative'. My NPS policy for level-15 users is configured to send Service-Type=Administrative, however the level-7 one was set to Service-Type=NAS-Prompt.
This is what I get now when I login:
Z:\>ssh -l priv-1 ciscoasa.xxx.xxx priv-1@ciscoasa.xxx.xxx's password: Type help or '?' for a list of available commands. ciscoasa/actNoFailover/pri# conf t ^ ERROR: % Invalid input detected at '^' marker. ERROR: Command authorization failed ciscoasa/actNoFailover/pri#
However it appears sending Service-Type=Administrative to my IOS/IOS-XE devices now makes them ignore the shell:priv-lvl=x and they use the Service-Type=Administrative to set privilege 15. If I set the Service-Type=Login or NAS-Prompt then the priv-lvl=x is used, however that then breaks the ASA behaviour.
Looks like separate NPS/Radius policies are needed to achieve the desired behaviour.
11-15-2021 03:12 AM
Firewwall different, i will go with Priv 15, and restrict with access authorisation, is that works ?
11-15-2021 03:27 PM
Assuming you are running 9.2(1) or later you can use the AAA global config 'aaa authorization exec authentication-server auto-enable', however your RADIUS Server needs to send the av-pair 'shell:priv-lvl=7'. You might also need to change the privilege level of some commands with the global config 'privilege clear/cmd/show/clear/level'
HTH
Andy
11-15-2021 05:30 PM
Andy,
Thanks. I do have this command in my config, however, a user with "shell:priv-lvl=7" can still enter config mode. The same user cannot enter config mode on a router or a switch. I tried lowering the privilege level to 5, same behaviour.
About the "privilege clear" command, that works, but I don't want to block individual commands from being executed. I want the user to not enter the config mode at all, which I can't seem to accomplish with this command.
11-16-2021 01:58 AM
That's not the behaviour I get with my configuration. I have two policies on my Windows NPS RADIUS servers - one pushes priv-lvl=15, the other priv-lvl=1. If a user enters 'enable' and their password the RADIUS server returns the same AV pairs so is denied. You cannot enter 'enable 15' as its not allowed.
ciscoasa/actNoFailover/pri> enable Password: ******** [ priv-1 ] You do NOT have Admin Rights to the console ! Password: Password: Access denied. ciscoasa/actNoFailover/pri> enable 15 Enabling to privilege levels is not allowed when configured for AAA authentication. Use 'enable' only. ciscoasa/actNoFailover/pri>
My AAA configuration looks like this:
aaa authentication telnet console NPS-Servers LOCAL aaa authentication enable console NPS-Servers LOCAL aaa authentication ssh console NPS-Servers LOCAL aaa authentication http console NPS-Servers LOCAL aaa authorization command LOCAL aaa accounting enable console NPS-Servers aaa accounting serial console NPS-Servers aaa accounting ssh console NPS-Servers aaa accounting telnet console NPS-Servers aaa authorization exec authentication-server auto-enable
Andy
11-16-2021 02:20 AM
Thanks, priv-lvl=1 is not a problem for us. It works as expected on the firewalls. We have 3 levels
priv-lvl=15 : Admin : Works fine on Routers, Switches and Firewalls
priv-lvl=7 : Operator : On Routers and switches, the Operator can enter enable mode, but cannot enter config mode. But on Firewalls, the behaviour is identical to 15
priv-lvl=1 : Guest : Works as expected on Routers and Firewalls. Guest cannot enter enable mode.
11-16-2021 05:09 AM - edited 11-16-2021 05:55 AM
What is your RADIUS server sending for the 'Service-Type' attribute? It needs to be 'Administrative'.
I've just done some testing and the 'shell:priv-lvl=x' is ignored if the 'Service-Type' attribute is not set to 'Administrative'. My NPS policy for level-15 users is configured to send Service-Type=Administrative, however the level-7 one was set to Service-Type=NAS-Prompt.
This is what I get now when I login:
Z:\>ssh -l priv-1 ciscoasa.xxx.xxx priv-1@ciscoasa.xxx.xxx's password: Type help or '?' for a list of available commands. ciscoasa/actNoFailover/pri# conf t ^ ERROR: % Invalid input detected at '^' marker. ERROR: Command authorization failed ciscoasa/actNoFailover/pri#
However it appears sending Service-Type=Administrative to my IOS/IOS-XE devices now makes them ignore the shell:priv-lvl=x and they use the Service-Type=Administrative to set privilege 15. If I set the Service-Type=Login or NAS-Prompt then the priv-lvl=x is used, however that then breaks the ASA behaviour.
Looks like separate NPS/Radius policies are needed to achieve the desired behaviour.
11-16-2021 05:08 PM
Thanks. I cannot reproduce this using FreeRadius. My current Service-type is set as "Nas-Prompt-User". If I change it to "Administrative", login fails completely on the ASA, and as you said, all accounts login as Admin on routers/switches.
On FreeRadius, the replies are linked directly to groups, cannot be separated by policies/subnets. However, we do have plans to migrate to NPS in the future and will try it there.
Meanwhile, I will go with restricting individual commands for Privilege Level 7, which is a pain but is the only option left.
11-16-2021 05:01 AM - edited 11-17-2021 02:33 AM
...
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide