v2.1.10 Why authorize_group check & reply query changed?
For several years we have been happy using early v1 distributions of FreeRadius with a MySQL database on SuSe Linux. However, machines wear out and security issues are resolved so decided it was time to upgrade to v2.1.10 which is available as a package in Ubuntu 12.04. Instead of just copying over all the config files and correcting the directory pointers, I went through the process of updating the new radiusd.conf, sites-available/default, sql.conf, and dialup.conf files. I have been able to successfully authenticate & authorize test users using radtest. However, group membership did not work correctly as it did before. We use a system where most users are members of at least 2 groups, meaning that each will have 2 entries in the radusergroup table, one for each group it belongs to. In the previous production installation, each user would properly receive all the attributes of both groups. On the new test system however, they only receive the attributes of their first radusergroup entry in the list based on the priority entry. Research has shown that there was a BIG change in the group queries. v1: authorize_group_check_query = "SELECT ${groupcheck_table}.id,${groupcheck_table}.GroupName,${groupcheck_table}.Attribute,${groupcheck_table}.Value,${groupcheck_table}.op FROM ${groupcheck_table},${usergroup_table} WHERE ${usergroup_table}.Username = '%{SQL-User-Name}' AND ${usergroup_table}.GroupName = ${groupcheck_table}.GroupName ORDER BY ${groupcheck_table}.id" authorize_group_reply_query = "SELECT ${groupreply_table}.id,${groupreply_table}.GroupName,${groupreply_table}.Attribute,${groupreply_table}.Value,${groupreply_table}.op FROM ${groupreply_table},${usergroup_table} WHERE ${usergroup_table}.Username = '%{SQL-User-Name}' AND ${usergroup_table}.GroupName = ${groupreply_table}.GroupName ORDER BY ${groupreply_table}.id" v2: authorize_group_check_query = "SELECT id, groupname, attribute, \ Value, op \ FROM ${groupcheck_table} \ WHERE groupname = '%{Sql-Group}' \ ORDER BY id" authorize_group_reply_query = "SELECT id, groupname, attribute, \ value, op \ FROM ${groupreply_table} \ WHERE groupname = '%{Sql-Group}' \ ORDER BY id" Can anyone tell me why it was decided to limit the functionality in v2 by replacing the old queries?? I have tried replacing the new one with the old, and it seems to work perfectly again. I guess the more important question I am asking is whether I will have any problems just using the old queries in the new dialup.conf script? -- View this message in context: http://freeradius.1045715.n5.nabble.com/v2-1-10-Why-authorize-group-check-re... Sent from the FreeRadius - User mailing list archive at Nabble.com.
On 06/08/2012 11:28 PM, JustJoe wrote:
Can anyone tell me why it was decided to limit the functionality in v2 by replacing the old queries?? I have tried replacing the new one with the old, and it seems to work perfectly again.
In fact, functionality was added, not limited. (n.b. I'm working from memory here) The old queries effectively merged the check & reply items for all groups the user is a member of before comparing them / setting reply items. This can be a pain if you have NAS-specific check items. For example, if you have groups "VPN users" and "Wireless users" both of which have a different comparison for NAS-Port-Type, and a user is a member of both, the merged check items can never match. The rlm_sql source code & queries were changed to run the queries one group at a time, and look for / honour the Fall-Through attribute in a manner similar to the "users" file. That is: 1. Select all entries from radcheck/radreply for the users 2. Select all groups the user is a member of 3. For each group 4. select from radgroupcheck/radgroupreply 5. If check items do not match, goto next group, restart from #4 6. set reply items 7. If not Fall-Through==yes, stop 8. Else, goto next group, restart from #4 Step 7 is the key; if you want all groups to be processed, simply insert "Fall-Through", "=", "Yes" in the radgroupreply table. Do note that this will mean more SQL queries, though each with fewer result rows. This is unlikely to matter unless your SQL database is particularly slow.
I guess the more important question I am asking is whether I will have any problems just using the old queries in the new dialup.conf script?
The whole point is you can use any queries you want; if those work better for you, then use them. But do be aware of why they changed, and the alternatives (Fall-Through)
participants (2)
-
JustJoe -
Phil Mayers