How to get FR user check items override group check items
I have been using FreeRADIUS 1.1 (yeah very old) on an old Debian server over the years without any issues. Thank you for wonderful software! Now, as part of the server upgrade, I tried installing version 3.2.1 in Debian 12 and I was able to configure it except for one issue. In v1.1 user attributes get priority over group items. I am using the same SQL tables from v1.1. There I am setting Session-Timeout to 3600 in the radgroupcheck table. For some select users I set Session-Timeout differently, say 7200. In v1.1, I am seeing Session-Timeout = 7200 for Access-Accept while in v3.2.1 it is 3600. I checked the server in debug mode and found following <snip> .... (0) sql: User found in radcheck table (0) sql: Conditional check items matched, merging assignment check items (0) sql: Session-Timeout := 7200 (0) sql: Crypt-Password := "$1$bd1rxwue$ab3wiY34Cjfk5QM13/vNy0" .... (0) sql: User found in the group table (0) sql: EXPAND SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = '%{S QL-Group}' ORDER BY id (0) sql: --> SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'VPN -60-Min' ORDER BY id (0) sql: Executing select query: SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'VPN-60-Min' ORDER BY id (0) sql: Group "VPN-60-Min": Conditional check items matched (0) sql: Group "VPN-60-Min": Merging assignment check items (0) sql: Session-Timeout := 3600 .... (0) dailycounter: Allowing user, &control:Session-Timeout value (3600) is greater than counter value (0) (0) dailycounter: Setting &reply:Session-Timeout value to 3600 .... Sent Access-Accept Id 55 from 192.168.3.180:1812 to 192.168.3.180:39999 length 32 (0) Idle-Timeout = 600 (0) Session-Timeout = 3600 (0) Finished request </snip> So I think this is the expected behaviour in the new version. Following are the sql contents. Table radgroupreply: +----+------------+--------------+----+-------+ | id | groupname | attribute | op | value | +----+------------+--------------+----+-------+ | 9 | VPN-60-Min | Idle-Timeout | := | 600 | +----+------------+--------------+----+-------+ Table radgroupcheck: +----+------------+-----------------+----+-------+ | id | groupname | attribute | op | value | +----+------------+-----------------+----+-------+ | 2 | VPN-60-Min | Session-Timeout | := | 3600 | +----+------------+-----------------+----+-------+ Table: radcheck: +----+----------+-----------------+----+------------------------------------+ | id | username | attribute | op | value | +----+----------+-----------------+----+------------------------------------+ | 18 | vpn-user | Session-Timeout | := | 7200 | | 19 | vpn-user | Crypt-Password | := | $1$bd1rxwue$ab3wiY34Cjfk5QM13/vNy0 | +----+----------+-----------------+----+------------------------------------+ Now my question: Is there any configuration options available to get the old v1.1 behaviour? This way I don't have to set Session-Timeout for all my users, just a select few who need to be different from default. Thanks Abraham
On 15/11/2024 15:49, Abraham Jacob wrote:
So I think this is the expected behaviour in the new version. It is with the data you've got Following are the sql contents.
Table radgroupreply: +----+------------+--------------+----+-------+ | id | groupname | attribute | op | value | +----+------------+--------------+----+-------+ | 9 | VPN-60-Min | Idle-Timeout | := | 600 | +----+------------+--------------+----+-------+
The behaviour you want can be easily achieved by changing the operator in radgroupreply if you use "=" instead of ":=", the group reply won't overwrite the user one, since an instance of the attribute already exists. Nick -- Nick Porter
On Nov 15, 2024, at 10:49 AM, Abraham Jacob <abrahamj@gmail.com> wrote:
I have been using FreeRADIUS 1.1 (yeah very old) on an old Debian server over the years without any issues. Thank you for wonderful software!
You're welcome.
Now, as part of the server upgrade, I tried installing version 3.2.1 in Debian 12
There are updated packages available from us at http://packages.networkradius.com 3.2.1 is out of date, too.
and I was able to configure it except for one issue. In v1.1 user attributes get priority over group items. I am using the same SQL tables from v1.1. There I am setting Session-Timeout to 3600 in the radgroupcheck table. For some select users I set Session-Timeout differently, say 7200.
In v1.1, I am seeing Session-Timeout = 7200 for Access-Accept while in v3.2.1 it is 3600.
OK.
I checked the server in debug mode and found following
<snip> .... (0) sql: User found in radcheck table (0) sql: Conditional check items matched, merging assignment check items (0) sql: Session-Timeout := 7200 (0) sql: Crypt-Password := "$1$bd1rxwue$ab3wiY34Cjfk5QM13/vNy0" .... (0) sql: User found in the group table (0) sql: EXPAND SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = '%{S QL-Group}' ORDER BY id (0) sql: --> SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'VPN -60-Min' ORDER BY id (0) sql: Executing select query: SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'VPN-60-Min' ORDER BY id (0) sql: Group "VPN-60-Min": Conditional check items matched (0) sql: Group "VPN-60-Min": Merging assignment check items (0) sql: Session-Timeout := 3600
That's the issue. You have the user configuration setting it to 7200, and are the *over-riding* that with the group configuration of 3600. The solution here is to change the operator in the group table from ":=" to "=". That way it won't over-ride any previous setting.
So I think this is the expected behaviour in the new version.
This behavior hasn't changed since at least v2, so you're relying on some very, very, very, old behavior. Alan DeKok.
Thanks Nick and Alan for the quick response. Please see my reply inline below. On Fri, Nov 15, 2024 at 10:36 PM Alan DeKok <aland@deployingradius.com> wrote:
On Nov 15, 2024, at 10:49 AM, Abraham Jacob <abrahamj@gmail.com> wrote:
I have been using FreeRADIUS 1.1 (yeah very old) on an old Debian server over the years without any issues. Thank you for wonderful software!
You're welcome.
Now, as part of the server upgrade, I tried installing version 3.2.1 in Debian 12
There are updated packages available from us at http://packages.networkradius.com
3.2.1 is out of date, too.
Ok, will change the package repo sometime later.
and I was able to configure it except for one issue. In v1.1 user attributes get priority over group items. I am using the same SQL tables from v1.1. There I am setting Session-Timeout to 3600 in the radgroupcheck table. For some select users I set Session-Timeout differently, say 7200.
In v1.1, I am seeing Session-Timeout = 7200 for Access-Accept while in v3.2.1 it is 3600.
OK.
I checked the server in debug mode and found following
<snip> .... (0) sql: User found in radcheck table (0) sql: Conditional check items matched, merging assignment check items (0) sql: Session-Timeout := 7200 (0) sql: Crypt-Password := "$1$bd1rxwue$ab3wiY34Cjfk5QM13/vNy0" .... (0) sql: User found in the group table (0) sql: EXPAND SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = '%{S QL-Group}' ORDER BY id (0) sql: --> SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'VPN -60-Min' ORDER BY id (0) sql: Executing select query: SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'VPN-60-Min' ORDER BY id (0) sql: Group "VPN-60-Min": Conditional check items matched (0) sql: Group "VPN-60-Min": Merging assignment check items (0) sql: Session-Timeout := 3600
That's the issue. You have the user configuration setting it to 7200, and are the *over-riding* that with the group configuration of 3600.
The solution here is to change the operator in the group table from ":=" to "=". That way it won't over-ride any previous setting.
I tried changing the operator of Session-Timeout to '='. In that case it works perfectly for the users who has a Session-Timeout set on radcheck. For following data (for the users with default Session-Timeout of 3600, ie no Session-Timeout attribute on radcheck) FR is not sending Session-Timeout in Access-Reply. Table radcheck: +----+----------+----------------+----+------------------------------------+ | id | username | attribute | op | value | +----+----------+----------------+----+------------------------------------+ | 19 | vpn-user | Crypt-Password | := | $1$bd1rxwue$ab3wiY34Cjfk5QM13/vNy0 | +----+----------+----------------+----+------------------------------------+ Table radusergroup: +----------+------------+----------+ | username | groupname | priority | +----------+------------+----------+ | vpn-user | VPN-60-Min | 1 | +----------+------------+----------+ Table radgroupcheck: +----+------------+-----------------+----+-------+ | id | groupname | attribute | op | value | +----+------------+-----------------+----+-------+ | 2 | VPN-60-Min | Session-Timeout | = | 3600 | +----+------------+-----------------+----+-------+ The debug output shows dailycounter could not find control attribute. (1) [sql] = ok (1) [expiration] = noop (1) [logintime] = noop (1) dailycounter: WARNING: Couldn't find check attribute, control:Session-Timeout, doing nothing... (1) [dailycounter] = noop (1) [pap] = updated It is working as expected if I set the radgroupcheck op to ':='.
From the Operator wiki page I understand that for matching as a check item, the operator has to be :=.
I hope I am not missing anything here. Thanks again. Abraham
So I think this is the expected behaviour in the new version.
This behavior hasn't changed since at least v2, so you're relying on some very, very, very, old behavior.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Nov 16, 2024, at 4:51 AM, Abraham Jacob <abrahamj@gmail.com> wrote:
It is working as expected if I set the radgroupcheck op to ':='.
From the Operator wiki page I understand that for matching as a check item, the operator has to be :=.
Why are you matching it as a check item? You're trying to send it as a reply. Alan DeKok.
On Sat, Nov 16, 2024 at 7:23 PM Alan DeKok <aland@deployingradius.com> wrote:
On Nov 16, 2024, at 4:51 AM, Abraham Jacob <abrahamj@gmail.com> wrote:
It is working as expected if I set the radgroupcheck op to ':='.
From the Operator wiki page I understand that for matching as a check item, the operator has to be :=.
Why are you matching it as a check item? You're trying to send it as a reply.
Sorry, I missed to mention that I am using the sqlcounter module with the following configuration. sqlcounter dailycounter { sql_module_instance = sql dialect = mysql counter_name = Daily-Session-Time check_name = Session-Timeout reply_name = Session-Timeout key = User-Name reset = daily $INCLUDE ${modconfdir}/sql/counter/${dialect}/${.:instance}.conf } mods-config/sql/counter/mysql/dailycounter.conf: query = "\ SELECT SUM(acctsessiontime - GREATEST((%%b - UNIX_TIMESTAMP(acctstarttime)), 0)) \ FROM radacct \ WHERE username = '%{${key}}' \ AND UNIX_TIMESTAMP(acctstarttime) + acctsessiontime > '%%b'" This way I achieve 2 things. 1. Limit daily session time to Session-Timeout set, even if user is reconnecting 2. Give Access-Reject once the limit is crossed. Thanks, Abraham
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Nov 17, 2024, at 9:57 AM, Abraham Jacob <abrahamj@gmail.com> wrote:
Why are you matching it as a check item? You're trying to send it as a reply.
Sorry, I missed to mention that I am using the sqlcounter module with the following configuration.
That has nothing to do with the sql module. You're putting attributes into the radgroupcheck table, and are expecting the server to add them to the reply. Use the radgroupreply table instead. Once you do that, the "=" operator will work as I said. Configuring the sqlcounter module is nice, but it doesn't change how the radgroupcheck / radgroupreply tables work. Alan DeKok.
On Mon, Nov 18, 2024 at 12:15 AM Alan DeKok <aland@deployingradius.com> wrote:
On Nov 17, 2024, at 9:57 AM, Abraham Jacob <abrahamj@gmail.com> wrote:
Why are you matching it as a check item? You're trying to send it as a reply.
Sorry, I missed to mention that I am using the sqlcounter module with the following configuration.
That has nothing to do with the sql module.
Ok
You're putting attributes into the radgroupcheck table, and are expecting the server to add them to the reply. Use the radgroupreply table instead.
Once you do that, the "=" operator will work as I said.
Yes, when I put Session-Timeout in reply tables it is working except for the limiting the user using sqlcounter dailycounter. Suppose if the disconnects after cosuming 600 seconds long session and connects again, FR replies with Session-Timeout 3600. This is expected as there is no module to compute this. Following is the dailycounter config: sqlcounter dailycounter { sql_module_instance = sql dialect = mysql counter_name = Daily-Session-Time check_name = Session-Timeout reply_name = Session-Timeout key = User-Name reset = daily $INCLUDE ${modconfdir}/sql/counter/${dialect}/${.:instance}.conf } mods-config/sql/counter/mysql/dailycounter.conf: query = "\ SELECT SUM(acctsessiontime - GREATEST((%%b - UNIX_TIMESTAMP(acctstarttime)), 0)) \ FROM radacct \ WHERE username = '%{${key}}' \ AND UNIX_TIMESTAMP(acctstarttime) + acctsessiontime > '%%b'" Following is the sql contents; Table radcheck: +----+----------+----------------+----+------------------------------------+ | id | username | attribute | op | value | +----+----------+----------------+----+------------------------------------+ | 19 | vpn-user | Crypt-Password | := | $1$bd1rxwue$ab3wiY34Cjfk5QM13/vNy0 | +----+----------+----------------+----+------------------------------------+ Table radreply - No attributes Table radusergroup: +----------+------------+----------+ | username | groupname | priority | +----------+------------+----------+ | vpn-user | VPN-60-Min | 1 | +----------+------------+----------+ Table radgroupcheck - No attributes Table radgroupreply +----+------------+-----------------+----+-------+ | id | groupname | attribute | op | value | +----+------------+-----------------+----+-------+ | 12 | VPN-60-Min | Session-Timeout | = | 3600 | +----+------------+-----------------+----+-------+ FR debug output for dailycounter (7) [sql] = ok (7) [expiration] = noop (7) [logintime] = noop (7) dailycounter: WARNING: Couldn't find check attribute, control:Session-Timeout, doing nothing... (7) [dailycounter] = noop (7) [pap] = updated (7) } # authorize = updated As per my understanding, when Session-Time attribute was put in check tables, it was the dailycounter that computes remaining session time by deducting any used session from the radacct table and populating Session-Timeout reply attribute. Hope my understanding on how FR dailycounter module works is right and for this to work, the attribute has to be in one of the check tables and when it does, FR is working like a charm. Except that I am not able to find a method to override Session-Timeout in radgroupcheck for specific users by putting the attribute in radcheck table. Thanks, Abraham
On Nov 18, 2024, at 6:02 AM, Abraham Jacob <abrahamj@gmail.com> wrote:
Yes, when I put Session-Timeout in reply tables it is working except for the limiting the user using sqlcounter dailycounter.
It would have been helpful to describe that at the start. It's difficult to give the correct answer when the question is wrong. In this case, at least one issue is using Session-Timeout the wrong way. That attribute is meant to go into the reply, as the session timeout. It's not meant to be used in the dailycounter configuration. i.e. the default dailycounter configuration use "Max-Daily-Session" as the check name, in order to clearly separate the roles of the two different attributes.
Hope my understanding on how FR dailycounter module works is right and for this to work, the attribute has to be in one of the check tables and when it does, FR is working like a charm. Except that I am not able to find a method to override Session-Timeout in radgroupcheck for specific users by putting the attribute in radcheck table.
Configure the dailycounter module to use Max-Daily-Session. Don't use Session-Timeout in the check tables. Use Max-Daily-Session. And then in the radgroupcheck table use "+=" as the operator. The dailycounter module will only look at the first Max-Daily-Session, so that will be fine. Asking the right question gets you the right answer. Alan DeKok.
On Mon, Nov 18, 2024 at 5:18 PM Alan DeKok <aland@deployingradius.com> wrote:
On Nov 18, 2024, at 6:02 AM, Abraham Jacob <abrahamj@gmail.com> wrote:
Yes, when I put Session-Timeout in reply tables it is working except for the limiting the user using sqlcounter dailycounter.
It would have been helpful to describe that at the start. It's difficult to give the correct answer when the question is wrong.
In this case, at least one issue is using Session-Timeout the wrong way. That attribute is meant to go into the reply, as the session timeout. It's not meant to be used in the dailycounter configuration.
i.e. the default dailycounter configuration use "Max-Daily-Session" as the check name, in order to clearly separate the roles of the two different attributes.
Ok
Hope my understanding on how FR dailycounter module works is right and for this to work, the attribute has to be in one of the check tables and when it does, FR is working like a charm. Except that I am not able to find a method to override Session-Timeout in radgroupcheck for specific users by putting the attribute in radcheck table.
Configure the dailycounter module to use Max-Daily-Session.
Don't use Session-Timeout in the check tables. Use Max-Daily-Session.
Done
And then in the radgroupcheck table use "+=" as the operator. The dailycounter module will only look at the first Max-Daily-Session, so that will be fine.
Yes, now it is giving the desired behaviour. Thank you so much. I hope this is the intended method of using attributes/operators in radcheck//radgroupcheck tables (not a workaround). Thanks again. Abraham
participants (3)
-
Abraham Jacob -
Alan DeKok -
Nick Porter