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