Do not allow RADIUS user to enter config mode

[ronit]

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?

[balaji.bandi]

Firewwall different, i will go with Priv 15, and restrict with access authorisation, is that works ?

[andrew.butterworth]

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

[ronit]

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.

[andrew.butterworth]

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

[ronit]

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.

[andrew.butterworth · Accepted solution]

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.

[ronit]

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.

[MHM Cisco World]

...