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

Dave Kitabjian dave at netcarrier.com
Thu Dec 3 07:51:03 CST 2009


My understanding is that they show you the raw packet (as it comes in).
If you think about it, no matter where they dump the packet, there will
be other places where we'll want to see the values, depending on many
things.

What we do is add a print statement to echo any attribute changes we
make to the debug log. Then we can "trace" specific attribute values,
where they get changed, and what there values are at specific points in
processing.

Dave

-----Original Message-----
From: radiator-bounces at open.com.au [mailto:radiator-bounces at open.com.au]
On Behalf Of Alexander Hartmaier
Sent: Thursday, December 03, 2009 6:12 AM
To: Andrew D. Clark
Cc: radiator at open.com.au
Subject: Re: [RADIATOR] Client-Identifier doesn't match handler for
Tacacs requests

Forget my previous mail, the hook didn't compile properly because I've
forgot to add \ to the end of every line.

I've moved the code to a separate file and use it with PreHandlerHook
file:"%D/tacacs_client_identifier.hook" in my ServerTACACSPLUS section.

@Radiator guys: it's a bit irritating that the packet dump is printed
before the hook executes. Maybe it should be printed after some handlers
have run or a second time before the handler decision is made to ease
debugging.

-- 
Best regards, Alex


Am Donnerstag, den 03.12.2009, 11:47 +0100 schrieb Hartmaier Alexander:
> 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?
> > > 
> > 
> 
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator

_______________________________________________
radiator mailing list
radiator at open.com.au
http://www.open.com.au/mailman/listinfo/radiator




More information about the radiator mailing list