Brett Maxfield <[EMAIL PROTECTED]> wrote: > My understanding is that authentication basically happens once, at > logon. What i would like is for some external agent (not radius) to > create a list of online users (via SNMP or Telnet/Finger) and > periodically re-query that list of users against the radius server to > see if they would be authenticated, based on the current situation.
That's problematic, and I'm not sure it's a good idea. Do you really want to simplify the work of writing and enforcing timeouts in an application, by increasing the load on the RADIUS server and the network? > One solution would be to calculate the session time until the next time > the authentication would fail, say 12pm on sunday at logon. I guess this > could be dne with scripts, but it makes the assumption you counter is > time for which there is a control. The Session-Timeout attribute is supposed to be used by any RADIUS client to control session timeouts. If the application ignores this attribute, and implements timeouts via some other method, then it's broken. > This particular would fall down if you wanted to immediately stop a user > when they went over something like a bytes-downloaded-per-day counter. Which isn't a standard RADIUS attribute, precisely because it's so hard to administer. > Generic re-authorization would also allow you to kick off a user after > setting them to be disabled, as the next status check would have them > kicked off because they would fail authorization at that time. Then the application should take care of re-authorization. It's difficult for the RADIUS server to know when to kick the user off, which is why there's no standard 'radkill'. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
