Expiration - my experiences and a partial solution
Tomas 'tt' krag
tt at krag.org
Wed Jun 15 00:40:58 CEST 2005
Hi,
I spent a few days working on a freeradius solution in which I want to
be able to create users whose logins expire 24 hours after their first
login. Since I noticed that many people have been asking for similar
things on this list, I thought I'd explain the solution I have ended up
using.
NOTE: This solution is far from perfect. First of all, it is a hack, and
not too elegant, secondly it does not do exactly what it is supposed to
do, but it works well enough for my purposes, and perhaps other people
can use this as inspiration for an improved solution.
WARNING: I am far from proficient at freeradius, having spent only the
past week trying to get an understanding of how it works. This solution
was hacked together from various comments and ideas on this
mailing-list. So anything I say and do should be considered risky :-)
What I wanted was to be able to create a number of users, printed on
cards, that I could hand out to users at an event to let them access the
network for 24 hours after the first time they logged in. i.e. if they
log in at 15:31 on tuesday their account should expire at 15:31 on
wednesday no matter how much time they have spent on-line.
I am using chillispot and freeradius with mysql, all on one central
gateway server, as this is a small setup with a limited number of
users.
I had understood from comments by Kostas Kalevras and Alan DeKok
(thanks) that the way to do this in freeradius/mysql was to use a
post-auth query that executed whenever a user has successfully logged
into the system. In that post-auth query I would set an Attribute/Value
pair "Expiration := 25 May 2005 15:31" or equivalent in the radcheck
table of the database. Since I didn't want this to apply to all users (I
like to
keep a permanent login for myself), I needed some way to distinguish
users that should be timed out from other users.
I came up with the following hack.
When I generate the usernames (using a adapted version of phpMyPrepaid
http://www.jabali.net/~carl/?link=2) I add an Attribute called
Expiration with a value well in the future. In this case "Expiration:='1
Jan 2005'".
When a user logs in I check if there is an Expiration attribute with
that particular value, and if so, I change the Date to exactly 24 hours
from Now. I do this in sql.conf by adding the following query:
postauth_query = "UPDATE ${authcheck_table} SET
Value=DATE_FORMAT(DATE_ADD(NOW(),INTERVAL ${expire} HOUR),'%%e %%b %%Y %
%T') WHERE UserName='%{SQL-User-Name}' AND Attribute='Expiration' AND
Value='${expiration_dummy}'"
At the top of the file, I have defined the following
# Added by tkrag (support for Expiration)
# The dummy expiration value used when creating new
# users
expiration_dummy = "1 Jan 2099"
# How many hours an account lasts from first login
expire = 24
This has the effect of changing the Expiration date only the first time
a user logs in.
Unfortunately as Joachim Bloche pointed out in a mail "Session-Timeout
not set with pending Expiration" on this list, it seems that Freeradius
does NOT set the "Session-Timeout" based on an Expiration date in the
future.
I have confirmed this behaviour using freeradius 1.0.1 (from the ubuntu
package, but recompiled to support the rlm_sqlcounter module).
This effectively means that a user who logs in at 13:30 on tuesday and
logs in again at 13:29 on wednesday can then stay on-line after the
Expiration time, but cannot log back in again after that time.
In my situation I have handled this by also using an sqlcounter with an
Attribute "Max-All-Session := 86400" which then limits the user to a
total of 24 hours on-line. i.e. a user could login at 13:30 on tuesday
and immediately log out, after which she could relogin at 13:29 on
wednesaday and stay connected for another 24 hours until 13:29 on
thursday. In my case this is not a deal-breaker, as we are not selling
access, but mostly
trying to protect ourselves against ongoing abuse of bandwidth, but in
other scenarios it might not work well.
If I read the documentation correctly the current CVS version of
freeradius contains a new module called rlm_expiration which apparently
moves the Expiration support into a separate module, and will hopefully
support returning the correct Session-Timeout attribute.
I hope this helps someone out there.
Regards
/tomas
wire.less.dk
More information about the Freeradius-Users
mailing list