Duo Bypass not Working

[Klint Holmes]

I am seeing an issue in CAS version 5.2.4 and above. I was not seeing the issue in version 5.0.5 which I upgraded from.

If a user is in bypass on the Duo website, CAS returns and error about INVALID_AUTHENTICATION_CONTEXT, but if the it should just let the user throgh.

CAS Info:

CAS Version: 5.2.4

CAS Commit Id: 67d7e128955437619534b5af4819f2379b934353

CAS Build Date/Time: 2018-04-13T21:46:16Z

Spring Boot Version: 1.5.12.RELEASE

------------------------------------------------------------

Java Home: /usr/lib/jvm/java-8-openjdk-amd64/jre

Java Vendor: Oracle Corporation

Java Version: 1.8.0_181

JVM Free Memory: 95 MB

JVM Maximum Memory: 990 MB

JVM Total Memory: 213 MB

JCE Installed: Yes

------------------------------------------------------------

OS Architecture: amd64

OS Name: Linux

OS Version: 4.4.0-130-generic

OS Date/Time: 2018-08-14T09:22:13.889

OS Temp Directory: /tmp/tomcat8-tomcat8-tmp

------------------------------------------------------------

Here are the logs of a login of a user that is in bypass on the Duo side:

2018-08-14 09:23:09,480 INFO [PolicyBasedAuthenticationManager] - <Authenticated principal [klintduotest] with attributes [{displayName=[klintduotest], GOBTPAC_EXTERNAL_USER=[klintduotest], memberOf=[CN=auth_duoOU=groups,DC=example,DC=com], msDS-UserPasswordExpiryTimeComputed=[132094270306397245], pwdLastSet=[131778046306397245], sAMAccountName=[klintduotest]}] via credentials [[klintduotest]].>

2018-08-14 09:23:09,481 INFO [Slf4jLoggingAuditTrailManager] - <Audit trail record BEGIN

=============================================================

WHO: klintduotest

WHAT: Supplied credentials: [klintduotest]

ACTION: AUTHENTICATION_SUCCESS

APPLICATION: CAS

WHEN: Tue Aug 14 09:23:09 MDT 2018

CLIENT IP ADDRESS: 192.168.1.176

SERVER IP ADDRESS: 192.168.1.25

=============================================================

>

2018-08-14 09:23:09,786 INFO [Slf4jLoggingAuditTrailManager] - <Audit trail record BEGIN

=============================================================

WHO: klintduotest

WHAT: [event=mfa-duo,timestamp=Tue Aug 14 09:23:09 MDT 2018,source=RegisteredServicePrincipalAttributeMultifactorAuthenticationPolicyEventResolver]

ACTION: AUTHENTICATION_EVENT_TRIGGERED

APPLICATION: CAS

WHEN: Tue Aug 14 09:23:09 MDT 2018

CLIENT IP ADDRESS: 192.168.1.176

SERVER IP ADDRESS: 192.168.1.25

=============================================================

>

2018-08-14 09:23:10,198 INFO [Slf4jLoggingAuditTrailManager] - <Audit trail record BEGIN

=============================================================

WHO: klintduotest

WHAT: TGT-1-*********************************************************H4tIURR-L4-te-casdev1

ACTION: TICKET_GRANTING_TICKET_CREATED

APPLICATION: CAS

WHEN: Tue Aug 14 09:23:10 MDT 2018

CLIENT IP ADDRESS: 192.168.1.176

SERVER IP ADDRESS: 192.168.1.25

=============================================================

>

2018-08-14 09:23:10,255 INFO [DefaultCentralAuthenticationService] - <Granted ticket [ST-1-Fetae-ngqx0SA86AFbVFmdkssFM-te-casdev1] for service [https://hadoopdev1.weber.edu/casdev1/] and principal [klintduotest]>

2018-08-14 09:23:10,256 INFO [Slf4jLoggingAuditTrailManager] - <Audit trail record BEGIN

=============================================================

WHO: klintduotest

WHAT: ST-1-Fetae-ngqx0SA86AFbVFmdkssFM-te-casdev1 for https://hadoopdev1.weber.edu/casdev1/

ACTION: SERVICE_TICKET_CREATED

APPLICATION: CAS

WHEN: Tue Aug 14 09:23:10 MDT 2018

CLIENT IP ADDRESS: 192.168.1.176

SERVER IP ADDRESS: 192.168.1.25

=============================================================

>

2018-08-14 09:23:10,382 INFO [Slf4jLoggingAuditTrailManager] - <Audit trail record BEGIN

=============================================================

WHO: klintduotest

WHAT: ST-1-Fetae-ngqx0SA86AFbVFmdkssFM-te-casdev1

ACTION: SERVICE_TICKET_VALIDATED

APPLICATION: CAS

WHEN: Tue Aug 14 09:23:10 MDT 2018

CLIENT IP ADDRESS: 192.168.1.35

SERVER IP ADDRESS: 192.168.1.25

=============================================================

>

2018-08-14 09:23:10,393 WARN [DefaultAuthenticationContextValidator] - <No satisfied multifactor authentication providers are recorded in the current authentication context.>

CAS Response:

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>

   <cas:authenticationFailure code="INVALID_AUTHENTICATION_CONTEXT">The validation request for [&#39;ST-1-Fetae-ngqx0SA86AFbVFmdkssFM-te-casdev1&#39;] cannot be satisfied. The request is either unrecognized or unfulfilled.</cas:authenticationFailure>

</cas:serviceResponse>

[Klint Holmes]

Here is some additional information about the issue I am seeing with CAS not accepting Duo bypass.

Here are the responses from Duo for each kind of authentication.

Bypass (Not Working)

2018-08-15 09:12:38,663 DEBUG [BaseDuoSecurityAuthenticationService] - <Contacting Duo to inquire about username [klintduotest]>

2018-08-15 09:12:38,921 DEBUG [BaseDuoSecurityAuthenticationService] - <Received Duo admin response [{"response": {"result": "allow", "status_msg": "Logging you in automatically..."}, "stat": "OK"}]>

2018-08-15 09:12:38,921 DEBUG [DefaultDuoMultifactorAuthenticationProvider] - <Found duo user account status [org.apereo.cas.adaptors.duo.DuoUserAccount@49754dc2[status=ALLOW,enrollPortalUrl=<null>]] for [klintduotest]>

2018-08-15 09:12:38,921 DEBUG [DefaultDuoMultifactorAuthenticationProvider] - <Account status is set for allow/bypass for [klintduotest]>

Normal User not in bypass by Duo:

2018-08-15 09:13:27,126 DEBUG [BaseDuoSecurityAuthenticationService] - <Contacting Duo to inquire about username [klintholmes]>

2018-08-15 09:13:27,222 DEBUG [BaseDuoSecurityAuthenticationService] - <Received Duo admin response [{"response": {"devices": REMOVED}>

2018-08-15 09:13:27,222 DEBUG [DefaultDuoMultifactorAuthenticationProvider] - <Found duo user account status [org.apereo.cas.adaptors.duo.DuoUserAccount@a0af2d9[status=AUTH,enrollPortalUrl=<null>]] for [klintholmes]>

2018-08-15 09:13:27,222 DEBUG [BaseDuoSecurityAuthenticationService] - <Contacting Duo to inquire about username [klintholmes]>

2018-08-15 09:13:27,335 DEBUG [BaseDuoSecurityAuthenticationService] - <Received Duo admin response [{"response": {"devices": REMOVED}>

2018-08-15 09:13:27,335 DEBUG [DefaultDuoMultifactorAuthenticationProvider] - <Found duo user account status [org.apereo.cas.adaptors.duo.DuoUserAccount@5e565608[status=AUTH,enrollPortalUrl=<null>]] for [klintholmes]>

2018-08-15 09:13:27,336 DEBUG [BaseDuoSecurityAuthenticationService] - <Contacting Duo to inquire about username [klintholmes]>

2018-08-15 09:13:27,424 DEBUG [BaseDuoSecurityAuthenticationService] - <Received Duo admin response [{"response": {"devices": REMOVED}>

2018-08-15 09:13:39,281 DEBUG [BasicDuoSecurityAuthenticationService] - <Calling DuoWeb.verifyResponse with signed request token '[AUTH|REMOVED|REMOVED|REMOVED|REMOVED'>

2018-08-15 09:13:39,281 DEBUG [DuoAuthenticationHandler] - <Response from Duo verify: [klintholmes]>

2018-08-15 09:13:39,281 INFO [DuoAuthenticationHandler] - <Successful Duo authentication for [klintholmes]>

2018-08-15 09:13:39,281 INFO [PolicyBasedAuthenticationManager] - <Authenticated principal [klintholmes] with attributes [{}] via credentials [[[username=klintholmes,signedDuoResponse=AUTH|REMOVED|REMOVED|REMOVED|REMOVED]]].>

[Klint Holmes]

Found some more logs that might help find where the issue is happening. Looks like DefaultDuoMultifactorAuthenticationProvider does not support the the bypass on the Duo side.

2018-08-15 15:19:13,943 DEBUG [AbstractMultifactorAuthenticationProvider] - <[DefaultDuoMultifactorAuthenticationProvider] voted does not support this authentication request>

.......

2018-08-15 15:19:14,052 DEBUG [DefaultAuthenticationContextValidator] - <Attempting to match requested authentication context [mfa-duo] against [[]]>

2018-08-15 15:19:14,052 DEBUG [DefaultAuthenticationContextValidator] - <No authentication context could be determined based on authentication attribute [authnContextClass]>

2018-08-15 15:19:14,052 WARN [DefaultAuthenticationContextValidator] - <No satisfied multifactor authentication providers are recorded in the current authentication context.>

2018-08-15 15:19:16,572 DEBUG [WebApplicationServiceFactory] - <No service is specified in the request. Skipping service creation>

I am not sure if this is the area that is causing the issue and if this is now the expected behavior in the following file:

cas/support/cas-server-support-duo-core-mfa/src/main/java/org/apereo/cas/adaptors/duo/authn/DefaultDuoMultifactorAuthenticationProvider.java

...
        if (acct.getStatus() == DuoUserAccountAuthStatus.ALLOW) {

            LOGGER.debug("Account status is set for allow/bypass for [{}]", principal);

            return false;

        }
...

Should this return true if they are set in bypass?

Let me know if there is any other information that I can provide to help find the cause of this issue.