enter privileged EXEC mode on the ASA console

[wbleiberschnig]

I'd like to enter privileged EXEC mode on the ASA console through TACACS+ and ISE

The login works but when I enter 'enable' the authentication on ISE fails.

The TACACS log on ISE shows that the TACACS protocol contains "Authentication Service -> Enable" instead of "Authentication Service -> Login". Do I have to build an own policy for that?

Regards

Wolfgang

[marce1000]

 - If you are talking about the native console then I discourage this in order to be able to access your device at all times when the surrounding authentication services would be unavailable. Such purposes should be seen as the main goal of the native console (use a local user).

 M.

[wbleiberschnig]

I agree, for this reason serial and enable are configured to use ISE and local user:

aaa authentication serial console ISE LOCAL
aaa authentication enable console ISE LOCAL

[marce1000]

 - Good to hear, but even then with that configuration, it would be wise to check if the culprit does not remain in place, ,,,, (would the fallback actually work, when needed,....)

 M.

[wbleiberschnig]

Yes, of course, I will check if the fallback actually works, but I have to solve the above mentioned problem first.

[marce1000]

 - Have  a look at the below document (link) : I would presume that you just need to configure PermitAllCommands , in the section 

                   Configuring TACACS Command Sets

 https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/200208-Configure-ISE-2-0-IOS-TACACS-Authentic.html#anc11

 M.

[Greg Gibbs]

Hi Wolfgang,

I had a similar question from a recent customer and wanted to share those findings and workarounds here.

Unfortunately, the ASA does not support separate AAA sequence lists (like routers/switches), so there is no way to separate out or exempt command authorization for the serial console. Once the ‘aaa authorization command <list>’ configuration is applied, it will apply to both SSH and Serial console sessions.
In addition, the command ‘auto-enable’ option for the command ‘aaa authorization exec authentication-server auto-enable’ does not apply to the Serial console session (apparently, by design). As such, after authenticating to the Serial console, you must use the ‘enable’ command to gain priv15 access. This compounds the issue because the username associated with the Serial console session changes to ‘enable_15’.
This means that command authorization against the TACACS server will fail because the user ‘enable_15’ is not in the external ID store.
I did some testing in my lab and found the following way to work around this.

1. In ISE, create an internal user called ‘enable_15’. Set a strong password (the password will not actually be used.
2. Create a new Identity Source Sequence (Eg. ‘AD_LOCAL’) that uses both your AD followed by Internal User. Make sure the ‘Treat as if the user was not found…’ radio button is selected.
3. Update the Authentication Policy for your ASA Policy Set to use this new ISS (AD_LOCAL).
4. Create a new AuthZ Policy (Eg. above the default with a matching Condition of ‘Internal User Name EQUALS enable_15’ and the same Command Set and Shell Profile used for Priv 15 access.

This configuration will allow you to configure either ‘LOCAL’ or ‘TACACS+ LOCAL’ aaa authentication on the Serial console as well as the ‘aaa authorization command TACACS+ LOCAL’

There is an additional caveat of which you should be aware for the scenario when the ASA loses connectivity to the TACACS+ servers...
With the ‘aaa authorization command’ configured for either ‘LOCAL’ or ‘TACACS+ LOCAL’, there is a similar issue with command authorization on the serial console after issuing the ‘enable’ command to escalate to priv15 since, as mentioned above, the username changes to ‘enable_15’ (see the output from ‘show curpriv’).
Similar to the above scenario with an ‘enable_15’ internal user on ISE, you can work around this by creating a local ‘enable_15’ user on the ASA with the ‘nopassword’ option.

Example:
username enable_15 nopassword privilege 15

Cheers,

Greg

[RogerAas]

Hi Greg,

Old message now, but I was just working on this specific setup and found out that using the 'aaa authorization command TACACS LOCAL" would check the Tacacs-server for the console users commands also, as you wrote. When not using authentication on the console port the active username is enable_1 at first and when you do an enable command it changes to enable_15, as you stated. This would make commands fail as there is no enable_15 user on the tacacs server.

But I did not need to make an enable_15 user locally or in ISE (or indirectly through AD) to make things work as expected.

Yes, I make a local user with privilege 15 for cases when the connection to the Tacacs-servers are lost, but when I add authentication to the serial port, the ASA will use my Tacacs username when I log in to the console and will keep that username when I do the enable command (because as you say auto-enable does not apply to the console port so no direct level 15 privilege).

So with these aaa commands under here I can use my Tacacs user and password on the console when connection to the tacacs-servers are good, and use the local admin user when the connection is down. And still be able to use the enable command on the console both for the tacacs user and local user.

aaa authentication enable console TACACSISE LOCAL
aaa authentication serial console TACACSISE LOCAL
aaa authorization command TACACSISE LOCAL
aaa authorization exec authentication-server auto-enable

The good thing about this is that I do not need to have a password for an enable_15 user that is known by everyone that need to do work locally on a ASA. Techs use their tacacs username/password on the ASA in normal operation, they only need to get the local admin password if they have lost connection to the tacacs server and need local access.

Roger