RE: How to define time limited access?
Raymond Richmond (richmond@cronus.oanet.com)
Fri, 9 Aug 1996 01:36:36 -0600 (MDT)
I must agree, using the plainest configuration of RADIUS, we do the time
based control from separate user management software. The management
system imports time logs every 10 minutes and updates each users info on
an SQL server. When user X uses his allotted time period Y (configurable
on a per user basis) the system stops exporting the radius entry until the
next billing cycle of when user requests it reactivated.
This works because our user file is created from the server every
10 minutes. If the user is still within allotted time the server builds
the radius entry and exports it, as long as it is exported they log in.
The worst "miss" we have had was a user stayed logged in for about
6 hours solid and went over time.
Trying to hack RADIUS to add these "features" is simply asking for
a bulky, sluggish and unwieldy system. As it stands RADIUS is efficient,
straightforward to use and offers a VERY wide range of configuration
options IF you plan your system ahead of time rather than adding on more
and more.
On Fri, 9 Aug 1996, Matt Zimmerman wrote:
> On Thu, 8 Aug 1996, Rhudi wrote:
>
> > again, a hack for yet another desparately needed feature.
>
> A desperately needed feature of _what_? ComOS? I think not. RADIUS, in
> any of its forms? Doubtful. RADIUS is a means for exchange of
> authentication and accounting information between an NAS and one or more
> authentication/accounting servers. That is all. A purist RADIUS [server]
> implementation need not even maintain any state information about the