(RADIATOR) Limiting time before reconnection

Ayotunde Itayemi aitayemi at metrong.com
Wed Apr 9 06:32:56 CDT 2003


Hi Hugh,

How about putting a field that logs the time the user disconnects
({Acct-Session-Time})
(ACCTSESSTIME) in the accouting section then checking this in your
Authentication section.
Something like:

For accouting:
<AuthBy SQL>
        HandleAcctStatusTypes Stop
        AuthSelect
AcctSQLStatement insert into accoutingtable values ( \
        %{Acct-Session-Time}, ...
</AuthBy>

For Authentication:
<AuthBy ... >
 AuthSelect select PASSWORD, CHECKATTR, REPLYATTR \
  from SUBSCRIBERS where USERNAME = '%n'  and \
  (current-system-time - ACCTSESSTIME >=180 or \
   ACCTSESSTIME = 0)
</Auth>

I am sure Hugh can tell us what parameter returns the time radiator
received the access-request-packet (current-system-time) (too lazy to check
myself :-)

NOTES
1. current-system-time is the time the access-request packet is received by
radiator
2. or ACCTSESSTIME = 0 ( is for first time logon) otherwise a new client
will not
    be able to connect at all. Alternatively set this value to 180 or
something when
    you create a new user record in your user database then you don't need
the
    "or ACCTSESSTIME = 0" clause.

Regards,
Tunde I.


----- Original Message -----
From: "Hugh Irvine" <hugh at open.com.au>
To: "Nick M. Black" <nickb at mcspl.com.au>
Cc: <radiator at open.com.au>
Sent: Tuesday, April 08, 2003 9:33 AM
Subject: Re: (RADIATOR) Limiting time before reconnection


>
> Hello Nick -
>
> I can't think of an easy way to do this - any one else?
>
> regards
>
> Hugh
>
>
> On Tuesday, Apr 8, 2003, at 18:05 Australia/Melbourne, Nick M. Black
> wrote:
>
> > Hi,
> >
> > Is there a simple way to stop a user who has been disconnected due to a
> > session timeout from being reconnected within a certain time period ???
> > Or even better, to stop abuse, anyone who has been connected for, say,
> > greater than 30 minutes be stopped from reconnecting.
> >
> > We are using Platypus with RadiusNT, and AuthBy EMERALD. I am guessing
> > it can be done using AuthSelect - am I going on the right lines??
> >
> > We are currently using Radiator 2.19 running on Redhat 7.3 with freetds
> > 0.53, but I was thinking of upgrading to Radiator 3.5 as it will also
> > solve another problem I have
> >
> > Thanks in advance
> >
> > Nick Black
> > ===
> > 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 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 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.

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