[RADIATOR] Client-Identifier doesn't match handler for Tacacs requests
Alexander Hartmaier
alexander.hartmaier at t-systems.at
Thu Dec 3 10:41:49 CST 2009
That's the login to a cisco router:
Thu Dec 3 17:31:04 2009: DEBUG: New TacacsplusConnection created for
212.166.120.8:22987
Thu Dec 3 17:31:04 2009: DEBUG: TacacsplusConnection request 192, 1, 1,
0, 3629192834, 32
Thu Dec 3 17:31:04 2009: DEBUG: TacacsplusConnection Authentication
START 1, 1, 1 for username, tty1, 192.168.1.2
Thu Dec 3 17:31:04 2009: DEBUG: TacacsplusConnection Authentication
REPLY 5, 1, Password: ,
Thu Dec 3 17:31:06 2009: DEBUG: TacacsplusConnection request 192, 1, 3,
0, 3629192834, 14
Thu Dec 3 17:31:06 2009: DEBUG: TacacsplusConnection Authentication
CONTINUE 0, **obscured**,
Thu Dec 3 17:31:06 2009: DEBUG: TACACSPLUS derived Radius request
packet dump:
Code: Access-Request
Identifier: UNDEF
Authentic: <24><159>!<174><25>qO<158>b<255>Ft<186><21><143><225>
Attributes:
NAS-IP-Address = 212.166.120.8
NAS-Port-Id = "tty1"
Calling-Station-Id = "1.2.3.4"
Service-Type = Login-User
User-Name = "username"
User-Password = **obscured**
OSC-Version-Identifier = "192"
Thu Dec 3 17:31:06 2009: DEBUG: Hook tacacs_client_identifier called
Thu Dec 3 17:31:06 2009: DEBUG: Hook tacacs_client_identifier searching
for client <10.1.2.3>
Thu Dec 3 17:31:06 2009: DEBUG: Hook tacacs_client_identifier got
client ident <ipls>
Thu Dec 3 17:31:06 2009: DEBUG: Handling request with Handler
'OSC-Client-Identifier=ipls, Service-Type=Login-User'
Thu Dec 3 17:31:06 2009: DEBUG: Deleting session for username,
10.1.2.3,
Thu Dec 3 17:31:06 2009: DEBUG: Handling with Radius::AuthFILE:
Thu Dec 3 17:31:06 2009: DEBUG: Radius::AuthFILE looks for match with
username [username]
Thu Dec 3 17:31:06 2009: DEBUG: Radius::AuthFILE REJECT: No such user:
username [username]
Thu Dec 3 17:31:06 2009: DEBUG: AuthBy FILE result: REJECT, No such
user
Thu Dec 3 17:31:06 2009: DEBUG: Handling with TACACSPLUS
our.tacacs.server, oursecret
Thu Dec 3 17:31:06 2009: DEBUG: AuthBy TACACSPLUS result: ACCEPT,
Thu Dec 3 17:31:06 2009: DEBUG: Access accepted for username
Thu Dec 3 17:31:06 2009: DEBUG: Packet dump:
*** Reply to TACACSPLUS request:
Code: Access-Accept
Identifier: UNDEF
Authentic: <24><159>!<174><25>qO<158>b<255>Ft<186><21><143><225>
Attributes:
Thu Dec 3 17:31:06 2009: DEBUG: TacacsplusConnection result
Access-Accept
Thu Dec 3 17:31:06 2009: DEBUG: TacacsplusConnection Authentication
REPLY 1, 0, ,
Thu Dec 3 17:31:06 2009: DEBUG: TacacsplusConnection disconnected from
10.1.2.3:22987
And that's the debug from the enable command:
Thu Dec 3 17:31:08 2009: DEBUG: New TacacsplusConnection created for
10.1.2.3:56946
Thu Dec 3 17:31:08 2009: DEBUG: TacacsplusConnection request 192, 1, 1,
0, 2782843248, 32
Thu Dec 3 17:31:08 2009: DEBUG: TacacsplusConnection Authentication
START 1, 1, 2 for username, tty1, 1.2.3.4
Thu Dec 3 17:31:08 2009: DEBUG: TacacsplusConnection Authentication
REPLY 5, 1, Password: ,
Thu Dec 3 17:31:14 2009: DEBUG: TacacsplusConnection request 192, 1, 3,
0, 2782843248, 14
Thu Dec 3 17:31:14 2009: DEBUG: TacacsplusConnection Authentication
CONTINUE 0, **obscured**,
Thu Dec 3 17:31:14 2009: DEBUG: TACACSPLUS derived Radius request
packet dump:
Code: Access-Request
Identifier: UNDEF
Authentic: {<205><134><6>Bp<161><187>`4<25><<142>o<193><243>
Attributes:
NAS-IP-Address = 10.1.2.3
NAS-Port-Id = "tty1"
Calling-Station-Id = "1.2.3.4"
Service-Type = Administrative-User
User-Name = "username"
User-Password = **obscured**
OSC-Version-Identifier = "192"
Thu Dec 3 17:31:14 2009: DEBUG: Hook tacacs_client_identifier called
Thu Dec 3 17:31:14 2009: DEBUG: Hook tacacs_client_identifier searching
for client <10.1.2.3>
Thu Dec 3 17:31:14 2009: DEBUG: Hook tacacs_client_identifier got
client ident <ipls>
Thu Dec 3 17:31:14 2009: DEBUG: Handling request with Handler
'OSC-Client-Identifier=ipls, Service-Type=Administrative-User'
Thu Dec 3 17:31:14 2009: DEBUG: Deleting session for username,
10.1.2.3,
Thu Dec 3 17:31:14 2009: DEBUG: Handling with Radius::AuthFILE:
Thu Dec 3 17:31:14 2009: DEBUG: Radius::AuthFILE looks for match with
username [username]
Thu Dec 3 17:31:14 2009: DEBUG: Radius::AuthFILE REJECT: No such user:
username [username]
Thu Dec 3 17:31:14 2009: DEBUG: AuthBy FILE result: REJECT, No such
user
Thu Dec 3 17:31:14 2009: DEBUG: Handling with TACACSPLUS
our.tacacs.server, oursecret
Thu Dec 3 17:31:14 2009: DEBUG: AuthBy TACACSPLUS result: ACCEPT,
Thu Dec 3 17:31:14 2009: DEBUG: Access accepted for username
Thu Dec 3 17:31:14 2009: DEBUG: Packet dump:
*** Reply to TACACSPLUS request:
Code: Access-Accept
Identifier: UNDEF
Authentic: {<205><134><6>Bp<161><187>`4<25><<142>o<193><243>
Attributes:
Thu Dec 3 17:31:14 2009: DEBUG: TacacsplusConnection result
Access-Accept
Thu Dec 3 17:31:14 2009: DEBUG: TacacsplusConnection Authentication
REPLY 1, 0, ,
Thu Dec 3 17:31:14 2009: DEBUG: TacacsplusConnection disconnected from
10.1.2.3:56946
The second (enable) tacacs+ request becomes a radius request with
Service-Type = Administrative-User, then get's transformed to a tacacs
request to our central tacacs+ server but looses the information about
the type of login (login vs. enable) and the backend radiator server
shows Service-Type = Login-User instead.
I assume the ServerTACACSPLUS module doesn't take the Service-Type into
account when creating the tacacs+ packet.
--
Best regards, Alex
Am Donnerstag, den 03.12.2009, 01:13 +0100 schrieb Hugh Irvine:
> Hello Alex -
>
> Yes I have spoken to Mike about the Service-Type and he asks if you can send us the debugs showning what is happening and what is getting changed?
>
> As for the TACACS+ Client-Identifier behaviour, we will leave things as they are simply for historical reasons.
>
> When that part of the code was developed, the ServerTACACSPLUS module did not make use of the RADIUS client clauses at all.
>
> Obviously in perfect hindsight it would have been preferable to do things differently, but we didn't then and now we can't really change it.
>
> thanks for your assistance
>
> regards
>
> Hugh
>
>
>
> On 3 Dec 2009, at 00:54, Alexander Hartmaier wrote:
>
> > Hi Hugh!
> >
> > Have you already talked to Mike about the Service-Type?
> >
> > What about changing the behavior like I suggested so a TACACS+ and a
> > Radius handler behave identical?
> >
> > --
> > Best regards, Alex
> >
> >
> > Am Mittwoch, den 25.11.2009, 11:49 +0100 schrieb Hugh Irvine:
> >> Hello Alex -
> >>
> >> You can add a simple PreHandlerHook in the ServerTACACSPLUS clause to look up the Client and add an OSC-Client-Identifier to the request.
> >>
> >> I'll talk to Mike tomorrow about the Service-Type.
> >>
> >> regards
> >>
> >> Hugh
> >>
> >>
> >>
> >> On 25 Nov 2009, at 21:18, Alexander Hartmaier wrote:
> >>
> >>> Hi Hugh!
> >>>
> >>> Because the fake radius request originates from it?
> >>>
> >>> Can that behavior be changed to match that of Radius?
> >>> It makes more sense to be able to distinguish from which NAS the request
> >>> came than to know how the internals of Radiator work.
> >>>
> >>> Additionally we've found out that the request from the tacacs proxy
> >>> Radiator to the backend Radiator doesn't contain the info which
> >>> transforms to the Service-Type radius attribute, so
> >>> Service-Type=Administrative-User becomes Service-Type=Login-User.
> >>> I couldn't find the opposite of the service_to_service_type hash to fix
> >>> it myself.
> >>>
> >>> --
> >>> Best regards, Alex
> >>>
> >>>
> >>> Am Dienstag, den 24.11.2009, 22:54 +0100 schrieb Hugh Irvine:
> >>>> Hello Alexander -
> >>>>
> >>>> The client for TACACS is the ServerTACACSPLUS clause.
> >>>>
> >>>> Ie.
> >>>>
> >>>> .....
> >>>>
> >>>> <ServerTACACSPLUS>
> >>>> Identifier ouridentifier
> >>>> .....
> >>>> </Server>
> >>>>
> >>>> <Handler Client-Identifier=ouridentifier, Service-Type=Login-User>
> >>>> .....
> >>>> </Handler>
> >>>>
> >>>> .....
> >>>>
> >>>> regards
> >>>>
> >>>> Hugh
> >>>>
> >>>>
> >>>> On 25 Nov 2009, at 01:25, Alexander Hartmaier wrote:
> >>>>
> >>>>> Hi!
> >>>>>
> >>>>> I've configured Radiator according to 5.5.16 Identifier in the 4.4.1
> >>>>> manual:
> >>>>>
> >>>>> <Client DEFAULT>
> >>>>> Identifier ouridentifier
> >>>>> TACACSPLUSKey oursecret
> >>>>> DupInterval 60
> >>>>> </Client>
> >>>>>
> >>>>> But this handler doesn't match:
> >>>>>
> >>>>> <Handler Client-Identifier=outidentifier, Service-Type=Login-User>
> >>>>>
> >>>>> The fake radius packet looks like this:
> >>>>>
> >>>>> Attributes:
> >>>>> NAS-IP-Address = 10.1.2.3
> >>>>> NAS-Port-Id = "tty322"
> >>>>> Calling-Station-Id = "1.2.3.4"
> >>>>> Service-Type = Login-User
> >>>>> User-Name = "username"
> >>>>> User-Password = **obscured**
> >>>>> OSC-Version-Identifier = "192"
> >>>>>
> >>>>> In ServerTACACSPLUS line 547 it seems this should work:
> >>>>>
> >>>>> $tp->{Client} = $self; # So you can use Client-Identifier check items
> >>>>>
> >>>>> Is this a bug or are I'm doing something wrong?
> >>>>>
> >>>>> --
> >>>>> Alexander Hartmaier <alexander.hartmaier at t-systems.at>
> >>>>> T-Systems Austria GesmbH
> >>>>>
> >>>>>
> >>>>>
> >>>>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
> >>>>> T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
> >>>>> Handelsgericht Wien, FN 79340b
> >>>>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
> >>>>> Notice: This e-mail contains information that is confidential and may be privileged.
> >>>>> If you are not the intended recipient, please notify the sender and then
> >>>>> delete this e-mail immediately.
> >>>>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
> >>>>> _______________________________________________
> >>>>> radiator mailing list
> >>>>> radiator at open.com.au
> >>>>> http://www.open.com.au/mailman/listinfo/radiator
> >>>>
> >>>>
> >>>>
> >>>> NB:
> >>>>
> >>>> Have you read the reference manual ("doc/ref.html")?
> >>>> Have you searched the mailing list archive (www.open.com.au/archives/radiator)?
> >>>> Have you had a quick look on Google (www.google.com)?
> >>>> Have you included a copy of your configuration file (no secrets),
> >>>> together with a trace 4 debug showing what is happening?
> >>>>
> >>>
> >>
> >>
> >>
> >> NB:
> >>
> >> Have you read the reference manual ("doc/ref.html")?
> >> Have you searched the mailing list archive (www.open.com.au/archives/radiator)?
> >> Have you had a quick look on Google (www.google.com)?
> >> Have you included a copy of your configuration file (no secrets),
> >> together with a trace 4 debug showing what is happening?
> >>
> >
>
>
>
> NB:
>
> Have you read the reference manual ("doc/ref.html")?
> Have you searched the mailing list archive (www.open.com.au/archives/radiator)?
> Have you had a quick look on Google (www.google.com)?
> Have you included a copy of your configuration file (no secrets),
> together with a trace 4 debug showing what is happening?
>
More information about the radiator
mailing list