SQL Groups broken in v 1.1.5 but fixed in CVS head :)

[Arran Cudbard-Bell]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20070406/93a636d5/attachment.html>