01-24-2020 12:56 AM
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
01-24-2020 01:41 AM
- 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.
01-24-2020 01:45 AM
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
01-24-2020 01:51 AM
- 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.
01-24-2020 02:03 AM
Yes, of course, I will check if the fallback actually works, but I have to solve the above mentioned problem first.
01-24-2020 02:26 AM
- Have a look at the below document (link) : I would presume that you just need to configure PermitAllCommands , in the section
M.
02-04-2020 07:45 PM
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.
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
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