SQL Groups broken in v 1.1.5 but fixed in CVS head :)
Hi, Updated The sql querys to honour priority field, and happily it seems that rlm_sql processes groups in the order they come out of the database... which is good. What the packets below are show, is that if the group with the highest priority has all it's check items match, then it's reply items are added fine. However if the first group doesn't match then the other groups arn't processed ! So although the user is still authorised via LDAP none of the group reply items are sent :( If the priority of the groups is reversed, so the 'nas_admins' group comes out of the database first, then the nas_admins reply items work, but the roaming_users group doesn't *sigh*. Would also appear that CIDR ip notation doesn't work for NAS-IP-Address ... But thats not too bad, as you can stick the relevant NAS's in a huntgroup and check against that instead. * Confirmed this is broken in branch_1_1 * Confirmed this is fixed in CVS head with group priority being honoured properly. Don't suppose there's any chance of bringing some of the changes in the CVS Head rlm_sql over to branch_1_1 for the next 1.1.* release is there ? .... Namely the new sql_clients function with the user definable query, and the new groups handling. As the groups handling is a pretty major bug, and i'm sure anyone else using sql will be having issues with the later releases. Oh and a huge great big thanks, to whoever fixed rlm_sql in the cvs head ... I think it was Alexander Serkin. :) *Rad Group Check SQL query:* SELECT radgroupcheck . id , radgroupcheck . GroupName , radgroupcheck . Attribute , radgroupcheck . Value , radgroupcheck . op FROM radgroupcheck , usergroup WHERE usergroup . UserName = 'ac221' AND usergroup . GroupName = radgroupcheck . GroupName ORDER BY usergroup . priority DESC , radgroupcheck . GroupName LIMIT 0, 30 ; *Rows:* 2 id GroupName Attribute Value op 5 roaming_users Service-Type Framed-User == 1 nas_admins Service-Type NAS-Prompt-User == *Rad Group Reply* *SQL query:* SELECT radgroupreply . id , radgroupreply . GroupName , radgroupreply . Attribute , radgroupreply . Value , radgroupreply . op FROM radgroupreply , usergroup WHERE usergroup . UserName = 'ac221' AND usergroup . GroupName = radgroupreply . GroupName ORDER BY usergroup . priority DESC , radgroupreply . GroupName LIMIT 0, 30 ; *Rows:* 7 id GroupName Attribute Value op 3 roaming_users Tunnel-Type 13 = 4 roaming_users Tunnel-Medium-Type 6 = 5 roaming_users Tunnel-Private-Group-ID 134 = 8 roaming_users Service-Type 4 = 10 roaming_users Fall-Through yes = 1 nas_admins Service-Type 6 = 9 nas_admins Fall-Through yes = Sending Access-Request of id 178 to 139.184.**.*** port 1812 User-Name = "ac221" User-Password = "nopassword" Service-Type = NAS-Prompt-User NAS-IP-Address = 139.184.8.1 rad_recv: Access-Accept packet from host 139.184.**.***:1812, id=178, length=20 Sending Access-Request of id 225 to 139.184.**.*** port 1812 User-Name = "ac221" User-Password = "nopassword" Service-Type = Framed-User NAS-IP-Address = 139.184.8.1 rad_recv: Access-Accept packet from host 139.184.**.***:1812, id=225, length=43 Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "134" Service-Type = Callback-Framed-User Thanks, Arran
Arran Cudbard-Bell wrote:
Don't suppose there's any chance of bringing some of the changes in the CVS Head rlm_sql over to branch_1_1 for the next 1.1.* release is there ?
No. I'd like to get 1.1.6 out with some stability fixes, and Coverity bug fixes. After that, 1.1.7 (if it happens) will contain bug fixes, nothing more. Maybe the SQL code will get fixed, it all depends.
.... Namely the new sql_clients function with the user definable query, and the new groups handling. As the groups handling is a pretty major bug, and i'm sure anyone else using sql will be having issues with the later releases.
Likely, yes. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Fri, Apr 06, 2007 at 08:43:30PM +0100, Arran Cudbard-Bell wrote:
Hi,
Updated The sql querys to honour priority field, and happily it seems that rlm_sql processes groups in the order they come out of the database... which is good. What the packets below are show, is that if the group with the highest priority has all it's check items match, then it's reply items are added fine.
However if the first group doesn't match then the other groups arn't processed ! So although the user is still authorised via LDAP none of the group reply items are sent :(
So Fall-Through is not being obeyed, correct?
Phil Mayers wrote:
On Fri, Apr 06, 2007 at 08:43:30PM +0100, Arran Cudbard-Bell wrote:
Hi,
Updated The sql querys to honour priority field, and happily it seems that rlm_sql processes groups in the order they come out of the database... which is good. What the packets below are show, is that if the group with the highest priority has all it's check items match, then it's reply items are added fine.
However if the first group doesn't match then the other groups arn't processed ! So although the user is still authorised via LDAP none of the group reply items are sent :(
So Fall-Through is not being obeyed, correct?
No Fall-Through shouldn't even be checked. Whats happening is if the first groups check items don't match, it doesn't check the second group. Fall-Through status for a group should only be checked if the group actually matches. --- Arran
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Phil Mayers