How to get FR user check items override group check items

[Alan DeKok]

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.

> 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.