[RADIATOR] ServerTACACSPLUS and Client-Identifier

Hugh Irvine hugh at open.com.au
Thu Apr 23 03:44:18 CDT 2009


Hello Alex, Hello Steve -

You are both right.

;-)

Historically Radiator only supported a single ServerTACACSPLUS  
definition with a single key.

More recently we have added support for the sorts of things Steve  
needs by adding parameters to what are normally RADIUS <Client ....>  
clauses.

regards

Hugh


On 23 Apr 2009, at 18:17, Steve Rogers wrote:

> Hi Alex,
>
> We have to use per client TACACS keys and Radiator supports this. We  
> are also supporting different hardware vendors and their TACACS  
> implementations from the same TACACS server so have some reliance on  
> the Client definitions. It's challenging !
>
> Cheers
> Steve
>
> On Thu, Apr 23, 2009 at 8:48 AM, Alexander Hartmaier <alexander.hartmaier at t-systems.at 
> > wrote:
> Afaik the tacacs part of Radiator doesn't need and also doesn't care
> about Client sections because the Tacacs key is per server and not per
> client.
>
> --
> BR Alex
>
>
> Am Donnerstag, den 23.04.2009, 08:39 +0200 schrieb Steve Rogers:
> > Hi Hugh,
> >
> >
> > We have this in the PostAuthHook code - shown below. Also I've
> > attached a debug output extract showing the Client Identifier being
> > null. And the Client definition. If we do a data dumper of
> > $p->{Client} we don't see the Identifier.
> >
> >
> > Any further suggestions we could look at?
> >
> >
> > <Client 192.168.X.X>
> >         Identifier noncisco
> >         TACACSPLUSKey XXXXXX
> > </Client>
> >
> >
> > sub
> > {
> > my $p = ${$_[0]};
> > my $rp = ${$_[1]};
> > my $result = ${$_[2]};
> >
> >
> > my $authGrp;
> > my $tacAttr = 'tacplusgrp';
> >
> > if (($result == $main::ACCEPT) && ($authGrp =
> > $rp->get_attr($tacAttr)))
> > {
> > my $clientId = $p->{Client}->{Identifier};
> > &main::log($main::LOG_DEBUG, "Client Identifier = $clientId");
> > $authGrp .= '-'.$clientId;
> > $rp->change_attr($tacAttr, "$authGrp");
> > &main::log($main::LOG_DEBUG, "TACACS group = $authGrp");
> > }
> > }
> >
> >
> >
> >
> > Thu Apr 23 07:26:19 2009: DEBUG: Handling request with Handler ''
> > Thu Apr 23 07:26:19 2009: DEBUG:  Deleting session for sr,
> > 192.168.0.99,
> > Thu Apr 23 07:26:19 2009: DEBUG: Handling with Radius::AuthFILE:
> > Thu Apr 23 07:26:19 2009: DEBUG: Reading users file /Radiator/users
> > Thu Apr 23 07:26:19 2009: DEBUG: Radius::AuthFILE looks for match  
> with
> > sr [sr]
> > Thu Apr 23 07:26:19 2009: DEBUG: Expiration date converted to:
> > 1264723200
> > Thu Apr 23 07:26:19 2009: DEBUG: Radius::AuthFILE ACCEPT: : sr [sr]
> > Thu Apr 23 07:26:19 2009: DEBUG: AuthBy FILE result: ACCEPT,
> > Thu Apr 23 07:26:19 2009: DEBUG: Client Identifier =
> > Thu Apr 23 07:26:19 2009: DEBUG: TACACS group = TACACSAdmins-
> > Thu Apr 23 07:26:19 2009: DEBUG: Access accepted for sr
> > Thu Apr 23 07:26:19 2009: DEBUG: Packet dump:
> > *** Reply to TACACSPLUS request:
> > Code:       Access-Accept
> > Identifier: UNDEF
> > Authentic:
> >  _<240><12><227><155><2><196>2<145><171><144>><194><20>y<227>
> > Attributes:
> >         tacplusgrp = TACACSAdmins-
> >
> >
> > Thu Apr 23 07:26:19 2009: DEBUG: TacacsplusConnection result
> > Access-Accept
> > Thu Apr 23 07:26:19 2009: DEBUG: TacacsplusConnection Authentication
> > REPLY 1, 0,
> >  ,
> > Thu Apr 23 07:26:19 2009: DEBUG: TacacsplusConnection request 192,  
> 2,
> > 1, 0, 2, 6
> > 3
> >
> >
> > Cheers
> > Steve
> >
> >
> >
> > On Thu, Apr 23, 2009 at 1:51 AM, Hugh Irvine <hugh at open.com.au>  
> wrote:
> >
> >         Hi Steve -
> >
> >         Try this:
> >
> >                .....
> >
> >                my $identifer = $p->{Client}->{Identifier};
> >
> >                .....
> >
> >         regards
> >
> >         Hugh
> >
> >
> >
> >
> >         On 22 Apr 2009, at 22:14, Steve Rogers wrote:
> >
> >
> >
> >                 Hi,
> >
> >                 We are using Radiator 4.4 with patches and  
> attempting
> >                 to get the Client-Identifier and use this in a  
> hook as
> >                 part of a Handler, but it doesn't seem to be
> >                 available. Doing a bit of debug, we see the  
> following
> >                 line from ServerTACACSPLUS.pm and we can retrieve  
> the
> >                 Client-Identifier at this point but appears that  
> when
> >                 the module creates the fake radius request and we  
> look
> >                 at the object passed to the PostAuthHook (${$_[0]}  
> we
> >                 cant seem to get this.
> >
> >                 $tp->{Client} = $self; # So you can use
> >                 Client-Identifier check items
> >
> >                 Is this possible? Or is there a simple mechanism to
> >                 use the originating Client-Identifier from the  
> Client
> >                 that the TACACS request came from?
> >
> >                 Appreciate any help or advise.
> >
> >                 Cheers
> >                 Steve
> >
> >                 _______________________________________________
> >                 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?
> >         Have you checked the RadiusExpert wiki:
> >         http://www.open.com.au/wiki/index.php/Main_Page
> >
> >         --
> >         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.
> >
> >
> >
> >
>
>
> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
> 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
>
> _______________________________________________
> 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?
Have you checked the RadiusExpert wiki:
http://www.open.com.au/wiki/index.php/Main_Page

-- 
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.




More information about the radiator mailing list