DUO ByPass unenrolled users broken?

101 views
Skip to first unread message

atilling

unread,
Feb 21, 2019, 9:39:18 AM2/21/19
to CAS Community
CAS version 5.1.9 using MFA with DUO. We had this working fine for about two years at this point. Tuesday it started causing problems for our unenrolled users. We have the DUO setting "allow unenrolled users to pass through without two-factor authentication" but sometime around 5 pm Tuesday all unenrolled users started getting the error "The validation request for ['ST-...'] cannot be satisfied. The request is either unrecognized or unfulfilled." whenever logging into a Duo protected service.

Has anyone else experienced this? Did something change with Duo in the last 72 hours? We had to turn off Duo for these services and we don't want to keep it off.

Any help would be appreciated. 

Travis Schmidt

unread,
Feb 21, 2019, 12:21:27 PM2/21/19
to CAS Community
Nothing has recently changed in your CAS Config?  

If you can set this class to debug logging level org.apereo.cas.authentication.DefaultAuthenticationContextValidator. That should give you some insight into perhaps why this is getting hit.

--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/d6587944-0b2a-492c-9922-b84d0047486f%40apereo.org.

Greg Booth

unread,
Feb 21, 2019, 12:30:34 PM2/21/19
to cas-...@apereo.org
We are seeing this issue as well, CAS 5.3.4 using MFA with Duo. We believe it is an issue Duo has introduced with their new API. See the yellow box under “User Account Status”: https://apereo.github.io/cas/5.3.x/installation/DuoSecurity-Authentication.html#user-account-status

Rather than wait for Duo to fix this, we are looking into ways to bypass this issue without disabling Duo entirely on our services, using Multifactor Authentication Bypass:

Have not gotten anywhere with this yet, if anyone has experience with those config settings, we could use your help.

Greg

--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/d6587944-0b2a-492c-9922-b84d0047486f%40apereo.org.


--
Gregory Booth
Senior Systems Administrator & Technical Team Lead
IT Operations
Information Technology
Michigan Technological University

Travis Schmidt

unread,
Feb 21, 2019, 12:38:17 PM2/21/19
to CAS Community
Ok, That might explain it.  Does the Duo iframe screen then flash by now for these users when in the past it did not?

One way to get around possibly.  If you have an attribute available that marks a user has being enrolled in Duo, You can set a trigger to enforce Duo on only those users, with name attribute values or groovy script.  Trade off being is that all services will require Duo for anyone enrolled in Duo, but you should be able to set bypass flags in services or a bypass script.  Depending on how you are set up to use Duo now, this could be a big or small change.

Travis

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAH%2BQwmhzWZgfTVapQ--LXEcNnOLF-dwC%2B%3D6zSLAtnF0hSnN2Vw%40mail.gmail.com.

Richard Frovarp

unread,
Feb 21, 2019, 2:02:28 PM2/21/19
to cas-...@apereo.org
5.1 uses a broken method for bypassing Duo. Or at least broken in some respects. That's why you get the flash on the screen. 5.1 actually triggers the widget, and the widget is doing the bypass. CAS doesn't know, so all of your users under 5.1 are asserting via attribute release that they have performed MFA, when in fact they may not have.

5.2+ added a method that makes an API call to see if the user can bypass. If the user can bypass, they don't get the MFA iframe appearing. It also then doesn't assert that MFA has happened when it hasn't.

What we're doing is that everyone that has to MFA is in an AD group. We use that to trigger MFA. The Duo integration is configured to always require MFA, because anyone sent to it will have been asserted by AD to require Duo. If you need to bypass Duo, you just change the CAS config to point to an AD group that doesn't exist, touch the file, and away it goes. Handy for when Duo is down, or your own network is down.

Travis Schmidt

unread,
Feb 21, 2019, 2:20:04 PM2/21/19
to CAS Community
All true, but I guess I am still confused by what Duo is doing.  If pre-auth just returns AUTH in all cases then what does it return for a bypassed user in Duo from the Iframe?  If it is a signed response then everything should be good and CAS would assume the user was authenticated with Duo.  Any other return value I think would result in an authentication error and the user would not be allowed to continue.

Travis

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/985ac6a9-1263-c9d1-6257-bdc22f948bfd%40ndsu.edu.

Mailvaganam, Hari

unread,
Feb 21, 2019, 3:11:07 PM2/21/19
to cas-...@apereo.org

https://community.duo.com/c/using-duo/release-notes

 

There isn’t anything in the Duo release notes for changes on 21st Feb….

 

We are on CAS5.3.4 – no impact so far – however if related to user-status, we check this upfront outside of Duo.

 

Best regards,

 

Hari Mailvaganam 
Access Application Architect, Identity & Access Management (IAM)

Cybersecurity | CISO Office

The University of British Columbia | Musqueam Traditional Territory
420 - 6356 Agricultural Road | Vancouver BC | V6T1Z2 Canada
Phone 604 827 5117

Privacy Matters @ UBC

Richard Frovarp

unread,
Feb 21, 2019, 4:16:23 PM2/21/19
to cas-...@apereo.org
Theoretically pre-auth follows the configuration of the integration. So if the integration returns allow or bypass (been a while since I looked at it to remember exact value), the CAS 5.2+ code won't trigger the Duo iframe to even display. I can't remember if the CAS code was doing the pre-auth with or without the IP. I think it was without.

The key thing is that the iframe will only ever return one value, the username that passed Duo by one method or another. That method may be an actual method, IP, remember me, or not registered with the integration letting them through. If the user fails Duo, nothing is ever returned by the iframe. So if the iframe is triggered (like it is in 5.1), and the user is allowed through by not being enrolled and the integration configuration allowing it, then the iframe will return the username back to the application. Since the only value is ever the username, the application has no way of knowing if MFA was triggered  or if the user was bypassed. It's somewhat complicated. It took a decent amount of effort on my part to get Duo to update their documentation to be a slight bit clearer. They didn't see my issue as a security issue, so I need to get a better write up about it out to the greater community.

The best method for bypassing is to have the IdP determine if Duo should be applied, and only trigger Duo for the cases where it needs to be triggered, and have Duo require MFA in all cases it is asked. This is more secure, and perhaps more reliable. We were on Duo 1, which had weird outages that weren't fully detected by various methods. So anyone that wasn't required to do Duo at NDSU, never triggered a check to Duo that was failing, so they weren't even impacted. For us to turn off Duo while Duo 1 was unresponsive, we only had to change the group we were pointing at to something that didn't exist. Thus it would always fail. There was the /ping endpoint, but during those outages it was always reporting success.
Reply all
Reply to author
Forward
0 new messages