[RADIATOR] AuthBy DUO issue

[Heikki Vatiainen]

On 27.5.2021 14.58, Alexander.Hartmaier at 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-bounces at lists.open.com.au> im Auftrag von 
> Hartmaier, Alexander <alexander.hartmaier at t-systems.com>
> *Gesendet:* Donnerstag, 27. Mai 2021 12:52
> *An:* radiator at lists.open.com.au <radiator at 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 <hvn at 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.