SQL Simultaneous usage checks
Hi, I've replaced an ancient FR 1.1.3 system with FR 3.0.17 from Debian buster and subsequently appear to be experiencing a problem where I would like user attributes to take precedence over those returned from the associated user's group. I don't appear to find any references on the legacy system where this appears to have been changed and am a little stuck on how to get the new system to behave the same way.
From a debug: (2) sql: User found in radcheck table (2) sql: Conditional check items matched, merging assignment check items (2) sql: User-Password := "************" (2) sql: Simultaneous-Use := 20 (2) sql: Max-Monthly-Traffic := 2450000 <snip> (2) sql: Group "ADSL_Local_1G": Merging assignment check items (2) sql: Simultaneous-Use := 4 (2) sql: Max-Monthly-Traffic := 1000 <snip> (2) Multiple logins (max 4) : [companyd2382@local.dslrealm.co.za] (from client telkom-saix port 4444444444 cli 0112223333)
Would this require us to change the source code, to obtain the group membership attributes ahead of those associated with the user? Regards David Herselman
On Jul 20, 2021, at 11:22 AM, David Herselman via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I've replaced an ancient FR 1.1.3 system with FR 3.0.17 from Debian buster and subsequently appear to be experiencing a problem where I would like user attributes to take precedence over those returned from the associated user's group.
See: https://wiki.freeradius.org/modules/Rlm_sql The operators are documented there.
I don't appear to find any references on the legacy system where this appears to have been changed and am a little stuck on how to get the new system to behave the same way.
I don't think it changed, but it's been a while since I looked at version 1. The operators have been in SQL, and the SQL module works the same way for a very long time now.
From a debug: (2) sql: User found in radcheck table (2) sql: Conditional check items matched, merging assignment check items (2) sql: User-Password := "************"
Use: Cleartext-Password := ...
(2) sql: Simultaneous-Use := 20 (2) sql: Max-Monthly-Traffic := 2450000 <snip> (2) sql: Group "ADSL_Local_1G": Merging assignment check items (2) sql: Simultaneous-Use := 4
Use Simultaneous-Use += 4
(2) sql: Max-Monthly-Traffic := 1000 <snip> (2) Multiple logins (max 4) : [companyd2382@local.dslrealm.co.za] (from client telkom-saix port 4444444444 cli 0112223333)
Would this require us to change the source code, to obtain the group membership attributes ahead of those associated with the user?
No. Alan DeKok.
Hi Alan, Thank you for your feedback. A debug on the legacy FR v1 system is unfortunately not as granular as with FR v3, but it would appear that FR v1 (perhaps incorrectly) didn't replace := values from the SQL radcheck table with ':=' values returned by radgroupcheck. ie: If radcheck returned Simultaneous-Use := 20 and radgroupcheck returned Simultaneous-Use := 4 it gets set as 20. If radcheck didn't have this attribute defined for the user it would only get the value from radgroupcheck and subsequently set it as 4. Reading through https://wiki.freeradius.org/config/Operators bring me hope that I could possibly set the radcheck operator for this attribute as ':=' and then set the radgroupcheck operator as '=', but I'm concerned about the comment in the documentation that this is 'Not allowed as a check item for RADIUS protocol attributes.' My understanding of using the '+=' operator is that the resulting value would be 24, is this incorrect? PS: Thank you for your recommendation on replacing 'User-Password' with 'Cleartext-Password'. This is on the cards, but we have to allow for a transition period where legacy and new FR nodes reference a common database. We are subsequently using unlang to do the following before pap in the authorize section: if (!control:Cleartext-Password && control:User-Password) { update control { Cleartext-Password := "%{control:User-Password}" User-Password !* ANY } } Regards David Herselman -----Original Message----- From: Alan DeKok <aland@deployingradius.com> Sent: Tuesday, 20 July 2021 5:31 PM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Cc: David Herselman <dhe@syrex.co> Subject: Re: SQL Simultaneous usage checks On Jul 20, 2021, at 11:22 AM, David Herselman via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I've replaced an ancient FR 1.1.3 system with FR 3.0.17 from Debian buster and subsequently appear to be experiencing a problem where I would like user attributes to take precedence over those returned from the associated user's group.
See: https://wiki.freeradius.org/modules/Rlm_sql The operators are documented there.
I don't appear to find any references on the legacy system where this appears to have been changed and am a little stuck on how to get the new system to behave the same way.
I don't think it changed, but it's been a while since I looked at version 1. The operators have been in SQL, and the SQL module works the same way for a very long time now.
From a debug: (2) sql: User found in radcheck table (2) sql: Conditional check items matched, merging assignment check items (2) sql: User-Password := "************"
Use: Cleartext-Password := ...
(2) sql: Simultaneous-Use := 20 (2) sql: Max-Monthly-Traffic := 2450000 <snip> (2) sql: Group "ADSL_Local_1G": Merging assignment check items (2) sql: Simultaneous-Use := 4
Use Simultaneous-Use += 4
(2) sql: Max-Monthly-Traffic := 1000 <snip> (2) Multiple logins (max 4) : [companyd2382@local.dslrealm.co.za] (from client telkom-saix port 4444444444 cli 0112223333)
Would this require us to change the source code, to obtain the group membership attributes ahead of those associated with the user?
No. Alan DeKok.
On Jul 21, 2021, at 8:03 AM, David Herselman <dhe@syrex.co> wrote:
Thank you for your feedback. A debug on the legacy FR v1 system is unfortunately not as granular as with FR v3, but it would appear that FR v1 (perhaps incorrectly) didn't replace := values from the SQL radcheck table with ':=' values returned by radgroupcheck.
Quite possibly. That version has been EOL for probably 10 years. In fact, even version 2 has been EOL for many years.
Reading through https://wiki.freeradius.org/config/Operators bring me hope that I could possibly set the radcheck operator for this attribute as ':=' and then set the radgroupcheck operator as '=', but I'm concerned about the comment in the documentation that this is 'Not allowed as a check item for RADIUS protocol attributes.'
My understanding of using the '+=' operator is that the resulting value would be 24, is this incorrect?
That's not correct. See the documentation for the "+=" operator. And yes, you could use ":=" for radcheck, and "=" for radgroupcheck. That would work, too.
PS: Thank you for your recommendation on replacing 'User-Password' with 'Cleartext-Password'. This is on the cards, but we have to allow for a transition period where legacy and new FR nodes reference a common database. We are subsequently using unlang to do the following before pap in the authorize section: if (!control:Cleartext-Password && control:User-Password) { update control { Cleartext-Password := "%{control:User-Password}"
Just do Cleartext-Password := &control:User-Password There's no need to expand it to a string, and then parse it back as a string. Alan DeKok.
participants (2)
-
Alan DeKok -
David Herselman