Re[3]: limiting sessions
...
DELETE FROM radius.usergroup WHERE GroupName = 'aroma'
THEN...
INSERT INTO radius.usergroup (UserName, CreationDate, GroupName)
VALUES ('username0001', (CURRENT_DATE), 'aroma');
repeated for all 500 usernames...
I think this should work, as all the usernames in use are stored in
radcheck and I'm not touching that table at all. Worst case scenario,
users continue to authenticate without a session limit and I go back
to work...
DOES THIS SOUND RIGHT?
Andrew
Well I think all the gurus let me swim alone on this one, and it
all worked out... now we have our 30 minutes session limits working!
Kevin... thanks for the clue!
Andrew
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re[5]: limiting sessions
Andrew Long [EMAIL PROTECTED] wrote: I tried Session-Timeout but it doesn't seem to do the job. So... is it being sent back to the NAS? If it is, then the NAS is ignoring it. Go ask your NAS manufacturer for a refund, or for a firmware upgrade that implements RADIUS. Alan DeKok. How would you suggest I verify the session-timeout is actually being sent/received? Andrew - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Re[5]: limiting sessions
radiusd -X in the debug mode you can see attributes that are being send back to you NAS. If you want to see what comes to NAS - please consult the documentation of your NAS ! Regards, E:S -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] g] On Behalf Of Andrew Long Sent: Donnerstag, 09. November 2006 14:51 To: Alan DeKok; FreeRadius users mailing list Subject: Re[5]: limiting sessions Andrew Long [EMAIL PROTECTED] wrote: I tried Session-Timeout but it doesn't seem to do the job. So... is it being sent back to the NAS? If it is, then the NAS is ignoring it. Go ask your NAS manufacturer for a refund, or for a firmware upgrade that implements RADIUS. Alan DeKok. How would you suggest I verify the session-timeout is actually being sent/received? Andrew - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Re[5]: limiting sessions
Andrew Long [EMAIL PROTECTED] wrote: How would you suggest I verify the session-timeout is actually being sent/received? tcpdump / wireshark? Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re[7]: limiting sessions
Andrew Long [EMAIL PROTECTED] wrote: I tried Session-Timeout but it doesn't seem to do the job. So... is it being sent back to the NAS? If it is, then the NAS is ignoring it. Go ask your NAS manufacturer for a refund, or for a firmware upgrade that implements RADIUS. Alan DeKok. How would you suggest I verify the session-timeout is actually being sent/received? Andrew radiusd -X in the debug mode you can see attributes that are being send back to you NAS. If you want to see what comes to NAS - please consult the documentation of your NAS ! Regards, E:S Here is the output from radiusd -X regarding the answer to an auth-request from one of the properties where I changed session-timeout to 1800. It does not look to me like the session-timeout attribute is being sent... any suggestions? = sample 1 (main street) == rad_recv: Access-Request packet from host 141.149.128.xx:1024, id=88, length=191 Acct-Session-Id = 54a4b76f NAS-Port = 3 NAS-Port-Type = Wireless-802.11 User-Name = 4aroma70370 Calling-Station-Id = 00-14-A5-71-1A-61 Called-Station-Id = 00-03-52-02-8C-F9 Framed-IP-Address = 192.168.110.101 CHAP-Password = [removed] CHAP-Challenge = [removed] NAS-Identifier = R035-00371 NAS-IP-Address = 141.149.128.58 Framed-MTU = 1496 Connect-Info = HTTPS Service-Type = Framed-User Message-Authenticator = 0xacd61ed325c0d7c91980dbf8bcf6ccdd modcall: entering group authorize for request 1 modcall[authorize]: module preprocess returns ok for request 1 rlm_chap: Setting 'Auth-Type := CHAP' modcall[authorize]: module chap returns ok for request 1 modcall[authorize]: module eap returns noop for request 1 rlm_realm: No '@' in User-Name = 4aroma70370, looking up realm NULL rlm_realm: No such realm NULL modcall[authorize]: module suffix returns noop for request 1 users: Matched DEFAULT at 177 modcall[authorize]: module files returns ok for request 1 modcall[authorize]: module mschap returns noop for request 1 radius_xlat: '4aroma70370' rlm_sql (sql): sql_set_user escaped user -- '4aroma70370' radius_xlat: 'SELECT id,UserName,Attribute,Value,op FROM radcheck WHERE Username = '4aroma70370' ORDER BY id' rlm_sql (sql): Reserving sql socket id: 3 radius_xlat: 'SELECT radgroupcheck.id,radgroupcheck.GroupName,radgroupcheck.Attribute,radgroupcheck.Value,radgroupcheck.op FROM radgroupcheck,usergroup WHERE usergroup.Username = '4aroma70370' AND usergroup.GroupName = radgroupcheck.GroupName ORDER BY radgroupcheck.id' radius_xlat: 'SELECT id,UserName,Attribute,Value,op FROM radreply WHERE Username = '4aroma70370' ORDER BY id' radius_xlat: 'SELECT radgroupreply.id,radgroupreply.GroupName,radgroupreply.Attribute,radgroupreply.Value,radgroupreply.op FROM radgroupreply,usergroup WHERE usergroup.Username = '4aroma70370' AND usergroup.GroupName = radgroupreply.GroupName ORDER BY radgroupreply.id' rlm_sql (sql): Released sql socket id: 3 modcall[authorize]: module sql returns ok for request 1 rlm_sqlcounter: Entering module authorize code rlm_sqlcounter: Could not find Check item value pair modcall[authorize]: module noresetcounter returns noop for request 1 rlm_sqlcounter: Entering module authorize code rlm_sqlcounter: Could not find Check item value pair modcall[authorize]: module dailycounter returns noop for request 1 rlm_sqlcounter: Entering module authorize code rlm_sqlcounter: Could not find Check item value pair modcall[authorize]: module monthlycounter returns noop for request 1 rlm_sqlcounter: Entering module authorize code rlm_sqlcounter: Could not find Check item value pair modcall[authorize]: module daypasscounter returns noop for request 1 modcall: group authorize returns ok for request 1 rad_check_password: Found Auth-Type CHAP auth: type CHAP modcall: entering group Auth-Type for request 1 rlm_chap: login attempt by 4aroma70370 with CHAP password rlm_chap: Using clear text password [removed] for user 4aroma70370 authentication. rlm_chap: chap user 4aroma70370 authenticated succesfully modcall[authenticate]: module chap returns ok for request 1 modcall: group Auth-Type returns ok for request 1 Sending Access-Accept of id 88 to 141.149.128.xx:1024 Framed-IP-Address = 255.255.255.254 Framed-MTU = 576 Service-Type = Framed-User Finished request 1 Going to the next request = end === Andrew - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: limiting sessions
On Thursday 09 November 2006 11:00, Andrew Long wrote: Here is the output from radiusd -X regarding the answer to an auth-request from one of the properties where I changed session-timeout to 1800. It does not look to me like the session-timeout attribute is being sent... any suggestions? Where are you setting Session-Timeout? If it is being added by an sql entry, run the queries shown in your debug output to verify the rows returned from the database are correct. What are the check and reply items for the section that contains the Session-Timeout attribute? Are they matching attributes in the Access-Request packet you sent? Kevin Bonner pgp2Wjcu4U6Qm.pgp Description: PGP signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re[2]: limiting sessions
On Thursday 09 November 2006 11:00, Andrew Long wrote: Here is the output from radiusd -X regarding the answer to an auth-request from one of the properties where I changed session-timeout to 1800. It does not look to me like the session-timeout attribute is being sent... any suggestions? Where are you setting Session-Timeout? If it is being added by an sql entry, run the queries shown in your debug output to verify the rows returned from the database are correct. What are the check and reply items for the section that contains the Session-Timeout attribute? Are they matching attributes in the Access-Request packet you sent? Kevin Bonner I grabbed the response from radius to an auth-request from aroma and it does not appear to include the session timeout attr-value pair, but it did authorize. So, I ran the query that the module ran (grabbed from the -x output) SELECT radgroupreply.id,radgroupreply.GroupName,radgroupreply.Attribute,radgroupreply.Value,radgroupreply.op FROM radgroupreply,usergroup WHERE usergroup.Username = '4aroma70370' AND usergroup.GroupName = radgroupreply.GroupName ORDER BY radgroupreply.id and found that it came up with a null set for that user when run against radgroupreply,usergroup (session-timout is in radgroupreply). Next, I looked in usergroup with SELECT `usergroup`.`UserName`, `usergroup`.`creationdate`, `usergroup`.`GroupName` from usergroup where username like '%aroma%' order by creationdate desc limit 1000; and found no pairs for recent aroma usernames and no entry for '4aroma70370'. also ran SELECT `usergroup`.`UserName`, `usergroup`.`creationdate`, `usergroup`.`GroupName` from usergroup where username = '4aroma70370'; and that also comes up null... Does it make sense that radius is not recognizing the usernames as belonging to the group 'aroma', thus not assigning the group-reply? This is my current thought on this, but I'm not sure why it would still authorize the request, unless it's not necessary that users be part of group. I am thinking that some usernames were created and added to the radcheck table but were overlooked in usergroup... -- Regards, Andrew - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: limiting sessions
* Try to respond just to the list and not me personally. I don't enjoy wading through duplicate messages. Thanks! On Thursday 09 November 2006 11:34, Andrew Long wrote: also ran SELECT `usergroup`.`UserName`, `usergroup`.`creationdate`, `usergroup`.`GroupName` from usergroup where username = '4aroma70370'; and that also comes up null... Does it make sense that radius is not recognizing the usernames as belonging to the group 'aroma', thus not assigning the group-reply? Yes, because the radius server does what you configure it to do. You should have control over the usergroup table, so it shouldn't be difficult to add the missing records. If you're still stuck, try sending relevant output from all of your sql tables. The actual row data should be good enough, unless you've mangled the table structure to suit local needs. This is my current thought on this, but I'm not sure why it would still authorize the request, unless it's not necessary that users be part of group. It isn't necessary. The cleartext password needed for CHAP was provided by a module (users, sql, ??), so the access request was accepted. Kevin Bonner pgp5lBMh78e4T.pgp Description: PGP signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re[2]: limiting sessions
On Thursday 09 November 2006 11:34, Andrew Long wrote:
also ran
SELECT
`usergroup`.`UserName`,
`usergroup`.`creationdate`,
`usergroup`.`GroupName`
from usergroup
where username = '4aroma70370';
and that also comes up null...
Does it make sense that radius is not recognizing the usernames as
belonging to the group 'aroma', thus not assigning the group-reply?
Yes, because the radius server does what you configure it to do. You should
have control over the usergroup table, so it shouldn't be difficult to add
the missing records.
If you're still stuck, try sending relevant output from all of your sql
tables. The actual row data should be good enough, unless you've mangled the
table structure to suit local needs.
This is my current thought on this, but I'm not sure why it would
still authorize the request, unless it's not necessary that users be
part of group.
It isn't necessary. The cleartext password needed for CHAP was provided by a
module (users, sql, ??), so the access request was accepted.
Kevin Bonner
I have verified that there are indeed username-password pairs in
radreply where those unsernames do not exist in 'usergroups'. Here is
what I propose and I'd like confirmation that my thinking is accurate
before I do it...
First, I grabbed all the usernames from radcheck for the given
property. Then I write a script to insert them into usergroup (with
other appropriate values), which I run after clearing the usergroup
table of all records where the group is the one I am interested in.
DELETE FROM radius.usergroup WHERE GroupName = 'aroma'
THEN...
INSERT INTO radius.usergroup (UserName, CreationDate, GroupName)
VALUES ('username0001', (CURRENT_DATE), 'aroma');
repeated for all 500 usernames...
I think this should work, as all the usernames in use are stored in
radcheck and I'm not touching that table at all. Worst case scenario,
users continue to authenticate without a session limit and I go back
to work...
DOES THIS SOUND RIGHT?
Andrew
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re[3]: limiting sessions
Andrew Long [EMAIL PROTECTED] wrote: I need to boot users at one property after a specified time period. We have adjusted the max-daily-session to 1800 (30 minutes), but users still seem to be staying on. Can someone point me in the right direction. The NAS is a Colubris cn3000. Why use Max-Daily-Session? What's wrong with Session-Timeout? Alan DeKok. I tried Session-Timeout but it doesn't seem to do the job. A query of radacct yields several users at that property with sessions exceeding the 1800 mark specified for the attribute. Any additional thoughts on how best to limit these sessions? Andrew - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Re[3]: limiting sessions
Andrew Long [EMAIL PROTECTED] wrote: I tried Session-Timeout but it doesn't seem to do the job. So... is it being sent back to the NAS? If it is, then the NAS is ignoring it. Go ask your NAS manufacturer for a refund, or for a firmware upgrade that implements RADIUS. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
limiting sessions
I need to boot users at one property after a specified time period. We have adjusted the max-daily-session to 1800 (30 minutes), but users still seem to be staying on. Can someone point me in the right direction. The NAS is a Colubris cn3000. The other attribute we have that may apply is max-acct-age. I am pretty new to this, so any detail is most appreciated. -- Regards, Andrew Long EscapeWire Solutions, LLC 617 Dingens Street Buffalo, NY 14206 Office: (716) 893-4984 Mobile: (716) 830-5169 Fax: (716) 891-4288 Web: http://www.escapewire.com E-mail: [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: limiting sessions
Andrew Long [EMAIL PROTECTED] wrote: I need to boot users at one property after a specified time period. We have adjusted the max-daily-session to 1800 (30 minutes), but users still seem to be staying on. Can someone point me in the right direction. The NAS is a Colubris cn3000. Why use Max-Daily-Session? What's wrong with Session-Timeout? Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: limiting sessions
Andrew Long wrote: I need to boot users at one property after a specified time period. We have adjusted the max-daily-session to 1800 (30 minutes), but users still seem to be staying on. Can someone point me in the right direction. The NAS is a Colubris cn3000. The other attribute we have that may apply is max-acct-age. I am pretty new to this, so any detail is most appreciated. The NAS should support Session-Timeout, which is the most common method of time-limiting sessions. If not, hit the vendor with a big cluebat, as it's in the RFC. -- James Wakefield, Unix Administrator, Information Technology Services Division Deakin University, Geelong, Victoria 3217 Australia. Phone: 03 5227 8690 International: +61 3 5227 8690 Fax: 03 5227 8866 International: +61 3 5227 8866 E-mail: [EMAIL PROTECTED] Website: http://www.deakin.edu.au - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re[2]: limiting sessions
Andrew Long [EMAIL PROTECTED] wrote: I need to boot users at one property after a specified time period. We have adjusted the max-daily-session to 1800 (30 minutes), but users still seem to be staying on. Can someone point me in the right direction. The NAS is a Colubris cn3000. Why use Max-Daily-Session? What's wrong with Session-Timeout? Alan DeKok. My understanding from reading the Radius book made it sound like session-timeout will allow the user to re-connect. Am I wrong here? The hotspot is a cafe. We provide them a list of passwords (actually usernames) which their customers use to authenticate with our radius server. Right now, they recycle that list. Any way I can impose the limit so the user can not use the same code to log in again, at least in that day? If I have to create more codes, that's fine... I don't care about that, just about getting these sessions terminated so they don't have customers lounging... Andrew Long - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
