[RADIATOR] ServerTACACSPLUS and Client-Identifier
Hugh Irvine
hugh at open.com.au
Thu Apr 23 03:37:46 CDT 2009
Hello Steve -
You will need to do a "find" to get the correct Client object first.
The Client as far as TACACS+ is concerned is the ServerTACACSPLUS
clause itself.
Here is an example that tests fine on my machine with Radiator 4.4.
#
# client.pl
#
sub
{
my $p = ${$_[0]};
my $nasip = $p->get_attr('NAS-IP-Address');
my $nas = Radius::Util::inet_pton($nasip);
my $client = Radius::Client::findAddress($nas);
my $identifier = $client->{Identifier};
print "Identifier is $identifier\n";
}
This assumes of course that the NAS-IP-Address is present in the
derived RADIUS request.
See my other example hooks in "goodies/hooks.txt".
regards
Hugh
On 23 Apr 2009, at 16:39, Steve Rogers wrote:
> 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.
>
>
>
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