On 27.5.2021 14.58, alexander.hartma...@t-systems.com wrote:
I've tracked down the issue to the poke call at the beginning of
checkForResponses which doesn't return for half a minute sometimes::q
Thanks for the extensive debugging. I don't think this has been reported
before. I started a new Debian 10, installed the same Radiator packages
as you did. For AuthBy DUO specific dependencies, I used apt to install
these: libhttp-async-perl and libnet-https-nb-perl
Attempting the authentication multiple times, I was able to reproduce
the problem. It blocks until there's an answer from DUO API.
Now that the location has been narrowed down to _process_in_progress, a
couple of questions and comments related to your previous message:
1. Does it stop right after it pushes the request to API? That is, not
after a couple of polls that check for user action. That is how it seems
to me. It does preauth and then the actual auth request blocks until
there's some kind of response.
Does it fail constantly for you? I need to do multiple attempts to get
it fail, but eventually it does. In most cases it works as expected.
2. Trace ID values with all zeroes are logged when the logging does not
have a current request available. For example, periodic polling uses all
zeroes.
00000000 Thu May 27 11:24:19 2021: DEBUG: before poke
00000000 Thu May 27 11:24:19 2021: DEBUG: after poke
00000000 Thu May 27 11:24:19 2021: DEBUG: after while loop: 0
00000000 Thu May 27 11:24:19 2021: DEBUG: before poke
00000000 Thu May 27 11:24:52 2021: DEBUG: after poke
00000000 Thu May 27 11:24:52 2021: DEBUG: 200 OK
Digging deeper revealed _process_in_progress is the function called by
poke which doesn´t return in a timely manner.
Is this a known issue?
As mentioned above, it's not. From what I know it's been used
successfully on RHEL/CentOS systems and it works for me on Mac.
Is forking recommended for AuthBy DUO? So far we don´t have Fork in use.
Fork appears not to work with this AuthBy. The forked instance does not
stays around to do polling.
I'd say this is something specific for Debian 10 because the problem is
not that hard to reproduce. This needs further investigation.
Thanks,
Heikki
*Von:* radiator <radiator-boun...@lists.open.com.au> im Auftrag von
Hartmaier, Alexander <alexander.hartma...@t-systems.com>
*Gesendet:* Donnerstag, 27. Mai 2021 12:52
*An:* radiator@lists.open.com.au <radiator@lists.open.com.au>
*Betreff:* [RADIATOR] AuthBy DUO issue
Hi,
today we experienced an issue where two handlers using AuthBy DUO
blocked a whole radiator instance.
It seems to be triggerend when a user doesn't response to the push
notification.
As Radiator is using HTTP::Async this shouldn't happen.
A packet capture of the Duo https api calls and level 5 Radiator trace
shows that the response to the POST takes 60 seconds and contains the
status_msg: "Login timed out.".
During those 60 seconds no other radius requests are handled.
This instance is running Debian 10 with the radiator_4.25-5_all.deb and
radiator-radius-utilxs_2.3-1.buster_amd64.deb packages.
Any ideas what's causing this? I'm out of ideas after reading lots of
HTTP::Async and Radiator source code.
What I noticed it that the level 5 LOG_EXTRA_DEBUG messages are missing
the LogTraceId value.
Thanks, Alex
--
Heikki Vatiainen <h...@open.com.au>
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory,
EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc.
_______________________________________________
radiator mailing list
radiator@lists.open.com.au
https://lists.open.com.au/mailman/listinfo/radiator
