Multiple Calling of SQL Statements
I want FreeRADIUS 3.0.22 (I can't update now, sorry.) to reject anonymous logins *a**nd* log every successful login to the database. To that end, I wrote three MySQL stored procedures. 1. is_login_allowed -> Checks if the user in the database and has not exceeded his quota etc. 2. log_login -> Logs a successful login to the database. 3. log_mac -> Logs the MAC address of the user's device. Of course, I thought, the most reasonable place to achieve my goal was to place my sproc calls in the inner tunnel, since we always get the real user name there, at least that is my thinking. Here is the site script for my inner tunnel: server inner-tunnel-ttls { listen { ipaddr = 127.0.0.1 port = 18127 type = auth } authorize { * # Custom Script** ** if ("%{sql: CALL is_login_allowed('%{User-Name}', '%{Calling-Station-Id}', '%{Called-Station-Id}')}" == "0" ) {** ** reject** ** }** ** else {** ** "%{sql: CALL log_login('%{User-Name}', '%{Calling-Station-Id}', '%{NAS-IP-Address}')}"** ** "%{sql: CALL log_mac('%{Calling-Station-Id}', '%{User-Name}')}"** ** }* eap { ok = return } sql expiration logintime pap } authenticate { Auth-Type PAP { pap } Auth-Type MS-CHAP { mschap } eap } session { sql } post-auth { update outer.reply { User-Name += &request:User-Name Class += &reply:Class Idle-Timeout += &reply:Idle-Timeout Acct-Interim-Interval += &reply:Acct-Interim-Interval } if (1) { update reply { User-Name !* ANY Message-Authenticator !* ANY EAP-Message !* ANY Proxy-State !* ANY MS-MPPE-Encryption-Types !* ANY MS-MPPE-Encryption-Policy !* ANY MS-MPPE-Send-Key !* ANY MS-MPPE-Recv-Key !* ANY } update { &outer.session-state: += &reply: } } Post-Auth-Type REJECT { -sql attr_filter.access_reject update outer.session-state { &Module-Failure-Message := &request:Module-Failure-Message } } } pre-proxy { } post-proxy { eap } } It is simple, isn't it? And it should work, right? It *does* work. The problem is that for each successful login, I see 4 entries in the database, which suggests that the sproc is called 4 times simultaneously or in quick succession. Can anyone explain to me why this is happening and is there a way I can fix this? Thank you in advance... SCilek -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Jul 27, 2021, at 6:42 AM, Selahattin CILEK <selahattin_cilek@hotmail.com> wrote:
It is simple, isn't it? And it should work, right? It *does* work. The problem is that for each successful login, I see 4 entries in the database, which suggests that the sproc is called 4 times simultaneously or in quick succession. Can anyone explain to me why this is happening and is there a way I can fix this?
Read the debug output to see what FreeRADIUS is doing, and why. All of the documentation says to do this... If you do read the debug output, you'll likely see that PEAP is being used, and that there are multiple rounds of authentication. This is how EAP works. Not only that, PEAP also uses EAP for the inner-tunnel authentication. So... there are also multiple rounds there, too. The default configuration does authorization checks first, and then does logging only in the post-auth section. This is because we don't want logging for every packet. We only want it for the final accept / reject. Alan DeKok.
On 27.07.2021 14:05, Alan DeKok wrote:
On Jul 27, 2021, at 6:42 AM, Selahattin CILEK <selahattin_cilek@hotmail.com> wrote:
It is simple, isn't it? And it should work, right? It *does* work. The problem is that for each successful login, I see 4 entries in the database, which suggests that the sproc is called 4 times simultaneously or in quick succession. Can anyone explain to me why this is happening and is there a way I can fix this? Read the debug output to see what FreeRADIUS is doing, and why. All of the documentation says to do this...
If you do read the debug output, you'll likely see that PEAP is being used, and that there are multiple rounds of authentication. This is how EAP works.
Not only that, PEAP also uses EAP for the inner-tunnel authentication. So... there are also multiple rounds there, too. I see. I was guessing but was not sure.
The default configuration does authorization checks first, and then does logging only in the post-auth section. This is because we don't want logging for every packet. We only want it for the final accept / reject. I see. So is there somewhere specific you would recommend for those SQL statements to be? I mean, where would they be run only once?
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Jul 28, 2021, at 6:44 AM, Selahattin CILEK <selahattin_cilek@hotmail.com> wrote:
The default configuration does authorization checks first, and then does logging only in the post-auth section. This is because we don't want logging for every packet. We only want it for the final accept / reject. I see. So is there somewhere specific you would recommend for those SQL statements to be? I mean, where would they be run only once?
The problem is that you're mixing authorization and logging steps. Don't do that. Split them, like we do in the default configuration. Alan DeKok.
On 28.07.2021 14:14, Alan DeKok wrote:
On Jul 28, 2021, at 6:44 AM, Selahattin CILEK <selahattin_cilek@hotmail.com> wrote:
The default configuration does authorization checks first, and then does logging only in the post-auth section. This is because we don't want logging for every packet. We only want it for the final accept / reject. I see. So is there somewhere specific you would recommend for those SQL statements to be? I mean, where would they be run only once? The problem is that you're mixing authorization and logging steps. Don't do that. Split them, like we do in the default configuration. Moving the SQL calls to the *post-auth* section of the *inner-tunnel-ttls* worked. Thanks.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
participants (2)
-
Alan DeKok -
Selahattin CILEK