Switch local credentials are not working after removing switch IP from

[rakesh nair]

Hi Team,

I was able to login to new cisco 9300 switch with local credentials, post adding the switch in TACACS , the switch is accessible using TACACS credentials which is working as expected.

But i would like to access the switch with local credential as well by removing the switch ip from Network device group from Aruba policy manager which is the TACACS server.

How can we accomodate both this requiremets in cisco 9300.

I am able to do same for Ruckus switches, but cisco.

Need your expertise.

[rakesh nair]

Thanks Richard and Gluseppe. I will try both ways

[MHM Cisco World]

The SW start use local when it detect down of AAA server.

You need to use automate-tester to make it work.

MHM

[Richard Burts]

Perhaps we need Rakesh to clarify what they want to achieve. It seems to me that there are 4 alternatives:

- configure just tacacs (local not used at all)

- configure just local (tacacs not used at all)

- configure tacacs as primary and local as fallback if tacacs is not available 

- configure to use both tacacs and local (as in the example I previously posted).

Is one of these your objective, or is there something else you have in mind? Once we understand what you really want to achieve we can give you better advice. 

[rakesh nair]

Our requirement is to have tacacs as primary and local as fallback , if tacacs is not available.

I know the default behaviour of cisco is to go for local cred, only if tacacs ip is not reachable. I was exploring to have any other option to test the local fallback by just removing switch details from tacacs server device group.

Because when i remove the switch ip of Ruckus and Lantronix switches from server, the device is accessible by local instead of tacacs, i was expecting same behaviour for Cisco.

[Richard Burts · Accepted solution]

Rakesh

Thanks for the clarification.  Tacacs as primary and local as fallback is a frequent situation. And you have tried this. I am curious about the post where you have tested this and were surprised at the result:

After configuring ip route vrf Mgmt-vrf 10.x.x.x 255.255.255.255 Null0 , im able to access using local credentials, but unfortunately tacacs is not working

If you have made the tacacs server not reachable, why would you be disappointed that tacacs is not working?

[rakesh nair]

I understand the behaviour of cisco device and i am good with the result.

I have one more question. To restrict the access of users, i have created 3 profiles in tacacs server.

Readonly, Super admin and Admin with limited privilege, but for only cisco switches , if i put user in any of the profile, user is getting full privilege

[MHM Cisco World]

again use automate-test to make SW send to TACACS and since TACACS will not reply the SW will know there is problem with server and back to use local. 

MHM

[Richard Burts]

I will try to address your one more question. In an earlier post you provided the part of the config dealing with aaa. Is that still an accurate extract from your current running config? If it has changed any please post the current version.

As I understand it you have configured your Cisco to do authentication and authorization with the tacacs server. If the user IDs you have configured are able to login then your Cisco and the tacacs server are correctly communicating. If "user is getting full privilege" that is not a Cisco configuration issue but is a tacacs server configuration issue. After a user authenticates with tacacs the Cisco asks the tacacs server what can this user do, and apparently the tacacs server is responding with the same information for each of your users.  In the tacacs server you need to specify the appropriate level of command for each user.

[rakesh nair]

Hi ,

I have modified a little bit

aaa authentication login default group cppm-grp local
aaa authentication enable default group cppm-grp enable
aaa authorization exec default group cppm-grp if-authenticated
aaa authorization commands 0 default group cppm-grp if-authenticated
aaa authorization commands 1 default group cppm-grp if-authenticated
aaa authorization commands 15 default group cppm-grp if-authenticated
aaa authorization config-commands
aaa accounting exec default start-stop group cppm-grp
aaa accounting network default start-stop group cppm-grp
aaa accounting commands 0 default start-stop group cppm-grp

[rakesh nair]

I made some config changes in tacacs server as well and my read only users are not able to go to enable mode, can you tell me which privilege level and shell pivilege value , i can give , so that users should only see show copmmands, but not to go to config terminal

[MHM Cisco World]

You wasting your time, 

Without way SW detect failed of server it never fallback to local

MHM

[josimaru85]

To accommodate both TACACS and local authentication on the Cisco 9300 switch, you need to ensure that the switch is configured to fall back to local authentication if TACACS fails or if the device is not in the TACACS server's network device group. Here's how you can configure it:

1. Configure Local Authentication on Cisco 9300

First, ensure that local authentication is configured on the Cisco 9300. If you haven't already done so, create a local user for the switch:

bash

CopiarEditar

conf t username <local_user> privilege 15 secret <password>

2. Configure AAA Authentication to Use Both Local and TACACS

The key part here is configuring the aaa authentication method to try TACACS first and fall back to local authentication if TACACS is unavailable. You can set this up with the following commands:

bash

CopiarEditar

conf t aaa new-model aaa authentication login default group tacacs+ local aaa authorization exec default group tacacs+ local

• group tacacs+: This tells the switch to use the TACACS server.

• local: This will ensure that local authentication is used if the TACACS server is not reachable or if the switch IP is not found in the TACACS server’s network device group.

3. Ensure the TACACS Server Configuration is Correct

• Make sure that the Cisco 9300 switch is correctly added to the Aruba TACACS server with the appropriate network device group.

• However, in your case, when you remove the switch IP from the Aruba policy manager, the switch will automatically fall back to the local credentials due to the configuration above.

4. Verify Configuration

You can check your configuration to verify that both methods are working by using the following command:

bash

CopiarEditar

show run | include aaa

This will display your AAA authentication settings, and you should see that both group tacacs+ and local are included for the login and exec authorization.

Example:

Here’s how the configuration would look in practice:

bash

CopiarEditar

conf t username admin privilege 15 secret AdminPassword123 aaa new-model aaa authentication login default group tacacs+ local aaa authorization exec default group tacacs+ local

This setup ensures that the switch will first try to authenticate using TACACS. If TACACS is unavailable or the device is not recognized by the Aruba TACACS server, it will fall back to using the locally configured credentials.

Let me know if you need further clarification!

---

Best regards,
Josimar Caitano /  Josinfo
(CCIE / Cisco Instructor / Trading Floor)

[rakesh nair]

This is exactly i configured, but fallback not happening if i remove switch ip from device group in tacacs server, but if tacacs server is failing then local will work as expected. As per others opinion , cisco switch will never fallback when switch ip is removed from tacacs server device group until connection between switch and server breaks.

[Jens Albrecht]

The keypoint is that Cisco devices only fallback if they do not get ANY reply from tacacs/radius.

I don't know Aruba policy manager but in case of Cisco ISE it is possible to modify the policy to silently drop an incoming request if ISE does not find the user in its database. Hence you could authenticate with the local user even if tacacs is reachable.

However, I strongly recommend not to go that way as such options have the potential to break the security of your network and open a gateway to hell.

[rakesh nair]

Thanks Jens