Re: Version 2.0 is a lot closer to reality...

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,radgroupc heck.Attribute,radgroupcheck.Value,radgroupcheck.o p
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,radgroupc heck.Attribute,radgroupcheck.Value,radgroupcheck.o p
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