Hi there, I'm having trouble getting the do_not_respond policy working in the post-auth section with FreeRADIUS 3.0.17. I've got a minimal testcase, reproduced with an almost-default 3.0.17 config built from (I only disabled EAP, removed EAP references from sites-enabled/default and enabled test user "bob" in mods-config/files/authorize). I can insert do_not_respond at the top of the authorize or authenticate sections, and I get the expected behaviour (no response sent and "Not responding to request", "Not sending reply to client" messages in the "radiusd -X" output). E.g.: authenticate { Auth-Type PAP { do_not_respond ... If I insert do_not_respond at the top of the post-auth section, then an Access-Accept response is sent. E.g.: post-auth { do_not_respond ... Here are the differences between the "radiusd -X" output working vs. not-working: Working (do_not_respond in authenticate section): (0) Found Auth-Type = PAP (0) # Executing group from file .../freeradius-server-3.0.17/raddb/sites-enabled/default (0) Auth-Type PAP { (0) policy do_not_respond { (0) update control { (0) &Response-Packet-Type := Do-Not-Respond (0) } # update control = noop (0) [handled] = handled (0) } # policy do_not_respond = handled (0) } # Auth-Type PAP = handled (0) Not responding to request (0) # Executing section post-auth from file .../freeradius-server-3.0.17/raddb/sites-enabled/default (0) post-auth { (0) update { (0) No attributes updated (0) } # update = noop (0) [exec] = noop (0) } # post-auth = noop (0) Not sending reply to client. (0) Finished request Not working (do_not_respond in post-auth section): (0) Found Auth-Type = PAP (0) # Executing group from file .../freeradius-server-3.0.17/raddb/sites-enabled/default (0) Auth-Type PAP { (0) pap: Login attempt with password (0) pap: Comparing with "known good" Cleartext-Password (0) pap: User authenticated successfully (0) [pap] = ok (0) } # Auth-Type PAP = ok (0) # Executing section post-auth from file .../freeradius-server-3.0.17/raddb/sites-enabled/default (0) post-auth { (0) policy do_not_respond { (0) update control { (0) &Response-Packet-Type := Do-Not-Respond (0) } # update control = noop (0) [handled] = handled (0) } # policy do_not_respond = handled (0) } # post-auth = handled (0) Sent Access-Accept Id 73 from 127.0.0.1:1812 to 127.0.0.1:59268 length 0 (0) Reply-Message = "Hello, bob" (0) Finished request My ultimate goal is to do this conditionally from rlm_perl, such as described here: http://lists.freeradius.org/pipermail/freeradius-users/2015-September/079600... but when I try that, I see the same results as above, which is how I came up with this minimal test case. Thanks, Geoffrey.
On Apr 24, 2018, at 1:35 AM, Geoffrey D. Bennett <g@netcraft.com.au> wrote:
I'm having trouble getting the do_not_respond policy working in the post-auth section with FreeRADIUS 3.0.17.
It's not meant to run there. The post-auth section is run *after* it decides what kind of response to send.
My ultimate goal is to do this conditionally from rlm_perl, such as described here: http://lists.freeradius.org/pipermail/freeradius-users/2015-September/079600... but when I try that, I see the same results as above, which is how I came up with this minimal test case.
You can do it, but not from the post-auth section. Alan DeKok.
On Tue, Apr 24, 2018 at 09:05:43PM +0930, Alan DeKok wrote:
On Apr 24, 2018, at 1:35 AM, Geoffrey D. Bennett <g@netcraft.com.au> wrote:
I'm having trouble getting the do_not_respond policy working in the post-auth section with FreeRADIUS 3.0.17.
It's not meant to run there.
The post-auth section is run *after* it decides what kind of response to send.
Hi Alan, Thanks for your reply. My use case for this is that I have a database lookup in the post-auth section, and if the database connection fails I need to return no response so that the NAS will send its request to the other RADIUS server which has the backup database. Is there another way to do this from the post-auth section? I can't move these checks into the authorise section as they have to run after authentication. What do you think about adding support for this? Could you point me in the appropriate direction to implement this if you'd accept such a patch? Thanks, Geoffrey.
On Apr 25, 2018, at 10:09 PM, Geoffrey D. Bennett <g@netcraft.com.au> wrote:
My use case for this is that I have a database lookup in the post-auth section, and if the database connection fails I need to return no response so that the NAS will send its request to the other RADIUS server which has the backup database.
That's useful, I must admin.
Is there another way to do this from the post-auth section?
Not really. We would have to change the source code.
I can't move these checks into the authorise section as they have to run after authentication. What do you think about adding support for this?
You can just list the rules in the "authenticate" section. e.g. authenticate { Auth-Type PAP { # or whatever you use... pap # will reject on failure do_database_stuff } ... }
Could you point me in the appropriate direction to implement this if you'd accept such a patch?
src/main/process.c. Look for "Not responding to request". And try to figure it out. :( Honestly, just move the database checks to the "authenticate" section, inside of whatever Auth-Type subsection is running. If you're using SQL, and you need to log to SQL, just do: authenticate { Auth-Type PAP { # or whatever you use... pap # will reject on failure sql.post_auth } ... } Which will run the "post-auth" rules for SQL, but during the "authenticate" phase. Alan DeKok.
On Thu, Apr 26, 2018 at 12:16:23PM +0930, Alan DeKok wrote:
On Apr 25, 2018, at 10:09 PM, Geoffrey D. Bennett <g@netcraft.com.au> wrote:
My use case for this is that I have a database lookup in the post-auth section, and if the database connection fails I need to return no response so that the NAS will send its request to the other RADIUS server which has the backup database.
That's useful, I must admin. [...]
Could you point me in the appropriate direction to implement this if you'd accept such a patch?
src/main/process.c. Look for "Not responding to request". And try to figure it out. :(
Thanks for the pointer. Please find attached a patch relative to v3.0.x. Is this the right way to go about it? Thanks, Geoffrey.
On May 4, 2018, at 1:59 AM, Geoffrey D. Bennett <g@netcraft.com.au> wrote:
Thanks for the pointer. Please find attached a patch relative to v3.0.x. Is this the right way to go about it?
Sort of. The patch checks for it *always*, when I think it's only really needed for Access-Reject packets. I'll take a look. Alan DeKok.
Hi all, Thanks to this thread I discovered the do_not_respond policy, but similarly to the OP issue, we have a use case that would require the do_not_respond policy to be used in post-auth. We set a EAP submodule which presents a bogus certificate and, while some supplicants drop the auth attempt, others (like Android and Windows 7) continue in a way that provokes the FR server to send an Access-Reject packet. Android just attempts the auth a bit later. That's okay. Windows 7 prompts the user with the creds input window. This is not okay. We are actually avoiding doing this to Windows 7 supplicants. We would want the server to drop the Access-Reject packet as if communication was lost so Windows 7 never asks for new credentials in this situation. Could this be in 3.0.x some time? Regards. El mar., 8 may. 2018 a las 16:42, Alan DeKok (<aland@deployingradius.com>) escribió:
On May 4, 2018, at 1:59 AM, Geoffrey D. Bennett <g@netcraft.com.au> wrote:
Thanks for the pointer. Please find attached a patch relative to v3.0.x. Is this the right way to go about it?
Sort of. The patch checks for it *always*, when I think it's only really needed for Access-Reject packets.
I'll take a look.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Alberto Martínez Setién Middleware Comunicación y Sistemas Servicio Informático Universidad de Deusto Avda. de las Universidades, 24 48007 - Bilbao (SPAIN) Phone: +34 944 139 000 Ext. 2859 Fax: +34 944 139 101
On Thu, May 17, 2018 at 09:02:00PM +0930, Alan DeKok wrote:
On May 17, 2018, at 5:13 AM, Alberto Martínez Setién via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Could this be in 3.0.x some time?
The patch is already in the v3.0.x branch on github. It will be in 3.0.18 when it's released.
Thank you!
participants (3)
-
Alan DeKok -
Alberto Martínez Setién -
Geoffrey D. Bennett