cannot get to privileged enable mode via console

[kewwa]

After searching through other posts, my config seems OK but still strange behaviour
asa 9.20 running on FPWR chasis

I cannot get in enabled mode when connecting to ASA via console.
It used to work but stopped after I played (disable and restore) with aaa authentication LOCAL vs remote setting.

Tests done: tried console and telnet for comparison; telne - no problem, console: get stuck with the >

1. local password test

with these settings
/admin# sh run aaa
aaa authentication http console RADIUS LOCAL
aaa authentication ssh console RADIUS LOCAL
aaa authentication enable console LOCAL
aaa authentication serial console LOCAL
aaa authentication telnet console LOCAL
aaa local authentication attempts max-fail 3
no aaa authentication login-history

and locally configured user
telnet: OK, enable - OK
console: NOK
%Login failed
and the low privilege prompt from the firewall (ASA)
ciscoasa>

I tried one after another 
>en 
> login
> exit and again login
all failures. For the login I mange to loging as far as the initial prompt

2. Remote authentication does not work either
I tested with aaa authentication and authorisation debug on and the radius debug
Only radius debug output but not when trying to en on the console:

with these settings

admin# sh run aaa
aaa authentication http console RADIUS LOCAL
aaa authentication ssh console RADIUS LOCAL
aaa authentication enable console RADIUS LOCAL
aaa authentication serial console RADIUS LOCAL
aaa local authentication attempts max-fail 3
no aaa authentication login-history

prompt on console
hostname>
---no radius debug
exit (logoff) and prompt to login
Username (radius user)
<<<<<<<there is a radius debug output; user priv15
>en
radius password - Invalid password
enable local - Invalid password
<<<<<<<there is NO radius debug output

telnet:
prompt: OK
en: OK
in both cases radius debug output

There is no authorisation setting

the closest issue was described here
https://community.cisco.com/t5/network-security/unable-to-go-to-enable-mode-of-asa-via-console/td-p/2469186
but did not help
I tried the 
aaa authorization exec authentication-server auto-enable described here 
https://www.cisco.com/c/en/us/td/docs/security/asa/asa-cli-reference/A-H/asa-command-ref-A-H/aa-ac-commands.html#wp6184732320:~:text=the%20AAA%20configuration.-,aaa%20authentication%20console,-To%20authenticate%20users

But it did not bring any effect - even for the ssh, which I had always authed by RADIUS

I have not configured any other authorization as I did not want to log myself out and reload in nor manual reload would not be handy as it is cluster so there would be need to do it simmultaneously
Looking at the snippets here:
https://community.cisco.com/t5/network-security/aaa-for-serial-login-in-asa/td-p/4057264
I guess I miss the 
aaa authori command RADIUS LOCAL,
However I do not really think I need any authorization for my setup to work.
The reason I touched it was to make the login go directly to priviledged mode. Which did not happen

Any hint will be appreciated

[MHM Cisco World]

Add new user (not found in radius) abd give it privilege 15' sure you need to access via telnet 

Then try access to console.

And friend later dont use fallback for console access' use only local user db.

MHM

[kewwa]

I used a local user in the first try. It had priv15 and was not existing in RADIUS
There was no fallback in the config
aaa authentication enable console LOCAL
aaa authentication serial console LOCAL
The telnet was just to have a point of reference if local user works - and it worked


The goal is actually to have all aaa Radius because if I have ssh auth by Radius and en by LOCAL, it will not work.

[MHM Cisco World]

This what you share 

admin# sh run aaa
aaa authentication http console RADIUS LOCAL
aaa authentication ssh console RADIUS LOCAL
aaa authentication enable console RADIUS LOCAL
aaa authentication serial console RADIUS LOCAL
aaa local authentication attempts max-fail 3
no aaa authentication login-history

If there is issue with radius or the radius send reject not unknown user then sure the access will deny by ASA.

That why I mention that dont use same username in local and radius 

MHM

[kewwa]

This is the second test.
the first one is in the point 1. of my initial description - I tried to do LOCAL which does not work either (it is not my target config, but it was a test which failed as well)

In the second test - with a RADIUS, the Radius does not send any reject - I did a packet capture, only accept
What is strange is that if I login via console (forced logon) The first login is successfull, the radius debug on asa shows sending the auth request and gets accept and I end up with firewall> prompt. In the second step I type "en" and am prompted for a password but after typing in there is no more debug information as if ASA did not bother to send the auth request to radius
The result is "auth failed" 

[MHM Cisco World]

If this is lab then try below

aaa authorization exec RADIUS local 

It seem to me issue with exec

If this is not lab' please mention that to make me try suggestion before you in my lab.

MHM

[MHM Cisco World]

Use exec and since you use enable auth let radius check each user, auto-enable meaning you dont need anymore enable auth.

MHM

[tvotna]

@kewwa, Do you use multiple mode or single mode? What kind of firepower is this?

In case of multiple mode, if you login via serial console, "enable" never sends request to RADIUS from the system execution space, no matter what you configured in the "aaa authentication enable console ...". It always uses "enable password" configured in the system execution space, if "enable" is run from the system (and context "enable password" if it is run from the context). Likewise, "login" from the system execution space always uses locally configured "username"s. This is little bit confusing, because for the initial serial console login "admin" context settings are used, i.e. RADIUS or TACACS+ or LOCAL, depending on the admin context configuration ("aaa authentication serial console ..."). There is a caveat here too: privilege level is never assigned during initial login to serial console. If you login via serial console, it is recommended to run "login" command afterwards (which will ask for a username and a password again) and not use "enable". The reason is: "enable" will change username to "enable_15" which may not be what you want (details omitted due to complexity and dependency on software versions).

NB. 1. I don't know if anything was changed in 9.20. 2. I honestly don't remember how things work in single mode. Should be similar.

The recommended config is:

aaa authentication serial console LOCAL
aaa authentication enable console LOCAL
aaa authentication ssh console <ext-server> LOCAL
enable password ...
username <local-admin> password ... privilege 15
aaa authorization exec authentication-server auto-enable

To assign privilege level during ssh/telnet login RADIUS should return Service-Type(6) = Administrative. TACACS+ should return priv-lvl=15.

To troubleshoot use "debug aaa ..." (with options - determine by trial and error), "show curpriv" and RADIUS capture.

HTH

[Aref Alsouqi]

You are right, the service type 6 would be used to allow administrative accesses to the firewall. However, and I'm not sure if this works only on the IOS devices, with RADIUS we can still push the "priv-lvl=15" value over RADIUS as you can see in my post link below.

Privilege Level 15 with Cisco ISE | Blue Network Security (bluenetsec.com)

Also, I think we still can do the "enable" authentication via RADIUS, in fact on a Cisco U ISE training I remember going through a scenario where it was showing an example of ISE configuration where the enable authentication rule is configured, but I can't remember if I ever tested that myself.

[tvotna]

@Aref Alsouqi, maybe priv-lvl=15 Cisco VSA can also be used, but the most natural way to control user privileges with RADIUS is the standard RADIUS attribute Service-Type: 6 - "administrative" (privileged), 7 - "nas-prompt" (unprivileged) and 5 - "outbound" or "remote-access" (no access to CLI). This is inline with ASA CLI:

username cisco attributes
 service-type {admin | nas-prompt | remote-access}

Of course, enable authentication can be performed via RADIUS too and you're correct that user must enter his own password (not a separate enable password) in response to enable prompt. (This is helpful if auto-enable authorization is not configured for some reason and the user is not assigned privilege level during login). The RADIUS behavior is different from TACACS+ where enable password for the user is configured separately on the TACACS+ server. What I meant in my previous post is that serial console is special (in multiple context mode if user logged on via serial console, "enable" command doesn't even try to contact external authentication server and that is why "debug radius" is empty. See below for a bug id which has never been fixed.

Also, if RADIUS login authentication is configured, the user logs in via telnet or ssh and RADIUS server returns anything but 6, subsequent "enable" command fails even though RADIUS sends back Access-Accept. This makes sense, because the user has been restricted to unprivileged "NAS prompt" during initial RADIUS authentication.

CSCsw18455 admin context enable mode credentials compared to system context DB
Symptom: In multi-mode configuration, user credentials for entering privileged mode (enable mode) via serial console are not sent to external server for authentication purpose. Conditions: ASA/PIX is in multi-mode. serial console and enable console authentication are configured to use external aaa server in admin context. Workaround: Option 1: Configure enable password in system context. Option 2: Avoid the use of the serial console interface and rely on telnet or ssh console access. From ssh or telnet consoles, attempts to enter enabled mode will be authenticated as specified by the aaa configuration in the "admin" context. Further Problem Description: When authentication is enabled for serial console and for enable console in admin context via an external aaa server(eg: tacacs+ or radius), serial console authentcation is done against external aaa server, but enable mode credentials are compared against enable db in system context.

CSCsz93058 System Context only allows local enable password
Symptom: Enable authentication in the system context can only use local the local enable password. It should be able to be authenticated against AAA. Conditions: ASA 8.1 ASA 8.2 Multi-Context mode. Workaround: None if the serial console is used, the local enable password must be used in the system context. If the ssh or telnet consoles are used, attempts to enter enabled mode will be authenticated as specified by the aaa configuration in the "admin" context. Further Problem Description: This is an enhancement request to have aaa enable authentication added to the system context. When logging in via the serial console the username/password can already be authenticated against an aaa server.

[tvotna]

Documentation:

The RADIUS IETF service-type attribute, when sent in an access-accept message as the result of a RADIUS authentication and authorization request, is used to designate which type of service is granted to the authenticated user

The RADIUS Cisco VSA privilege-level attribute (Vendor ID 3076, sub-ID 220), when sent in an access-accept message, is used to designate the level of privilege for the user.

So, this appears to be legacy Altiga VSA (as you remember, the company which developed entire RA VPN technology which was ported to ASA 7.0 when the company was acquired by Cisco), although documentation can be obsolete.

[Aref Alsouqi]

I'm with you now @tvotna, thanks for the clarification.

[Aref Alsouqi]

One thing to keep in mind when you enable the enable aaa authentication with the command "aaa authentication enable console" is that with that command applied the enable password the users need to type in is going to be their own passwords, not the global enable password/secret you configured on the ASA. However, when that command is not applied, then all the users would need to type in the global enable password.

Also, as you mentioned, the authorization command is not required in your case because the ASA by default allows the exec authorization, this is why the users are placed into the user mode (>) when they logged in. Another thing is that with RADIUS both authentication and authorization are combined into a single call, no separate transaction for authorization. A common use case of using the authorization command would be if you want the users to be placed into privilege 15 after they logged in, you can use the authorization command with the keyword "auto-enable" as you showed in your original post.

One thing you can do to trying to find out the issue is to connect with an SSH session to the firewall, and then trying to console into it and see what logs get generated.

[kewwa]

Not exactly but the hint about the global/system context password helped to solve my issue

Indeed I am using the context mode and the en password for the en on the console in the system context enable password and that one works
Even if I have RADISU authentication, the login is with the radius account, however to get to enable mode I need to give the enable password configured in the system. Now it works.

Thank you all for the discussion that helped to solve my issue

My working setup is:
# sh run aaa
aaa authentication http console RADIUS LOCAL
aaa authentication ssh console RADIUS LOCAL
aaa authentication enable console RADIUS LOCAL
aaa authentication serial console RADIUS LOCAL
aaa local authentication attempts max-fail 3
no aaa authentication login-history

to login in a console:
Login: my radius user (to be clear: it is a different user name than any of the locally configured users)
Password: Radius user password
> en
enable password configured in a system
(Out of curiosity I also tested the radius password and the enable password configured in the admin context and neither of them worked)

This also explains why there were no radius requests sent from asa  when trying to use the radius password for the "enable".

No authorization was needed 

As additional out-of-curiosity test I configured:
# sh run aaa
aaa authentication http console RADIUS LOCAL
aaa authentication ssh console RADIUS LOCAL
aaa authentication serial console RADIUS LOCAL
aaa local authentication attempts max-fail 3
no aaa authentication login-history
(no enable configuration)
It does not have effect on my login via console. It just does not allow me to go to enable mode after I login with my radius user. Neither Radius, no enable global password work

[MHM Cisco World]

debug aaa common 255 <<- share this, and note disable debug after end

MHM