Hello StackOverflow community,

I am currently encountering issues with accessing the enable mode through the CLI on an ASA (Adaptive Security Appliance Version 9.18(4)29), even though the ASDM is functioning correctly. This issue persists despite having enabled TACACs-based authentication for ASDM, SSH, and HTTP. I have configured the ASA as specified, but the transition to enable mode over the CLI presents significant challenges.

The detailed ASA configurations are as follows:

aaa authentication http console ISE LOCAL
aaa authentication ssh console ISE LOCAL
aaa authentication enable console ISE LOCAL
aaa authentication serial console LOCAL
aaa authorization exec authentication-server auto-enable
aaa authentication login-history

In the TACACS logs of the Cisco ISE, the authorization policy indicates a “Pass”; however, the ASA log entries suggest underlying issues.

I utilized the above ASA configurations expecting seamless authentication and authorization transitions across all access methods, particularly for transitioning into the CLI’s enable mode. According to the Cisco ISE TACACS logs, the authorization for the user appears successful with status “Pass”. However, the ASA logs tell a different story, indicating failed attempts due to supposed lack of administrative rights:

Jun 10 2024 15:21:52 w : %ASA-6-113004: AAA user authorization successful: server = 10.100.10.150 : user = [USERNAME REDACTED]
Jun 10 2024 15:21:52 gw : %ASA-6-113008: AAA transaction status ACCEPT: user = [USERNAME REDACTED]
Jun 10 2024 15:21:52 gw : %ASA-3-113021: Attempted console login failed, user '[USERNAME REDACTED]' did NOT have appropriate Admin Rights.
Jun 10 2024 15:21:52 gw : %ASA-6-302014: Teardown TCP connection 2640 for management:10

Additionally, I created a profile in “Work Centers > Device Administration > Policy Results > TACACS Profiles” with attributes priv-lvl=15, max_priv_lvl=15, idletime=15. Despite these settings, the ASA debug logs reveal these attributes are not being successfully communicated:

Received TACACS packet. Session id:********  seq no:2
tacp_procpkt_author: PASS_ADD
tacp_procpkt_author: PASS_REPL
Attributes = cisco-av-pair
Attributes = idletime
Attributes = priv-lvl
TACACS Session finished. Session id: **, seq no: 1

My expectation was that the settings would directly reflect in enabled sessions with full privileges, which has not been the case, based on the debug logs and failed login attempts. Could anyone provide insights or guidance on ensuring fully functional access?