search

facebook / tac_plus

A Tacacs+ Daemon tested on Linux (CentOS) to run AAA via TACACS+ Protocol via IPv4 and IPv6.
MIT License
216 stars 72 forks source link

authorization reply from tacacs server with the error TAC_PLUS_AUTHOR_STATUS_ERROR := 0x11 #43

Closed iyyapa closed 9 months ago

iyyapa commented 9 months ago

First time when we give wrong credentials and second time give correct credentials TACACS sever error. This happens when we do two logins back to back first wrong and then correct... Can someone check whether issue is from CISCO tacacs server side or client side. When we checked debug logs from server side got the below..

Tue Feb 6 13:59:19 2024 [10495]: Reading config Tue Feb 6 13:59:19 2024 [10495]: Version F4.0.4.26 Initialized 1 Tue Feb 6 13:59:19 2024 [10495]: tac_plus server F4.0.4.26 starting Tue Feb 6 13:59:19 2024 [10495]: uid=0 euid=0 gid=0 egid=0 s=4 Tue Feb 6 14:01:02 2024 [10526]: Reading config Tue Feb 6 14:01:02 2024 [10526]: Version F4.0.4.26 Initialized 1 Tue Feb 6 14:01:02 2024 [10526]: tac_plus server F4.0.4.26 starting Tue Feb 6 14:01:02 2024 [10526]: uid=0 euid=0 gid=0 egid=0 s=4 Tue Feb 6 14:03:00 2024 [10526]: connect from 192.168.0.233 [192.168.0.233] Tue Feb 6 14:03:00 2024 [10526]: cfg_get_hvalue: name=192.168.0.233 attr=key Tue Feb 6 14:03:00 2024 [10526]: cfg_get_hvalue: no host named 192.168.0.233 Tue Feb 6 14:03:00 2024 [10526]: cfg_get_phvalue: returns NULL Tue Feb 6 14:03:00 2024 [10526]: cfg_get_value: name=gcom isuser=1 attr=pap rec=1 Tue Feb 6 14:03:00 2024 [10526]: cfg_get_pvalue: returns des QpXJh0JnBY8yc Tue Feb 6 14:03:00 2024 [10526]: cfg_get_value: name=gcom isuser=1 attr=acl rec=1 Tue Feb 6 14:03:00 2024 [10526]: cfg_get_value: recurse group = admins Tue Feb 6 14:03:00 2024 [10526]: cfg_get_pvalue: returns tidcbp_tmap Tue Feb 6 14:03:00 2024 [10526]: pap-login query for 'gcom' ssh from 192.168.0.233 rejected ### >> First time wrong credentials** Tue Feb 6 14:03:00 2024 [10526]: login failure: gcom 192.168.0.233 (192.168.0.233) ssh Tue Feb 6 14:03:00 2024 [10526]: cfg_get_hvalue: name=192.168.0.233 attr=key Tue Feb 6 14:03:00 2024 [10526]: cfg_get_hvalue: no host named 192.168.0.233 Tue Feb 6 14:03:00 2024 [10526]: cfg_get_phvalue: returns NULL Tue Feb 6 14:03:09 2024 [10526]: connect from 192.168.0.233 [192.168.0.233] Tue Feb 6 14:03:09 2024 [10526]: cfg_get_hvalue: name=192.168.0.233 attr=key Tue Feb 6 14:03:09 2024 [10526]: cfg_get_hvalue: no host named 192.168.0.233 Tue Feb 6 14:03:09 2024 [10526]: cfg_get_phvalue: returns NULL Tue Feb 6 14:03:09 2024 [10526]: cfg_get_value: name=gcom isuser=1 attr=pap rec=1 Tue Feb 6 14:03:09 2024 [10526]: cfg_get_pvalue: returns des QpXJh0JnBY8yc Tue Feb 6 14:03:09 2024 [10526]: cfg_get_value: name=gcom isuser=1 attr=expires rec=1 Tue Feb 6 14:03:09 2024 [10526]: cfg_get_value: recurse group = admins Tue Feb 6 14:03:09 2024 [10526]: cfg_get_pvalue: returns NULL Tue Feb 6 14:03:09 2024 [10526]: cfg_get_value: name=gcom isuser=1 attr=acl rec=1 Tue Feb 6 14:03:09 2024 [10526]: cfg_get_value: recurse group = admins Tue Feb 6 14:03:09 2024 [10526]: cfg_get_pvalue: returns tidcbp_tmap Tue Feb 6 14:03:09 2024 [10526]: pap-login query for 'gcom' ssh from 192.168.0.233 accepted >> second time correct credentials.** Tue Feb 6 14:03:09 2024 [10526]: cfg_get_hvalue: name=192.168.0.233 attr=key Tue Feb 6 14:03:09 2024 [10526]: cfg_get_hvalue: no host named 192.168.0.233 Tue Feb 6 14:03:09 2024 [10526]: cfg_get_phvalue: returns NULL Tue Feb 6 14:03:09 2024 [10526]: connect from 192.168.0.233 [192.168.0.233] Tue Feb 6 14:03:09 2024 [10526]: cfg_get_hvalue: name=192.168.0.233 attr=key Tue Feb 6 14:03:09 2024 [10526]: cfg_get_hvalue: no host named 192.168.0.233 Tue Feb 6 14:03:09 2024 [10526]: cfg_get_phvalue: returns NULL Tue Feb 6 14:03:09 2024 [10526]: Error 192.168.0.233: author minimum payload length: 143, got: 58 Tue Feb 6 14:03:09 2024 [10526]: cfg_get_hvalue: name=192.168.0.233 attr=key Tue Feb 6 14:03:09 2024 [10526]: cfg_get_hvalue: no host named 192.168.0.233 Tue Feb 6 14:03:09 2024 [10526]: cfg_get_phvalue: returns NULL Tue Feb 6 14:03:09 2024 [10526]: connect from 192.168.0.233 [192.168.0.233] Tue Feb 6 14:03:09 2024 [10526]: cfg_get_hvalue: name=192.168.0.233 attr=key Tue Feb 6 14:03:09 2024 [10526]: cfg_get_hvalue: no host named 192.168.0.233 Tue Feb 6 14:03:09 2024 [10526]: cfg_get_phvalue: returns NULL Tue Feb 6 14:03:09 2024 [10526]: cfg_get_hvalue: name=192.168.0.233 attr=key Tue Feb 6 14:03:09 2024 [10526]: cfg_get_hvalue: no host named 192.168.0.233 Tue Feb 6 14:03:09 2024 [10526]: cfg_get_phvalue: returns NULL Tue Feb 6 14:03:13 2024 [10526]: connect from 192.168.0.233 [192.168.0.233] Tue Feb 6 14:03:13 2024 [10526]: cfg_get_hvalue: name=192.168.0.233 attr=key Tue Feb 6 14:03:13 2024 [10526]: cfg_get_hvalue: no host named 192.168.0.233 Tue Feb 6 14:03:13 2024 [10526]: cfg_get_phvalue: returns NULL Tue Feb 6 14:03:13 2024 [10526]: cfg_get_hvalue: name=192.168.0.233 attr=key Tue Feb 6 14:03:13 2024 [10526]: cfg_get_hvalue: no host named 192.168.0.233 Tue Feb 6 14:03:13 2024 [10526]: cfg_get_phvalue: returns NULL

RollerMatic commented 9 months ago

Hey @iyyapa , I need some additional information to debug this.

1) What exactly is the issue you are observing and What should be the expected response ? Is there a device you are not able to login to and get to the shell prompt ? Are you unable to run a command on the device ?

2) Can you please share your tacacs server config that can help us repro the issue ?

iyyapa commented 9 months ago

Hi @RollerMatic

The issue happens in below scenario.

  1. User login with tacacs server with wrong password. This is failed due to wrong password and it's expected behavior.
  2. Then loging with correct password and autherization fails.TAC_PLUS_AUTHOR_STATUS_ERROR := 0x11 . This is unexpected. From our analysis the client sends the unencrypted autherization request to tacacs server.
    Why client sends unencrypted request?
  3. This issue always happen after some login fails attempts then next time user logins.
  4. It is not seen when we give correct credentials for the first time.

The user role is configured as admin. It is CISCO ISE.

I requested the tacacs server config and share once I got.

RollerMatic commented 9 months ago

From our analysis the client sends the unencrypted autherization request to tacacs server. Why client sends unencrypted request?

do you have further details on how you confirmed this ? Do you have any packet captures that show the key being specified in cleartext ? The server has no role to play when it comes to client sending an unencrypted request. You need to check on the client side why this is happening. If the device is an Arista/cisco/juniper, usually the PSK is configured at the server configuration level than at the AAA operation level.

On the server side, it looks to me that the server tries to lookup the key for the host, which isn't configured (indicated by "no host named 192.168.0.233". )

There are two ways to resolve that

  1. configure the key for all devices by putting this line at the top of your tac_plus.conf 
    key = <your psk>
  2. Specify the key for the specific host 
    host = 192.168.0.233 {
key = <PSK configured on the host>
}
iyyapa commented 9 months ago

Thanks for your inputs. Please find the below pcap snapshot image

This is extreme device. I have doubt, If there is an issue with device it should fail always right. This happens only when first time wrong credentials and then correct credentials.

RollerMatic commented 9 months ago

Other than the unencrypted payload, it's surprising that the device hasn't send any authorization arguments which are usually needed to authorize a request from a network device. I am not sure if those arguments got clipped in your pcap snapshot. As I said before, server cannot influence the client to send an unencrypted packet. This is just not part of the protocol. If the client sends an unencrypted packet , it needs to inform the server through a request flag. This doesn't look to be a server problem of any kind. I would suggest you work with Cisco ISE and Extreme switch TACs to figure out the correct configuration for your device, and ISE server.

iyyapa commented 9 months ago

The device sends authorization arguments. The issue with Extreme switch because it was working in lower releases and not working after upgrade the higher release. I will share the server configs once I received from TAC.. Can we suggest the below config to customer to resolve the issue..

There are two ways to resolve that

configure the key for all devices by putting this line at the top of your tac_plus.conf key = <your psk> Specify the key for the specific host

host = 192.168.0.233 {
    key = <PSK configured on the host>

}

RollerMatic commented 9 months ago

@iyyapa we don't have enough information from you to confirm the problem.

You mention

The device sends authorization arguments

and yet , the captured pcap shows no arguments in the authorization packet. We don't have the server config to see what exactly is configured on CISCO's end I can't speak on what you could refer to the customer at this time. You can try the change I suggested and see if it helps your case, else I would suggest to raise a case with CISCO TAC.

marking as #resolved because this is not a problem in the tac_plus code, and looks to be a device level interaction problem between an EXTREME networks switch and CISCO ISE. Please raise a new issue with all the necessary information if there is any logging driven symptom of tac_plus server exhibiting unexpected behaviour.

iyyapa commented 9 months ago

@RollerMatic I missed to attach the pcap

image

iyyapa commented 9 months ago

can't speak on what you could refer to the customer at this time. You can try the change I suggested and see if it helps your case, else I would suggest to raise a case with CISCO TAC.

Sure. Thanks for your help.

RollerMatic commented 9 months ago

@RollerMatic I missed to attach the pcap

image

From this pcap, I can see that the device needs an optional arg to be set in the TACACS config. EXTREME should be able to help you with the arguments that need to be set . Here is a sample config authorizing the user as admin There is more info here

service = exec {
      optional brcd-role = admin;
 }
iyyapa commented 9 months ago

Added AV-Pair configuration to Cisco ISE a few days ago but issue still exist. brcd-role = admin brcd-AV-Pair1 = "homeLF=30;LFRoleList=admin:1,2,11,12,13,14,15,16,17,18,19,20" brcd-AV-Pair2 = "chassisRole=admin"

iyyapa commented 8 months ago

@RollerMatic

Customer has shared the debug logs from server side. Can you please review and share your comments. Customer entered wrong credentials first two times and then enters correct credentials..

tacacs server debugs: image