(RADIATOR) No Access-Reject but a different profile
Hugh Irvine
hugh at open.com.au
Thu Dec 8 17:45:12 CST 2005
Hello Toomas -
Thanks for another interesting mail.
Mike and I have discussed this also, and at the moment we are not
convinced that we want to extend the AuthColumnDef syntax.
We will keep thinking about it however.
regards
Hugh
On 8 Dec 2005, at 20:37, Toomas Kärner wrote:
> 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.
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.
More information about the radiator
mailing list