[RADIATOR] Issues with Tacacs/Radius and v6 conversion

[Heikki Vatiainen]

On 01/26/2011 05:08 PM, Patrik Forsberg wrote:

>> Is this pure RADIUS or something that has been converted from TACACS+?
> 
> From what I can tell it's only on Tacacs+ messages, but as I mentioned before, I haven't seen it on Radius yet but that doesn't mean that its not the same there.

> It's pretty strait forward, I think. We have a Extreme and a Brocade(Foundry) device that try to authenticate a user on the tacacs server running in Radiator.
> Config for the extreme is as follows
> "
> configure tacacs primary shared-secret <secret-key>
> configure tacacs primary server <server-ip> client-ip <client-ip> vr <VR-A>
> configure tacacs-accounting primary shared-secret <secret-key>

As an additional test, can you try unencyprted configuration and use
e.g., Wireshark to see the Tacacs+ message when it is received from the
network. Message fields user, port, remote address and arguments are in
that order and are all ASCII strings. If you see the same ::ffff: prefix
there, then you may want to contact the switch vendor.

> The Brocade have a similar configuration ofc :)

About this ::ffff: problem: do you see it with both Extreme and Brocade?

> Radiator is almost as simple but simply to many rows to paste in here.. but it's pretty much the same as in the example configurations from "goodies".. and as far as authentication goes it's working as intended.

Ok.

> Trace 4 log

> Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection result Access-Accept
> Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection Authentication REPLY 1, 0, ,
> Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection disconnected from 111.11.111.111:34801
> Wed Jan 26 15:55:43 2011: DEBUG: New TacacsplusConnection created for 111.11.111.111:41205
> Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection request 192, 2, 1, 0, 1763071228, 57
> Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection Authorization REQUEST 6, 15, 1, 1, <snip>, telnet175, ::ffff:111.11.1, 2, service=shell cmd=

Thanks for the log. Username (<snip>), port (telnet175), rem_addr
(::ffff:111.11.1) and arguments (service=shell cmd=) are all ASCII
strings that follow each other directly in the message body.

Based on this the original message Radiator receives from Extreme or
Brocade seems to have incorrect information for rem_addr. There seems to
be enough space for a full length IP address (aaa.bbb.ccc.ddd) but
there's not enough of original IP left so that it can e.g., be rewritten
with Radiator.

The same seems to happen with Accounting REQUEST as shown below.

It would be interesting to see any results from Wireshark. That would
confirm the suspicion that the received message is not quite right.

You could rewrite the Calling-Station-Id with Radiator, but I guess
there is not enough information in the ::ffff: prefixed address, is there?


> Wed Jan 26 15:55:43 2011: DEBUG: AuthorizeGroup rule match found: permit service=shell cmd= { priv-lvl=15 }
> Wed Jan 26 15:55:43 2011: INFO: Authorization permitted for <snip> at 111.11.111.111, group manager, args service=shell cmd=
> Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection Authorization RESPONSE 1, , , priv-lvl=15 priv-lvl=15
> Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection disconnected from 111.11.111.111:41205
> Wed Jan 26 15:55:43 2011: DEBUG: New TacacsplusConnection created for 111.11.111.111:60789
> Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection request 192, 3, 1, 0, 1553834616, 75
> Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection Accounting REQUEST 2, 6, 15, 1, 1, <snip>, telnet175, ::ffff:111.11.1, 2, start_time=1296053322 service=shell
> Wed Jan 26 15:55:43 2011: DEBUG: TACACSPLUS derived Radius request packet dump:
> Code:       Accounting-Request
> Identifier: UNDEF
> Authentic:  <snip>
> Attributes:
>         NAS-IP-Address = 111.11.111.111
>         NAS-Port-Id = "telnet175"
>         Calling-Station-Id = "::ffff:111.11.1"
>         NAS-Identifier = "TACACS"
>         User-Name = "<snip>"
>         Acct-Status-Type = Start
>         Acct-Session-Id = "1553834616"
>         cisco-avpair = "start_time=1296053322"
>         cisco-avpair = "service=shell"
>         OSC-Version-Identifier = "192"


> The the log.. snipped out a few things and changed the ip to 111s ;)

Ok.

> As far as I can tell the rem_addr is getting limited by rem_addr_len in ServerTACACS.pm .. but that in it self might not be it ?

I'm not sure what you mean, but since they are ASCII strings the ::ffff:
does not look like error in offset while decoding.

> Did a Trace 5 dump too.. but that doesn't seem to reveal anything that the trace 4 dump doesn't.

Trace 5 dump should show what the message looks when it is just
received. You can check with ascii chart if ::ffff: is in the level 5
hex dump.

So in summary: if you could verify the message contents with e.g.,
Wireshark that would be useful to see where to ask fixes from.

Thanks!

-- 
Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.