(RADIATOR) No Access-Reject but a different profile

[Hugh Irvine]

Hello Toomas -

This is very simple to do with a PostAuthHook.

Here is an example I wrote for another customer which should give you  
the idea:


# postauth.pl
# Hugh Irvine, 20051129

sub
{
     my $p = ${$_[0]};
     my $rp = ${$_[1]};
     my $handled = $_[2];
     my $reason = $_[3];

     return unless ${$handled} == $main::REJECT || ${$handled} ==  
$main::REJECT_IMMEDIATE;

     return unless ${$reason} =~ 'Simultaneous-Use' || ${$reason} =~  
'Check item';

     # Set the Identifier
     my $identifier = 'AllocateIPAddress';
     &main::log($main::LOG_DEBUG, "Using Identifier $identifier");

     # Find the AuthBy clause with the same Identifier
     my $authby = Radius::AuthGeneric::find($identifier);

     if (defined $authby)
     {
         &main::log($main::LOG_DEBUG, "Found AuthBy with Identifier  
$identifier");

         # add the PoolHint to the reply
         $rp->add_attr('Framed-Pool', 'RESTRICTED');

         # Call handle_request for this AuthBy DYNADDRESS
         my $rc = $authby->handle_request($p, $rp);

         if ($rc == $main::ACCEPT)
         {
             &main::log($main::LOG_DEBUG, "Allocate IP address  
succeeded");
             $$handled = $main::ACCEPT;
             $$reason = 'Conditional ACCEPT';
         }
     }
     else
     {
         &main::log($main::LOG_ERR, "No AuthBy with Identifier  
$identifier found for address allocation");
     }
     return;
}


This code checks the result of the previous AuthBy(s) and the reject  
reason and in certain circumstances allocates an IP address from the  
RESTRICTED pool and returns an Access-Accept. You can add additional  
reply attributes as required and of course you don't need to do the  
address allocation if your address pools are defined on your NAS  
equipment.

Please let me know how you get on.

hope that helps

regards

Hugh


On 5 Dec 2005, at 20:30, Toomas Kärner wrote:

> Hi,
>
> I'm gathering my thoughts on solution that would rather give a  
> scpecific set
> of parameters to a user upon a "failed" login rather than Access- 
> Reject.
> These profiles should also be different depending on the cause of  
> "failure"
> and in some cases it still should give Access-Reject.
> It's part of my plan to get HD call levels lower - if thses  
> profiles will
> direct subscriber to a "educational" web page for that specific  
> error that
> he/she encountered then there would be no reason to call. Also it  
> would
> reduce the load on radius servers since logged in router causes no  
> load but
> once-in-a-second-trying router causes load. If it would get in I  
> would get
> rid of that extra load.
> I have several (better and worse) ways of doing it but I'd like to  
> get some
> other opinions.
> Let me know how YOU would do this. It would probably benefit us all.
>
> Rgds.
> Toomas
>
> --
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.


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: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
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.


--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.