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

[Mariano Absatz]

El 28 May 2001, a las 10:25, Hugh Irvine escribió:

> 
> 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!  :-)
FTR, I DID read all of the manual when we bought Radiator (it was 2.16.3, 
then), but anyway, you allways do the reading with some short vision and some 
things you read either you forget or it goes somewhere in the bottom of your 
mind from where you get the feeling you know something, but not quite well... 
:-)

> 
> > 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".
I'm quick-browsing this file and can't find how to do this... how do I invoke 
an <AuthBy XXX> from inside a hook?


> 
> > 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
Great!! I didn't see THIS in the manual... now I'm searching for ", request" 
and only find it in 6.33.14 AuthAttrDef (in LDAP) and NOT in 6.26.7 
AuthColumnDef (in SQL)... maybe a little comment/example in the next release 
of the manual? :-)

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

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


Mariano Absatz
El Baby
----------------------------------------------------------
This message transmitted on 100% recycled electrons. 

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