authorization reply from tacacs server with the error TAC_PLUS_AUTHOR_STATUS_ERROR := 0x11 about tac_plus

[iyyapa]

@RollerMatic
I missed to attach the pcap

[RollerMatic]

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]

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]

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]

Thanks for your inputs. Please find the below pcap snapshot

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]

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]

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]

@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]

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]

@RollerMatic I missed to attach the pcap

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]

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]

@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: