A couple of months ago I worked out a way of limiting users to one 15-minute period per day based on their MAC address -- I tested it, and it worked just fine. Yesterday someone asked me how many times they could use the "promo" code in a day, and I said "once", and he had this odd mischievious smile, which prompted me to join the "made me look" club -- sure enough, the accounting log records are showing multiple instances in the same day for the same MAC address, yet I have made "no" changes to the configuration files.
Here are the relevant portions of my configuration files [still using 0.8 -- I
haven't found a free weekend to upgrade to 0.9, and now I see 0.9.1 is
out...]
under modules :
counter dailytime{
filename = ${raddbdir}/db.daily
key = Calling-Station-Id
count-attribute = Acct-Session-Time
reset = daily
counter-name = daily-session-time
check-name = daily-time-limit
cache-size = 5000
}
under instantiate:
dailytime
lifetime
sessions
[lifetime is a "reset=never" style counter, sessions is similar to dailytime,
but the count-attribute is session-type instead of time -- that was before I
found out that counters had an undocumented side effect of setting the
"session-limit" to the difference between the actual limit and the
accumulated-count -- made for very short session with "max-daily-limit := 1"
:) ]
under authorize:
# attr_filter
# eap
suffix
files
sql
dailytime
lifetime
sessions
# etc_smbpasswd
and finally accounting:
acct_unique
detail
unix # wtmp file
sql
radutmp
dailytime
lifetime
sessions
# sradutmp
[note: for the most part, the configuration file is unchanged from the
"sample" provided in the package]
the "users" file [since "files" comes first in the scheme of things] is like
most of the rest of the configuration files -- basically unchanged;
effectively the only thing being set is "auth-type := system" for all users
[which gets overridden in the SQL database anyway]
For the sql part, I have the following entries for the group "promo":
radgroupcheck:
groupname,attribute,op,value
promo,daily-time-limit,:=,900
promo,Auth-Type,:=,Local
usergroup:
username,groupname
higleys,promo
radcheck
username,attribute,op,value
higleys,password,==,coffee
This is using the "regular" DB counter, not the sql-counter module [it wasn't
listed as entirely stable for 0.8, and yes, I'm aware of a known bug with
"reset=never", but for the most part, the radius server runs 24x7 -- as such,
I've only encountered one incident when a "reset=never" user ID has been
re-used]
Where should I begin looking for how and why this "reset=daily" counter
doesn't seem to be getting applied [and no, "run in debug mode" is not an
acceptible answer -- this is a PRODUCTION machine]
FWIW: the log file isn't much help -- it shows this counter both works and
doesn't work:
Tue Sep 2 12:13:57 2003 : Auth: Login OK: [higleys] (from client
higleyscoffee port 0 cli 00-04-E2-07-EC-31)
Tue Sep 2 15:48:04 2003 : Auth: Login OK: [higleys] (from client
higleyscoffee port 0 cli 00-04-E2-07-EC-31) <= this should have been denied
Tue Sep 2 20:55:20 2003 : Auth: Login OK: [higleys] (from client
higleyscoffee port 0 cli 00-0B-CD-75-46-9B)
Tue Sep 2 21:11:01 2003 : Auth: Login OK: [higleys] (from client
higleyscoffee port 0 cli 00-0B-CD-75-46-9B) <= likewise!!!
Tue Sep 2 21:26:44 2003 : Info: rlm_sql (sql): Pairs do not match for user
[higleys]
Tue Sep 2 21:26:44 2003 : Auth: Login incorrect: [higleys/cofee] (from client
higleyscoffee port 0 cli 00-0B-CD-75-46-9B) <== ok, user mistype password
Tue Sep 2 21:27:15 2003 : Auth: Login OK: [higleys] (from client
higleyscoffee port 0 cli 00-0B-CD-75-46-9B) <== however this should have
been denied as the 15 minutes have already been "used" by this MAC
Tue Sep 2 21:29:28 2003 : Auth: Invalid user (rlm_counter: Maximum daily
usage time reached): [higleys/coffee] (from client higleyscoffee port 0 cli
00-0B-CD-75-46-9B) <== finally it gets denied
--
Yet another Blog: http://osnut.homelinux.net
pgp00000.pgp
Description: signature
