[RADIATOR] ServerTACACSPLUS and Client-Identifier

[Steve Rogers]

Hi Hugh,
Forgot to add that if we modify ServerTACACSPLUS.pm to include:

    $self->{Identifier} = $client->{Identifier}
if $client && !defined $self->{Identifier};

Then we can use the $p->{Client}->{Identifier}.

Is there any reason why the Identifier couldn't be added to
ServerTACACSPLUS.pm?

Here is the diff:

*** ServerTACACSPLUS.pm 2009-04-10 06:56:32.000000000 +0100
---  ServerTACACSPLUS.pm       2009-04-23 08:07:34.2908
50000 +0100
***************
*** 289,294 ****
--- 289,297 ----
      $client =
&Radius::Client::findAddress(Radius::Util::inet_pton($self->{pee
raddr}))
        unless $client;

+     $self->{Identifier} = $client->{Identifier}
+       if $client && !defined $self->{Identifier};
+
      $self->{Key} = $client->{TACACSPLUSKey}
          if $client && !defined $self->{Key};
      $self->{Key} = $parent->{Key}

Cheers
Steve

On Thu, Apr 23, 2009 at 7:39 AM, Steve Rogers <sterogers at gmail.com> 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.
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.open.com.au/pipermail/radiator/attachments/20090423/b86c6e7d/attachment-0001.html>