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