DUO Health Check Fail

[Lipscomb, Gary]

Hi list,

We had an incident on the weekend after a firewall update  caused access to DUO to be blocked and the Health checked failed.
Subsequently any sites requiring MFA failed authentication.
SSO password authentication was OK for non MFA protected sites.


22024-07-28 00:03:10,338 - 203.189.4.16 - ERROR [net.shibboleth.idp.plugin.authn.duo.impl.HealthCheckDuoOIDCAuthAPI:97] - Profile Action HealthCheckDuoOIDCAuthAPI: Duo API health check failed
net.shibboleth.idp.plugin.authn.duo.DuoClientException: Could not execute Duo HTTP request
        at net.shibboleth.idp.plugin.authn.duo.nimbus.impl.NimbusClient.executeRequest(NimbusClient.java:271)
Caused by: java.net.SocketException: Connection reset
        at java.base/java.net.SocketInputStream.read(SocketInputStream.java:186)
2024-07-28 00:03:10,339 - 203.189.4.16 - WARN [org.opensaml.profile.action.impl.LogEvent:101] - A non-proceed event occurred while processing the request: AuthenticationException



>From reading from
https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/1374027959/DuoOIDCAuthnConfiguration#Advanced-Topics



Before each Duo 2FA request, a back-channel lookup is made to Duo’s health check endpoint to determine if the Duo servers are accessible and accepting requests. If for some reason they aren’t, the 2FA attempt fails but the IdP’s authentication flows resume. This is a standard part of Duo’s 2FA workflow. The benefit of this approach is, it occurs before the URL redirect in the browser, and if the Duo 2FA endpoint were not available the IdP remains in control of the authentication process. Otherwise, the user’s browser might timeout during the 2FA request, or the user might get stuck on an error page of some kind.

However, this involves an extra, frequent, back-channel network lookup and as such is subject to the same reliability/availability issues as the actual 2FA request. From investigation, it appears possible to bypass this check and still have the 2FA proceed as normal. Consequently, from v1.3.0 onward we have included a property (idp.duo.oidc.healthcheck.enabled) that allows the deployer to turn off this check.


Should the SSO have just continued , basically bypassing MFA?

Is there a configuration we have missed for MFA?


regards

Gary


Gary Lipscomb

Technical Officer, Systems

IT Infrastructure & Security | Division of Information Technology

Charles Sturt University, Bathurst, NSW 2795

Ph: 02 6338 6533

Email: glipscomb at csu.edu.au<mailto:glipscomb at csu.edu.au>

csu.edu.au<http://www.csu.edu.au/>





[Charles Sturt]<https://www.csu.edu.au>

________________________________

LEGAL NOTICE

This email (including correspondence comprising an email chain and any attachment) is confidential and is intended for the use of the addressee(s) only. If you are not the intended recipient of this email, you must not copy, distribute, take any action in reliance on it or disclose it to anyone.
Any confidentiality is not waived or lost by reason of mistaken delivery. Any email should be checked for viruses and defects before opening. Charles Sturt University does not accept liability for viruses or any consequence which arise as a result of this email transmission. Email communications with Charles Sturt University may be subject to automated email filtering, which could result in the delay or deletion of a legitimate email before it is read at Charles Sturt University. The views expressed in this email are not necessarily those of Charles Sturt University.

Charles Sturt University in Australia<https://www.csu.edu.au> The Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 (ABN: 83 878 708 551). Charles Sturt University - TEQSA Provider Identification: PRV12018 (Australian University). CRICOS Provider: 00005F.

Consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20240731/6f88f182/attachment.htm>