How to get FR user check items override group check items

[Abraham Jacob]

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 at deployingradius.com> wrote:
>
> On Nov 15, 2024, at 10:49 AM, Abraham Jacob <abrahamj at 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