Problem with authorization process

[Kostiantyn]

Hello,

At now I on the migration process from cisco tacacs+ server(Version F4.0.4.27a) to your(because i need a ldap support). And I successfully install a tac_plus version 202006201038/PCRE.

All work perfectly except authorization on zte olt c320 with fw 1.2.5P3, i can't upgrade it to next stable branch(where authorization work).

In attache i added log from tacacs server and screenshot of cli.

When I trying to log in on device, at first time a get message that I have entered invalid credentials(but it valid), after that I entered my username againt(but reale, at this moment doesn't matter what I will enter, if previous i entered valid credentials) and i log in on device.

If i using ssh, it work fine, but i have problem with acl(nac address don't sended to tacacs server). 

So maybe you can help me with my problem. If you need a tcp dump, i can send it to your mail.

[Marc Huber]

Hi Kostiantyn,

On 10.11.20 18:01, Kostiantyn wrote:

All work perfectly except authorization on zte olt c320 with fw 1.2.5P3, i can't upgrade it to next stable branch(where authorization work).

thanks for the debug output.

Basically, your ZTE device starts a LOGIN/ASCII session, with

session id: 25ee396d data length: 44
AUTHEN/START, priv_lvl=1
action=login (1)
authen_type=ascii (1)
service=login (1)
user_len=2 port_len=3 rem_addr_len=14
data_len=17
user (len: 2): xx
port (len: 3): vty
rem_addr (len: 14): xxx.xx.xx.xxx
data (len: 17): ec:1d:7f:xx:xx:xx

which is TAC_PLUS_AUTHEN_TYPE_ASCII with both username and, well, "data" pre-filled. Unfortunately, IOS-XE already misuses this (similar to PAP, but not a defined mechanism) to transmit the user password in the data portion, and the daemon tries to handle that. This obviously doesn't work for the ZTE device which misuses the data field too, but differently -- to transmit its MAC address.

Does forcefully zeroing the data length parameter improve ZTE behavior?

--- authen.c    2020/03/05 18:50:22    1.383
+++ authen.c    2020/11/10 17:44:45
@@ -1595,6 +1595,7 @@
         default:
         switch (start->type) {
         case TAC_PLUS_AUTHEN_TYPE_ASCII:
+             start->data_len = 0; // don't accept authen_data in the START packet
             if (start->user_len && start->data_len) {
             /* PAP-like inbound login. Not in the drafts, but used by IOS-XR. */
             session->authen_data->authfn = do_login;

Cheers,

Marc

[Kostiantyn]

Hi Marc,
Thanks for a quick answer, your patch work and now i can log in without double time entering my credentials.
But, I found one more problem with zte switch(oh this zte :) ).
I entering my credentials but on log i don't see it and have messege about invalid credentials.
Log in attached.

вт, 10 нояб. 2020 г. в 19:55, Marc Huber <marc.j...@gmail.com>:

--

WBR,

Astakhov Kostiantyn

[Marc Huber]

HI,

On 10.11.20 22:02, Kostiantyn wrote:
> Thanks for a quick answer, your patch work and now i can log in
> without double time entering my credentials.
> But, I found one more problem with zte switch(oh this zte :) ).
> I entering my credentials but on log i don't see it and have messege
> about invalid credentials.
> Log in attached.

I've had a look at that log, and all I can see is that the ZTE device is
sending an AUTHEN/START and the daemon responds with AUTHEN/GETUSER ...
5 seconds after that the ZTE device just seems to restart the session.

Do you have a F4.0.4.27a packet capture (I assume that the ZTE is
working there) that shows a working authentication/authorization?

Cheers,

Marc

[Kostiantyn]

I can get it tomorrow, I will send it as soon as got it.

--
wbr,
Kostiantyn

вт, 10 нояб. 2020 г., 23:38 Marc Huber <marc.j...@gmail.com>:

--
You received this message because you are subscribed to a topic in the Google Groups "Event-Driven Servers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/event-driven-servers/ejqpPqesMHo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to event-driven-ser...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/event-driven-servers/8ac8fe9c-c3ab-8083-b4d4-7c90bef4aa54%40googlemail.com.

[Kostiantyn]

Hi Marc,

Added log in attach.

вт, 10 нояб. 2020 г. в 23:46, Kostiantyn <ast.t...@gmail.com>:

--

WBR,

Astakhov Kostiantyn

[Marc Huber]

Hi Kostiantyn,

I'm sorry, I don't spot any significant differences between the "seq no 2" packets:

cisco_tacacs.log

tacacs_telnet_patch.log

version 192 (0xc0), type 1, seq no 2, flags 0x1 session_id 126575172 (0x78b6244), Data length 43 (0x2b) End header type=AUTHEN status=4 (AUTHEN/GETUSER) flags=0x0 msg_len=37, data_len=0 msg:  0xa User Access Verification 0xa data: End packet

version: 192, type: 1, seq no: 2, flags: unencrypted 10.10.3.3 session id: 69aab6dc data length: 43 AUTHEN status=4 (AUTHEN/GETUSER) flags=0x0 msg_len=37, data_len=0 msg (len: 37): \nUser Access Verification\n\nUsername: 0000 0a 55 73 65 72 20 41 63  63 65 73 73 20 56 65 72  .User Ac cess Ver 0010 69 66 69 63 61 74 69 6f  6e 0a 0a 55 73 65 72 6e  ificatio n..Usern 10.10.3.3 0020 61 6d 65 3a 20                                    ame: 10.10.3.3 data (len: 0): 10.10.3.3 ---<end packet>---

The only thing that makes me wonder here is that the "Username:" portion in the original log isn't displayed and the screenshot from your original mail doesn't show it either.

Can the ZTE device actually cope with welcome banners? Does

    welcome banner = ""

help?

Cheers,

Marc

[Kostiantyn]

Hi, I double checked and can say that the last problem linked only to this switch and appears on both versions of tacacs server. So i disabled aaa and enabled only local auth.

Thanks for help and have a nice day!

ср, 11 нояб. 2020 г. в 19:31, Marc Huber <marc.j...@gmail.com>:

--
You received this message because you are subscribed to a topic in the Google Groups "Event-Driven Servers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/event-driven-servers/ejqpPqesMHo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to event-driven-ser...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/event-driven-servers/ab92c13e-8c42-5f0f-1c00-0323cf37a2cd%40googlemail.com.

--

WBR,

Astakhov Kostiantyn