(RADIATOR) No Access-Reject but a different profile

Toomas Kärner tomkar at estpak.ee
Thu Dec 8 03:37:43 CST 2005


And another idea.

It would be extra super if AuthColumnDef's format could be extended so that
there would be extra fielt in the end of it like this:
        AuthColumnDef   0,      My-attribute, check, "You have no plaplapla"
And if that check fails then this would be given as Reply-Message (if
RejectHasReason and so on).
In case of reply or request type of field, it could be used as "default"
value if SQL returns NULL for this field.
For example:
        AuthColumnDef   0,      Rate-Limit-Rate, reply, 256kbps
Sound nice, doesn't it ?

Rgds.
Toomas

----- Original Message ----- 
From: "Hugh Irvine" <hugh at open.com.au>
To: "Toomas Kärner" <tomkar at estpak.ee>
Cc: <radiator at open.com.au>
Sent: Thursday, December 08, 2005 12:36 AM
Subject: Re: (RADIATOR) No Access-Reject but a different profile


>
> Hello Toomas -
>
> Yes you will need to add your message to the request packet in the
> previous AuthBy.
>
> Note that you can use any name you wish for this "pseudo-attribute".
>
> regards
>
> Hugh
>
>
> On 7 Dec 2005, at 21:12, Toomas Kärner wrote:
>
> > I'm getting somewhere but I'm little stuck (I know a workaround
> > already bu I
> > dont like it because it involves hook).
> > Config of a special AuthBy that will find special profile to your
> > user if it
> > got denied
> > <AuthBy SQL>
> >         Identifier      AuthAccept
> >         DBSource        dbi:mysql:
> >         DBUsername
> >         DBAuth
> >         AuthSelect      select
> > in_policy,out_policy,qos_profile,timeout,idle_timeout, \
> >                         from denyprofiles \
> >                         where MESSAGE = '%{Reply:Reply-Message}'
> >         AuthColumnDef   0,      ERX-Ingress-Policy-Name, reply
> >         AuthColumnDef   1,      ERX-Egress-Policy-Name, reply
> >         AuthColumnDef   2,      ERX-QoS-Profile-Name, reply
> >         AuthColumnDef   3,      Session-Timeout, reply
> >         AuthColumnDef   4,      Idle-Timeout, reply
> >         AcceptIfMissing
> >         NoDefault
> > </AuthBy>
> > It "should" work but in log I see:
> > Wed Dec  7 09:57:58 2005: DEBUG: AuthBy SQL result: REJECT, Bad
> > Password
> > (result from earlier AuthBy's)
> > Wed Dec  7 09:57:58 2005: DEBUG: Handling with Radius::AuthSQL
> > Wed Dec  7 09:57:58 2005: DEBUG: Handling with Radius::AuthSQL:
> > AuthAccept
> > Wed Dec  7 09:57:58 2005: DEBUG: Query is: 'select
> > in_policy,out_policy,qos_profile,timeout,idle_timeout from
> > denyprofiles
> > where MESSAGE = ''':
> >
> > Message contains emty string for some reason...
> > Its probably because auth_result_message gets inserted into reply
> > (as a
> > Reply-Message) in the very late stage of processing.
> > Workaround could be by fetching it and puting it into request before
> > executing AuthSelect and then doing AuthSelect with the Reply-
> > Message from
> > the request.
> >
> > Let me know what you think.
> >
> > Rgds.
> > Toomas
> >
> > ----- Original Message -----
> > From: "Toomas Kärner" <tomkar at estpak.ee>
> > To: "Hugh Irvine" <hugh at open.com.au>
> > Cc: <radiator at open.com.au>
> > Sent: Tuesday, December 06, 2005 2:37 PM
> > Subject: Re: (RADIATOR) No Access-Reject but a different profile
> >
> >
> >> Hi Hugh,
> >>
> >> I had such a "magic" in the PostAuthHook but I'd like to rid of it
> >> there
> > and
> >> do it more with config :). Sound weird? haa ... you haven't seen my
> >> implementation ways of radiator :D I have some ideas already. I'll
> >> how
> > they
> >> work out and let you know.
> >>
> >> Rgds.
> >> Toomas
> >>
> >>
> >> ----- Original Message -----
> >> From: "Hugh Irvine" <hugh at open.com.au>
> >> To: "Toomas Kärner" <tomkar at estpak.ee>
> >> Cc: <radiator at open.com.au>
> >> Sent: Tuesday, December 06, 2005 12:28 AM
> >> Subject: Re: (RADIATOR) No Access-Reject but a different profile
> >>
> >>
> >>>
> >>> 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.
> >>
> >> --
> >> 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.

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


More information about the radiator mailing list