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.

[Jan Rolny]

Hi Rakesh,

you have probably missed "local" word after tacacs in your aaa config.

it should look like this 

aaa new-model

aaa authentication login default group tacacs+ local  <<<< here device will first attempt to contact tacacs server and if it fails it will go local

Can you share your aaa configuration?

Best regards,

Jan

[Richard Burts]

If the OP wants to have local credentials to allow login to the switch when tacacs is not available (whether it is because switch IP has been removed on server or for other reasons) then I believe that Jan is correct in suggesting the local parameter be added to the config.

[rakesh nair]

SW1-AWSBRKOUT-DC1-R2B36#show run aaa
!
aaa authentication login default group cppm-grp local enable
aaa authentication enable default group cppm-grp enable
aaa authorization exec default group cppm-grp local
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
username admin privilege 15 password 7password
username wiproadmin privilege 15 password 7 password
!
!
!
!
!
!
tacacs server cppm01-srvr
address ipv4 10.0.x.x
key 7 password
!
!
aaa group server tacacs+ cppm-grp
server name cppm01-srvr
ip vrf forwarding Mgmt-vrf
ip tacacs source-interface GigabitEthernet0/0
!
!
!
aaa new-model
aaa session-id common
!
!
ip tacacs source-interface GigabitEthernet0/0 vrf Mgmt-vrf

SW1-AWSBRKOUT-DC1-R2B36#

[rakesh nair]

This is the aaa config im using

[rakesh nair]

And the error im seeing while using local is this

Using username "admin".
Keyboard-interactive authentication prompts from server:
End of keyboard-interactive prompts from server

Tacacs session has expired.Please re-login to continue.

[Richard Burts]

Thanks for the additional information. Are you attempting access using the console, or by SSH/telnet/ or by the web interface? It might be helpful to see the configuration of the interface that you are accessing.

I would suggest one change in your config - use this

aaa authorization exec default group cppm-grp if-authenticated

[rakesh nair]

Hi,

Im accessing through SSH.

I tried this command also, no luck.

Im getting tacacs error, switch is sending local credentials to server for authentication and server is rejecting it , as local cred are not available in tacacs server.

This is the error im seeing in switch 

Tacacs session has expired.Please re-login to continue.

[Mancunian]

Local vs TACACS conflict: If you're trying to log in with local credentials but TACACS is still the primary method, and it's not available or has expired, it may reject the attempt instead of falling back to local.

TACACS server unreachable: The TACACS server might be down or unreachable, so the authentication request fails without reverting to local login, depending on the device's fallback configuration.

[Giuseppe Larosa]

Hello @rakesh nair ,

>> Im getting tacacs error, switch is sending local credentials to server for authentication and server is rejecting it , as local cred are not available in tacacs server.

This is normal and it is the expected behaviour the list of authentication methods is an ordered list and the first method is used untl the TACACS+ server is reachable from the local device.

In order to be able to use local accounts the local device must be not able to communicate with the tacacs+ server.

To emulate this you can use an extended access-list on the upstream L3 device or in the upstream L3 device you can use a static route to null0 like

ip route <tacacs-server> 255.255.255.255 null0

only in this condition is the second AAA method used and you can login with local user credentials.

Hope to help

Giuseppe

[Richard Burts]

It was my understanding of the OP that the intention was to have tacacs as primary and local as a fall back when tacacs was not available. And it was my understanding that the plan for testing was to make the tacacs server unavailable. But in reading the posts it sounds like tacacs is still available. Am I misunderstanding something?

Is it perhaps the case that sometimes you want to access using SSH and sometimes access using telnet? I have a suggestion that could enable that. Now your aaa configuration for authentication has one method, called default which enables both SSH and telnet. If you want to use both I suggest these steps:

- create 2 methods for authentication, perhaps call one SSH and have it specify the tacacs server (and perhaps local as a fallback), perhaps call the other one telnet and have it specify local authentication. 

- configure some of the vty (perhaps 0 through 3) to use the SSH method and configure the rest of the vty (4 and 5) to use local.

If you do that when you attempt access using SSH it can use only vty 0 through 3 and will authenticate using tacacs and if you attempt access using telnet it can use on vty 4 and 5 and will use local credentials.

[rakesh nair]

TACACS service is still reachable, but we removed the switch from device group in tacacs server , my intention is to test the local connection even if tacacs is accessible but intentionally removing he device from the list

[rakesh nair]

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 

[Giuseppe Larosa]

Hello @rakesh nair ,

yes the static to null0 makes the tacacs server unreachable and it triggers the use of next method in list that is local credentials.

until the switch is able to reach the tacacas+ server whatever answer it gets also an error mesage it will not move on to next authentication method.

Hope to help

Giuseppe

[Richard Burts]

What you describe is the expected behavior. The way that you are currently configured it is one authentication method or the other, but not both. If tacacs is available and working then the local name/password will not work. And if the local name/password works then tacacs is not available.

I get the impression that you want both methods to work at the same time. Is that correct? If so then you need to implement the changes that I suggested such that some vty work with tacacs and other vty work with local. I do not know of any other way to have both tacacs and local name/password working at the same time.