[RADIATOR] Client-Identifier doesn't match handler for Tacacs requests

[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?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.