bypassing aaa authnetication

[netbeginner]

Hi,

Would like to bypass TACACS authentication for a particular or specific user on Cisco asa 5500.

For example.... We have aaa authentication configured on ASA , but still require to bypass tacacs authentication for a specific local user with enable mode full access rest users should authenticate through TACACS only.

pl advise CLI

[Philip D'Ath]

This is off a Catalyst switch, but the idea should be close for an ASA.

aaa authentication login default local group tacacs+
aaa authentication enable default group tacacs+ enable
aaa authorization console
aaa authorization exec default local group tacacs+

[Karsten Iwen]

That won't work on the ASA. Local authentication can only be configured as a backup for a remote authentication, but not in the order "first LOCAL, then TACACS".

There could be a workaround: If the particular user can authenticate through RSA, then the TACACS-authentication can be skipped.

[Richard Bradfield]

Is this specific user an Admin user?

[netbeginner]

Ys , Will be a Admin User

[Richard Bradfield]

Ok can use something like

aaa authentication telnet console LOCAL

see extract from link below

http://www.cisco.com/c/en/us/td/docs/security/asa/asa82/configuration/guide/config/access_aaa.html#wp1084748

Local Database Support

The ASA maintains a local database that you can populate with user profiles.

This section contains the following topics:

•User Profiles

•Fallback Support

User Profiles

User profiles contain, at a minimum, a username. Typically, a password is assigned to each username, although passwords are optional.

The username attributes command lets you enter the username mode. In this mode, you can add other information to a specific user profile. The information you can add includes VPN-related attributes, such as a VPN session timeout value.

Fallback Support

The local database can act as a fallback method for several functions. This behavior is designed to help you prevent accidental lockout from the ASA.

For users who need fallback support, we recommend that their usernames and passwords in the local database match their usernames and passwords in the AAA servers. This provides transparent fallback support. Because the user cannot determine whether a AAA server or the local database is providing the service, using usernames and passwords on AAA servers that are different than the usernames and passwords in the local database means that the user cannot be certain which username and password should be given.

The local database supports the following fallback functions:

•Console and enable password authentication—When you use the aaa authentication console command, you can add the LOCAL keyword after the AAA server group tag. If the servers in the group all are unavailable, the ASA uses the local database to authenticate administrative access. This can include enable password authentication, too.

•Command authorization—When you use the aaa authorization command command, you can add the LOCAL keyword after the AAA server group tag. If the TACACS+ servers in the group all are unavailable, the local database is used to authorize commands based on privilege levels.

•VPN authentication and authorization—VPN authentication and authorization are supported to enable remote access to the ASA if AAA servers that normally support these VPN services are unavailable. Theauthentication-server-group command, available in tunnel-group general attributes mode, lets you specify the LOCAL keyword when you are configuring attributes of a tunnel group. When VPN client of an administrator specifies a tunnel group configured to fallback to the local database, the VPN tunnel can be established even if the AAA server group is unavailable, provided that the local database is configured with the necessary attributes.