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

[Alexander Hartmaier]

Hi Andrew!

Should this PreHandlerHook used in the Client or the ServerTACACSPLUS
config section?
According to the manual it's valid in both places, but neither works for
me.

I've only a <Client DEFAULT> section at the moment which has an
identifier, but this isn't added.

I also don't see the debug log messages from your hook in a level 4
trace.

-- 
Best regards, Alex


Am Mittwoch, den 25.11.2009, 17:14 +0100 schrieb Andrew D. Clark:
> Here's one I use to do it:
> 
> # $Id: tacacs_client_identifier,v 1.3 2009/11/11 16:29:38 adc Exp $
> 
> # PreHandlerHook to pull the Identifier out of the client clause
> # for TACACS+ clients.  The Identifier is then added to the request
> # in the 'OSC-Client-Identifier' VSA
> 
> sub {
>         my $p = ${$_[0]};
>         my $hook_name = 'tacacs_client_identifier';
> 
>         &main::log($main::LOG_DEBUG, "Hook $hook_name called");
> 
>         my $client_addr = $p->get_attr('NAS-IP-Address');
>         my $client = Radius::Client::findAddress($client_addr);
> 
>         &main::log($main::LOG_DEBUG, "Hook $hook_name searching for client 
> <$client_addr>");
>         &main::log($main::LOG_DEBUG, "Hook $hook_name got client ident 
> <$client->{'Identifier'}>");
> 
>         $p->add_attr('OSC-Client-Identifier', $client->{'Identifier'});
> 
>         return;
> }
> 
> 
> On Wednesday 25 November 2009 04:49:57 Hugh Irvine wrote:
> > 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.
> > >
> > >> 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?
> > 
>