[tac_plus] Is it possible to handle anonymous authorization requests?
Martin T
m4rtntns at gmail.com
Fri May 25 10:37:34 UTC 2018
On Fri, May 25, 2018 at 1:12 AM, heasley <heas at shrubbery.net> wrote:
> Thu, May 24, 2018 at 07:20:39PM +0300, Martin T:
>> Hi!
>>
>> I have two Cisco 3750-E series switches in a stacked configuration.
>> When I connect to "Master" switch over console port, then I'm able to
>> authenticate and authorize without issues. When I connect to "Member"
>> switch over console port, then I'm not able to authorize. I see that
>> switch sends the authorization(type 2) packet to TACACS+ server:
>>
>> 014310: May 24 15:34:57.824 UTC: %SEC_LOGIN-5-LOGIN_SUCCESS: Login
>> Success [user: ] [Source: UNKNOWN] [localport: 0] at 15:34:57 UTC Thu
>> May 24 2018
>> 014352: May 24 15:35:58.258 UTC: T+: Version 192 (0xC0), type 2, seq
>> 1, encryption 1
>> 014353: May 24 15:35:58.258 UTC: T+: session_id 3904028160
>> (0xE8B2BE00), dlen 40 (0x28)
>> 014354: May 24 15:35:58.258 UTC: T+: AUTHOR, priv_lvl:1, authen:1
>> method:enable
>> 014355: May 24 15:35:58.258 UTC: T+: svc:1 user_len:0 port_len:4
>> rem_addr_len:9 arg_cnt:2
>> 014356: May 24 15:35:58.258 UTC: T+: user:
>> 014357: May 24 15:35:58.258 UTC: T+: port: tty4
>> 014358: May 24 15:35:58.258 UTC: T+: rem_addr: 127.0.0.4
>> 014359: May 24 15:35:58.258 UTC: T+: arg[0]: size:13 service=shell
>> 014360: May 24 15:35:58.258 UTC: T+: arg[1]: size:4 cmd*
>> 014361: May 24 15:35:58.267 UTC: T+: End Packet
>>
>>
>> ..and TACACS+ server replies with FAIL. I also did the packet capture
>> in TACACS+ server and saw exactly the same behavior. As seen above,
>> "user" field is empty. Also, the TACACS+ server logs that "user '' not
>> found, denied by default".
>>
>> Any ideas, why master switch skips sending the authorization request?
>> Why is the "user" field of member switch authentication request empty?
>
> Does the console ask for a username? does it require different configuration
> to enable aaa such as configured under 'line tty4' rather than line con?
>
>> Most importantly, is there a workaround to handle anonymous
>> authorization requests? I tried with "anonymous-enable = permit" under
>> host level, but this did not help. Authorization-related configuration
>> in the switch is "aaa authorization exec default group tacacs+
>> if-authenticated".
>
> I'd lean toward a bug in ios or missing config, but the tacacs protocol
> clearly allows the the username to omitted. tbh, i dont know if the
> daemon allows an empty user; its not in the manpage that I compiled. I'd
> have to look through the code, whcih i can't do ATM. perhaps, try the
> special user DEFAULT or "".
Thanks for the reply!
> Does the console ask for a username?
No, the console does not ask for a username. Only the password.
> does it require different configuration to enable aaa such as configured under 'line tty4' rather than line con?
Yes, in case of stacked setup, the "Member" switch console port should
use line "vty 0 15" AAA authorization list. There is a Cisco bug
CSCsw51727 for this. I use default authorization list for vty lines,
i.e "authorization exec default". This should mean that "aaa
authorization exec default group tacacs+ if-authenticated" has an
effect. I can confirm this by changing the "aaa authorization exec
default group tacacs+ if-authenticated" to "aaa authorization exec
default none". Then I was able to log in to the console port of
"Member" switch.
> perhaps, try the special user DEFAULT or "".
Unfortunately, those did not work. I still see the "user '' not found,
denied by default" in tac_plus log.
> I'd lean toward a bug in ios or missing config
Me too. The workaround in CSCsw51727 works, i.e if one creates a local
user to a switch, then configures "aaa authentication login console
local" and finally adds this local user to TACACS+ server, then switch
sends this authorization packet with this locally configured
user-name. However, in case of "aaa authentication login console
enable" it sends this authorization packet with an empty user-name.
regards,
Martin
More information about the tac_plus
mailing list