(RADIATOR) No Access-Reject but a different profile
Hugh Irvine
hugh at open.com.au
Thu Dec 8 17:09:56 CST 2005
Hello Toomas -
Thanks for your thoughtful mail.
The problem is intermediate tracking of individual AuthBy results in
a sequence of AuthBy's.
Mike and I have discussed this several times in the past and we have
not managed to come up with any solution that is easily applicable,
easily configurable and easily understandable.
What I tend to do in my consulting practice is to use things like
stored procedures in the database (if supported) and/or AuthBy
INTERNAL clauses with hooks that do whatever is required (ie. calling
other AuthBy clauses, checking results, logging and so forth).
There are examples showing some of these things in "goodies/hooks.txt".
regards
Hugh
On 8 Dec 2005, at 20:30, Toomas Kärner wrote:
> Hello Hugh,
>
> My testings have led me to understanding that Reply-Message will be
> inserted
> into reply in the very end of processing and based on conditions that
> RejectHasReason is set and reply is Access-Reject. I could not get
> reply
> message in any way in between two AuthBy's because it's probably
> too early
> (final decision is not made jet because there are more AuthBy-s to go
> through) and in the end I can not get it because last AuthBy turned
> it into
> Access-Accept (no point in "RejectHasReason" because it wasn't
> reject).
> I still had to turn to PostAuthHook, that turns Reject into Accept and
> inserts necessary parameters. It inserts original reject_reason
> Reply-Message (if possible then err_code also) into Class so that
> it can be
> logged into Accounting and shown on error-portal that will be
> displayd to
> user (mulilingual based on err_code).
> If radiator code could be changed in the way that Reply-Message is
> set into
> reply packet that is beeing constructed on the moment of first
> AuthBy reject
> and then be filtered out if RejectHasReason is NOT set or it is
> Access-Accept then my code would have worked. This Reply message
> would also
> have to change if any other following AuthBy gives Reject. Let me
> know it
> that coul be possible. I dont see any side-effects of that change.
> Let me
> know what you think.
>
> 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