Re: Restricting dialup users to certain client definitions only
Can't post now but, yes I do see the groups table being queried ------Original Message------ From: tnt@kalik.net Sender: freeradius-users-bounces+tjrlist=lightwavetech.com@lists.freeradius.org To: FreeRadius users mailing list ReplyTo: FreeRadius users mailing list Subject: RE: Restricting dialup users to certain client definitions only Sent: Dec 19, 2008 8:29 PM
Just a clarification on my earlier response. I mentioned that I put the rule in radcheck when in fact I was putting it in radgroupcheck.
Thing is, when I put it in radcheck it works. When I put the same rule in radgroupcheck, it fails.
Are groups processed? Post the debug. Ivan Kalik Kalik Informatika ISP - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Sent via BlackBerry by AT&T
>>>>>>>>>>>>>>>>>>>> Subject: Re: Restricting dialup users to certain client definitions only
Can't post now but, yes I do see the groups table being queried
Is there something else in the group entry that doesn't match? Ivan Kalik Kalik Informatika ISP
>>>>>>>>>>>>>>>>>>>>>
OK, took me a while but here is the SQL dump and the Debug output. One thing that's interesting is that I only seem to get my reply attributes from the radgroupreply table when I am coming from the allowed client-ip-address, when coming from any other IP I still get an accept but I get not reply attributes. So, FR seems to know the difference but I guess I am just not sending the reject or something? Thanks in advance! Todd R. Here is the MySQL output: mysql> select * from radcheck; +----+-------------------+--------------------+----+------------------------ + | id | username | attribute | op | value | +----+-------------------+--------------------+----+------------------------ + | 9 | testuser | Cleartext-Password | := | testpass | +----+-------------------+--------------------+----+------------------------ + mysql> select * from radgroupcheck; +----+------------------+-------------------+----+----------------+ | id | groupname | attribute | op | value | +----+------------------+-------------------+----+----------------+ | 0 | dialusers | Client-IP-Address | == | 66.221.123.122 | | 3 | dialusers-suspnd | Auth-Type | := | Reject | +----+------------------+-------------------+----+----------------+ mysql> select * from radusergroup; +-------------------+------------------+----------+ | username | groupname | priority | +-------------------+------------------+----------+ | blahsampleuser | dialusers-suspnd | 1 | | testuser | dialusers | 1 | +-------------------+------------------+----------+ mysql> select * from radgroupreply; +----+------------------+--------------------+----+------------------------- --------------+ | id | groupname | attribute | op | value | +----+------------------+--------------------+----+------------------------- --------------+ | 1 | dialusers | Framed-Protocol | = | PPP | | 9 | dialusers | Idle-Timeout | = | 900 | | 10 | dialusers-suspnd | Reply-Message | = | Dialup account suspended | +----+------------------+--------------------+----+------------------------- --------------+ Here is the debug: ####################################################### rad_recv: Access-Request packet from host 66.221.123.134 port 49794, id=2, length=60 User-Name = "testuser@myrealm.com" User-Password = "testpass" +- entering group authorize {...} ++[preprocess] returns ok [suffix] Looking up realm "myrealm.com" for User-Name = "testuser@myrealm.com" [suffix] Found realm "DEFAULT" [suffix] Adding Stripped-User-Name = "testuser" [suffix] Adding Realm = "DEFAULT" [suffix] Authentication realm is LOCAL. ++[suffix] returns ok [sql] expand: %{Stripped-User-Name} -> testuser [sql] sql_set_user escaped user --> 'testuser' rlm_sql (sql): Reserving sql socket id: 2 [sql] expand: SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FROM radcheck WHERE username = 'testuser' ORDER BY id [sql] User found in radcheck table [sql] expand: SELECT id, username, attribute, value, op FROM radreply WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FROM radreply WHERE username = 'testuser' ORDER BY id [sql] expand: SELECT groupname FROM radusergroup WHERE username = '%{SQL-User-Name}' ORDER BY priority -> SELECT groupname FROM radusergroup WHERE username = 'testuser' ORDER BY priority [sql] expand: SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = '%{Sql-Group}' ORDER BY id -> SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'dialusers' ORDER BY id [sql] expand: %{Client-IP-Address} -> 66.221.123.134 rlm_sql (sql): Released sql socket id: 2 ++[sql] returns ok ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns updated Found Auth-Type = PAP +- entering group PAP {...} [pap] login attempt with password "testpass" [pap] Using clear text password "testpass" [pap] User authenticated successfully ++[pap] returns ok Login OK: [testuser@myrealm.com] (from client ToddHome port 0) +- entering group post-auth {...} [sql] expand: %{Stripped-User-Name} -> testuser [sql] sql_set_user escaped user --> 'testuser' [sql] expand: %{User-Password} -> testpass [sql] expand: INSERT INTO radpostauth (username, pass, reply, rejectreason, authdate) VALUES ( '%{User-Name}', '%{%{User-Password}:-%{Chap-Password}}', '%{reply:Packet-Type}', '%{Module-Failure-Message}-%{reply:Reply-Message}', '%S') -> INSERT INTO radpostauth (username, pass, reply, rejectreason, authdate) VALUES ( 'testuser@myrealm.com', 'testpass', 'Access-Accept', '-', '2008-12-23 00:01:00') rlm_sql (sql) in sql_postauth: query is INSERT INTO radpostauth (username, pass, reply, rejectreason, authdate) VALUES ( 'testuser@myrealm.com', 'testpass', 'Access-Accept', '-', '2008-12-23 00:01:00') rlm_sql (sql): Reserving sql socket id: 1 rlm_sql (sql): Released sql socket id: 1 ++[sql] returns ok ++[exec] returns noop Sending Access-Accept of id 2 to 66.221.123.134 port 49794 Finished request 1. Going to the next request Waking up in 4.9 seconds. Cleaning up request 1 ID 2 with timestamp +33 Ready to process requests. ############################################################################ #######
OK, took me a while but here is the SQL dump and the Debug output. One thing that's interesting is that I only seem to get my reply attributes from the radgroupreply table when I am coming from the allowed client-ip-address, when coming from any other IP I still get an accept but I get not reply attributes. So, FR seems to know the difference but I guess I am just not sending the reject or something?
That's how groups work. If a group check doesn't match - group reply attributes are ignored. User doesn't get rejected if one of the groups he belongs to doesn't match. SQL is a storage fascility - it's not an authentication method. Ivan Kalik Kalik Informatika ISP
Thanks.. I assumed that if something didn't match in the group that there was a reject. I was unsure how to make it reject if something didn't match in the group. I just figured out how to do this I think. I set up another group called dialusers-denied and then assigned the user to two groups like so: Testuser > dialusers > priority 1 Testuser > dialusers-denied > priority 2 For dialusers I set the client-ip-address check, if there is a match then the attributes are sent and all is well. For dialusers-denied group I set a check item for Auth-Type Reject. If the check item/s fail for dialusers those attributes aren't sent but it then falls through to dialusers-denied group and sends the Auth-Type Reject. This seems to work, hopefully I got it now and this is the way it's suppose to be done. Just took me a while to get how to reject if a check didn't match. Things works in my testing but if I am going down the wrong road, please let me know. Thanks! --Todd R. -----Original Message----- From: freeradius-users-bounces+tjrlist=lightwavetech.com@lists.freeradius.org [mailto:freeradius-users-bounces+tjrlist=lightwavetech.com@lists.freeradius. org] On Behalf Of tnt@kalik.net Sent: Tuesday, December 23, 2008 3:34 AM To: FreeRadius users mailing list Subject: RE: Restricting dialup users to certain client definitions only
OK, took me a while but here is the SQL dump and the Debug output. One thing that's interesting is that I only seem to get my reply attributes from the radgroupreply table when I am coming from the allowed client-ip-address, when coming from any other IP I still get an accept but I get not reply attributes. So, FR seems to know the difference but I guess I am just not sending the reject or something?
That's how groups work. If a group check doesn't match - group reply attributes are ignored. User doesn't get rejected if one of the groups he belongs to doesn't match. SQL is a storage fascility - it's not an authentication method. Ivan Kalik Kalik Informatika ISP - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Only problem I see with this approach is that I have to assign every user to two groups now in radusersgroup table. Or.. Is there a better way? --Todd R. -----Original Message----- From: freeradius-users-bounces+tjrlist=lightwavetech.com@lists.freeradius.org [mailto:freeradius-users-bounces+tjrlist=lightwavetech.com@lists.freeradius. org] On Behalf Of Todd R. Sent: Tuesday, December 23, 2008 3:43 AM To: 'FreeRadius users mailing list' Subject: RE: Restricting dialup users to certain client definitions only Thanks.. I assumed that if something didn't match in the group that there was a reject. I was unsure how to make it reject if something didn't match in the group. I just figured out how to do this I think. I set up another group called dialusers-denied and then assigned the user to two groups like so: Testuser > dialusers > priority 1 Testuser > dialusers-denied > priority 2 For dialusers I set the client-ip-address check, if there is a match then the attributes are sent and all is well. For dialusers-denied group I set a check item for Auth-Type Reject. If the check item/s fail for dialusers those attributes aren't sent but it then falls through to dialusers-denied group and sends the Auth-Type Reject. This seems to work, hopefully I got it now and this is the way it's suppose to be done. Just took me a while to get how to reject if a check didn't match. Things works in my testing but if I am going down the wrong road, please let me know. Thanks! --Todd R. -----Original Message----- From: freeradius-users-bounces+tjrlist=lightwavetech.com@lists.freeradius.org [mailto:freeradius-users-bounces+tjrlist=lightwavetech.com@lists.freeradius. org] On Behalf Of tnt@kalik.net Sent: Tuesday, December 23, 2008 3:34 AM To: FreeRadius users mailing list Subject: RE: Restricting dialup users to certain client definitions only
OK, took me a while but here is the SQL dump and the Debug output. One thing that's interesting is that I only seem to get my reply attributes from the radgroupreply table when I am coming from the allowed client-ip-address, when coming from any other IP I still get an accept but I get not reply attributes. So, FR seems to know the difference but I guess I am just not sending the reject or something?
That's how groups work. If a group check doesn't match - group reply attributes are ignored. User doesn't get rejected if one of the groups he belongs to doesn't match. SQL is a storage fascility - it's not an authentication method. Ivan Kalik Kalik Informatika ISP - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Only problem I see with this approach is that I have to assign every user to two groups now in radusersgroup table.
Or.. Is there a better way?
Well, different. Don't know about better: use huntgroups. onlythisgroup Client-IP-Address == some address SQL-Group == "thisgroup" multigroup Client-IP-Address == another address SQL-Group == "groupone", SQL-Group == "grouptwo" If your client-group mappings are static it will work well. Straightforward as long as you don't have to return anyhing as a reply for rejected users. You will need to utilize Post-Auth-Type REJECT if that is the case. Ivan Kalik Kalik Informatika ISP
participants (2)
-
tnt@kalik.net -
Todd R.