01-13-2012 02:32 AM - edited 03-10-2019 06:43 PM
Hello!
We have ASA configured in multi context mode, with software 8.4(2) configured for AAA
Configuration is admin context as follows:
aaa-server TAC protocol tacacs+
aaa-server TAC (management) host 10.162.2.201
key *****
aaa authentication enable console TAC LOCAL
aaa authentication http console TAC LOCAL
aaa authentication serial console TAC LOCAL
aaa authentication ssh console TAC LOCAL
Because of multiple context, after logging in we enter System context. Console port authentication is working fine except access to privileged mode while connecting over console port.
After issuing "enable" command ASA accepts only configured enable secret in system context and changes user ID to enable_15, so we are unable to do user-level command authorization and accounting.
It seems that ASA in system context is not aware of any AAA configuration, and there isn't any command to configure AAA in system context.
Is there any way to configure enable authentication over AAA in system context?
Thanks in advance!
Solved! Go to Solution.
01-16-2012 02:51 PM
Hello,
It seems that you are hitting the following known issue:
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. |
Hope this clarifies it. Unfortunately there is no fix yet for this behavior.
Regards.
01-17-2012 07:02 AM
Hello,
I am glad that the workaround worked for you. If you feel that the accurate answer was provided please mark the thread as answered for future reference for our Community members.
Regards.
01-16-2012 02:51 PM
Hello,
It seems that you are hitting the following known issue:
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. |
Hope this clarifies it. Unfortunately there is no fix yet for this behavior.
Regards.
01-17-2012 02:14 AM
Hi
Thanks for the info.
I have used the refred workarround
Thanks for the info
01-17-2012 07:02 AM
Hello,
I am glad that the workaround worked for you. If you feel that the accurate answer was provided please mark the thread as answered for future reference for our Community members.
Regards.
02-24-2021 04:27 AM - edited 02-24-2021 04:43 AM
That link above is currently returning:
No server is available to handle this request.
Updated URL: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCsw18455
Wow it has been almost 10 years, and this hasn't been addressed and:
"No release planned to fix this bug"
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