Alan DeKok wrote: > Arran Cudbard-Bell wrote: > >> At least in 1.1.5 it doesn't fall through properly if a user belongs to >> multiple groups and the check items in the first group partially match.. >> > > In which version did it stop working? > I will investigate, as far as I could tell it was still broken in the CVS head..
Oh btw, are dotted ip addresses supported in CIDR format as check items ? I've been using regular expressions, but CIDR would be easier. Let me check i've got the theory of groups correct first. Ok, there used to be a directive in sql.conf that forced rlm_sql to check groups, this is now depricated and no longer used ? So rlm_sql will check groups for the user in every case. The sql group check query, selects all the rows in the 'radgroupcheck' table, that has a group id that matches the id of any of the groups the user is marked a member of in the 'usergroup' table. It then runs much the same query for the 'radgroupreply' table. It works down the list of groups in order of priority which it's gleaned from the usergroup table. Or at least it should, but it doesn't in 1.1.5. The result from the default queries is actually ordered by the auto incremented ID in the groupcheck and group reply tables, it should be ordered by the priority in the user groups table.... Or rlm_sql should at least pull the priority field out of the database and process the groups in that order... When you think about it, this screws quite a few things up.... If you are relying on the group priority with groups of lower priorities having the fall-through directive to false.... So to illustrate 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 radgroupcheck.id 1 nas_admins Service-Type 7 == 2 nas_admins NAS-IP-Address ^(139[.]184[.]8[.])([0-9]{0,3})$ =~ 5 roaming_users Service-Type 5 == In the users group table however, roaming_users has a higher priority than nas admins (priority of 2) , so it should be listed first but it's ovbiously not. 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 5 roaming_users Service-Type 5 == 9 nas_admins Service-Type 7 == 2 nas_admins NAS-IP-Address ^(139[.]184[.]8[.])([0-9]{0,3})$ =~ So now, as long as the groups are processed in order then the priority field will be honoured. If not the priority should be included in the select query and it should be honoured by rlm_sql. Anyway first issue over :) Second issue, is when user ac221 belongs to both groups, if any of the check items match in nas_admins then it won't check roaming_users check items. Which means if a user is setup as a nas admin, they don't get the any vlan information sent when they connect as a framed user .... As far as I can tell this has been broken since 1.1.5 as is still broken in the cvs head. I can try and dig out a copy of 1.1.4 and check if you want ? SQL rows as follows.. user groups ac221 roaming_users 2 ac221 nas_admins 1 check items 9 nas_admins Service-Type == 7 2 nas_admins NAS-IP-Address =~ ^(139[.]184[.]8[.])([0-9]{0,3})$ 3 nas_operators Service-Type == 7 4 nas_operators NAS-IP-Address =~ ^(139[.]184[.]8[.])([0-9]{0,3})$ 5 roaming_users Service-Type == 5 reply items 1 nas_admins Service-Type = 6 2 nas_operators Service-Type = 7 3 roaming_users Tunnel-Type = 13 4 roaming_users Tunnel-Medium-Type = 6 5 roaming_users Tunnel-Private-Group-ID = 134 Login to NAS works fine. Login to AP results in user not found, and attributes not being sent :(. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html