Connection reject does not work as expected when running freeradius as a service

Question
1

Hi!
I’m using a fresh install of PrivacyIDEA 3.6 on Ubuntu 20.04.
I have configured "TIMEOUT = 30 " parameter in /etc/privacyidea/rlm_perl.ini.
When I test freeradius with “freeradius -X” command everything works as expected so if I ignore (or press Decline button) push request on my phone then my connection attempt is rejected after ~30 seconds (or right after pressing Decline button).
But when I start freeradius as a service my connection attempt continues for ~1min 30sec before my connection attempt rejects (even if I press Decline button).
If I press Allow button everything works as expected in both cases.
What could be the reason of that?
Thanks!

2

The reason might be, that in one case you are issuing a test request and in the other case you are trying to login via your RADIUSClient/VPN/Application. Am I right?

3

Actually no :slight_smile: I do absolutely the same process in both cases. Same user, same push (poll only) token, same phone with PI Authenticator app. Tried on several users - same result.
I’m using PI for RD Gateway if it matters.

4

Hi! I’m still trying to figure out the reason of such a behavior. And here are my new findings.

  1. I have reinstalled privacyIDEA and freeradius plugin again on fresh ubuntu 20.04 regarding this manual: 2.2. Ubuntu Packages — privacyIDEA 3.6 documentation
    I have configured just minimal things:
  • ldap resolver
  • realm
  • auth policy:
    push_allow_polling=allow
    push_ssl_verify=0
    push_wait=25
  • enroll policy:
    push_firebase_configuration=poll only
    push_registration_url=https://pi-server-external-ip:port/ttype/push
    push_ssl_verify=0
    push_ttl=1
  • added parameter TIMEOUT=30 to /etc/privacyidea/rlm_perl.ini
  • added client to freeradius clients.conf

So again, Push authentication works fine with my Remote Desktop Gateway if I press Allow in PI App.
But not those things I have wrote about before.

  1. After I have set push_wait to 20 seconds my connection attempt to RemoteDesktop rejects as expected (after ~30sec) it I do not press anything in auth request in PI App. It works even when freeradius works as a service (and with freeradius -X too). Again, if i set push_wait to 25sec and start freeradius service, my connection attempt continues for ~1min 30sec before it rejects. But it works as expected (30 sec) when I start freeradius -X.
    How could that be?

  2. Decline button in PI App doesn’t work for me in all cases. Nothing happens when I press it. I have to wait for 30sec (timeout which is set in rlm_perl). Is it an expected behavior? Can somebody confirm that it should immediately reject my connection attempt?

Thanks!

5

And again, some additional information.
I have noticed that if token’s Fail Counter is reached its maximum and I try to authenticate with this token pressing Accept button, my connection attempt to RD Gateway immediately rejects as expected. So I think it means that PI actually can reject connections to RD Gateway just fine. But Decline button still doesn’t work - I have to wait for timeout. Maybe some bug in the app with Decline button?

6

Could be.

Could also be an implementation error in the server.
Since RADIUS and PUSH are not made for each other, the server simlpy sits and waits before responding to the RADIUS request. Could be, that the declined challenge is not evaluated correctly in the waiting-loop.

7

But as I said before, if token’s Fail Counter is reached its maximum and I try to authenticate with this token pressing Accept button, my connection attempt to RD Gateway immediately rejects as expected.
Doesn’t that mean that declined challenge actually can be evaluated correctly?

8

The decline button is only local on the Authenticator App and does currently not communicate with the server!

9

Now I understand about Decline button, thanks for clarification!
Can you please give some comments about timeouts? Why push_wait works fine if I set it to 20 seconds, and doesn’t work if I set it to 25 or more?

10

push_wait: it waits for the user to hit the accpet button. If the user does not do so, it will wait for the timeout time. Only then, privacyIDEA will respond to the HTTP request.
Then the RADIUS server will receive the failed response from the privacyIDEA HTTP API and return the RADIUS Access Reject.

But: If the RADIUS server is impatient and its timeout is a bit shorter than the push_wait timeout, then it will not receive the failed response from the privacyIDEA server. FreeRADIUS internally has s.th. like an ACCESS_FAIL for this, which means the result could not be determined.

I very much suspect, that the RADIUS server also does not send (in time) the response to the RADIUS client, your RDGW. So what will the RDGW do? It will issue another RADIUS request, since the default setup for most RADIUS clients is retry=3.

This would also result in 3 (retry) x 30 sec timeout in 1 min 30 secs.

Service comment:
Listening to Keith Emerson Band - Lucky Man - YouTube while typing.

11

Cornelius, thanks for your explanation! It confirms my understanding of all that timeouts.

But it seems I have finally found the root cause of my questions. Looks like RDG just has some hardcoded radius timeout value which is 30 sec. And it cannot be changed. So all my modifications in Windows NPS or other timeouts in PI which are more than 30sec were useless :slight_smile:
See here for some details: Remote Desktop Gateway Authentication Timeout Change

Hope this info will help someone who will try to set 30sec or more radius timeout with RDG.

Thanks!

1 Like