Version 2.0 is a lot closer to reality...

[Arran Cudbard-Bell]

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 :(.