(RADIATOR) inter-AuthBy's hook and other stuff

[Hugh Irvine]

Hello Mariano -

On Monday 28 May 2001 06:16, Mariano Absatz wrote:
> Hi,
>
> I'm reading the section 19.0 "Execution sequence and Hook processing" from
> the Radiator manual and the execution sequence reads like:
>

I'm very pleased to see you reading the manual!  :-)

> 14. Accounting log files (AcctLogFileName and WtmpFileName) written
> 15. PreAuthHook called
> 16. AuthBy clauses invoked
> 17. PostAuthHook called
> 18. Reply sent to NAS (unless request was proxied)
>
> What I want is the possibility to have a "PostTHISAuthByHook" that executes
> AFTER a specific AuthBy but BEFORE the next one (inside an AuthByPolicy
> block).
>

There is no provision for this in the standard code.

> That is, I would like to check stuff returned by a specific AuthBy... and
> maybe decide I will change the result of that AuthBy (from accept to reject
> or something else).
>
> How can I do this?
>

I would suggest that you use a PostAuthHook which itself will call one or 
more supplementary AuthBy clauses, check the result(s) and do whatever is 
required. There are examples of how to do this sort of thing in the file 
"goodies/hooks.txt".

> Also, I would like to add certain stuff I'm SELECTing in an AuthSelect to
> the RequestPacket... can I do this?
>
> As far as I understand, if I put
>     AuthColumnDef 3, Some-Attr, reply
> it will add the 4th column from my select to the ReplyPacket as the
> Some-Attr attribute.
>
> But, if I use
>     AuthColumnDef 3, Some-Attr, check
> it will CHECK the 4th column from my select to the RequestPacket and FAIL
> if it doesn't match.
>
> I want to temporarly store this attribute to do some processing afterwards
> (e.g. because the "checking" is more complicated than a simple x=y). I
> remember Hugh said that it's better to store this temporary data in the
> RequestPacket (which will be deleted after its processing finishes) than in
> the ReplyPacket (from where I do have to manually delete them before I send
> it back to the NAS).
>
> In this particular case, I am getting a column that has a regexp against
> which to match the Calling-Station-Id and another against which to match
> the Called-Station-Id. The point is that, this stuff is not very reliable
> (depending on how the call is routed and a bunch of other things, the
> caller- ID might be different, at least the first few digits), and I want
> to give more flexibility (this user can call from a bunch of different
> number, e.g. all the out-dial numbers of a PABX).
>
> I intend to do a "~=" in a hook after getting this data, but
> 1) don't want to manually delete it from the reply, and
> 2) don't want to wait 'till other AuthBy's are executed before rejecting an
> invalid call.
>
> Am I completely off-base with this?
>
> Has anyone done something like this?
>
> FYI, all my AuthBy's are SQL's against an Oracle DB.
>

You should use this construct to put something into the request packet:

     AuthColumnDef 3, Some-Attr, request

> I intend to:
> 1) check username/realm/password validity and, in the same AuthSelect,
> would get a propietary service-code, max # of ports for this realm AND this
> service- code AND this valid-DNIS-set, valid DNIS and Caller-ID,
> simultaneous-use (for this user), etc.
>

Fine.

> 2) if that passes, I will PORTLIMITCHECK based on the realm/max # of
> ports/service-code/valid-DNIS-set
>

Fine.

> 3) if that passes AND the user had not been assigned a fixed-IP address (in
> 1), I will select a DYNADDRESS based on service-code/NAS-Identifier
> (service- code's define, among other stuff, a QOS that will be applied
> differently to different IP address pools.
>

You can quite happily call an AuthBy DYNADDRESS in this situation, as the 
first thing it does is check for the presence of a Framed-IP-Address in the 
reply packet, and if it finds one it simply returns. An AuthBy DYNADDRESS 
will only try to allocate an address if one is needed, ie. if there is no 
Framed-IP-Address present in the reply.

hth

Hugh


-- 
Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
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.