CAS 6.2.8 password management and Office 365 ATP

[Joseph Methot]

Hi everyone,

We recently upgraded our CAS server to version 6.2.8 from version 5.3.15.1 . We found out that the behaviour of the password management feature, specifically the password reset link, has changed. It seems that the password reset link is now single use, you can't use it again after clicking on it once even though it's not expired yet.

After investigating the error our users had "Password reset failed - We were unable to process your password reset request at this time", we found out that because we use Office 365 ATP (Advanced Threat Protection), all the links in the email, including the password reset link, are verified and clicked before the user gets the email. This means that the password reset link is already used when it gets to the user's inbox...

I didn't find any configuration related to this in the CAS documentation. I'm now thinking about overriding the class where the password reset token is deleted after use, even though I don't like the idea of having to maintain this change after future CAS updates.

Has anyone had this kind of problem with password management and something like Office 365 ATP and what was your solution?

Thank you!

Joseph

[Chris Durham]

Hey Joseph,

Did you get anywhere with this.  We've been having the same issue and I suddenly connected the dots and realized that we use Office 365 too..

Chris

[Joseph Methot]

Hi Chris,

If you have ATP activated and the password reset emails are only sent within your own organization, you can ask your Office 365 admin to whitelist the CAS server, this way ATP won't invalidate the password reset link. However, if they can be sent to multiple organizations (who might also have Office 365 and ATP activated) it would not be a practical solution to ask all of them to whitelist your CAS server. I ended up overriding the VerifyPasswordResetRequestAction class to remove the line that deletes the ticket. The ticket is still expired after the configured delay, so it solved our problem with password management.

Joseph

[Chris Durham]

Hi Joseph,

Our emails will be going to many different organizations that we have no control over, so overriding that class might be our only option too.  

Do you use the overlay method - and if so how do you override a single class without having to import tons of stuff?

Chris

[Joseph Methot]

Hi Chris,

Yes I use the overlay method. I created the package structure for that class in my overlay, and then copied the class from github for my CAS version. I also had to add a few dependencies in the build.gradle file to compile the overlay.

Joseph

[Chris Durham]

Would you mind sharing the additions in the build.gradle and the package structure you used?   I'm using 6.4.0-RC6, but I suspect once I understand what you had to add it should be transferrable logic wise

I've been trying to overlay classes to fix issues (or support our apparently unique requirements), but have been unable to get it to compile without complaining about lots and lots of missing dependencies.

BTW i submitted a pull request with a custom patch that allowed you to specify whether the Password Management TST was single use or not, but it was rejected (with a reasonable explanation at least!)

[Ray Bon]

Chris,

When you get a missing dependency, search your local copy of cas for that class. Once you have the path, you can include that package in build.gradle.

e.g.

    compileOnly "org.apereo.cas:cas-server-support-token-core-api:${casServerVersion}"

    compileOnly "org.apereo.cas:cas-server-support-token-tickets:${casServerVersion}"

Ray

On Tue, 2021-07-27 at 12:59 -0700, Chris Durham wrote:

Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information.

[Chris Durham]

Ray,

Thanks for that -  it all makes a lot more sense now - and after a bit of trial and error of figuring out what to include (the lombok stuff threw me) I've got it to compile - yay!

Chris

[Kink]

Hi Chris, Joseph,

No, you are not alone. I have been searching the doc, testing 6.4 (without success a few months back, likely at a too early stage where pm was completely bugged) about this pm reset ticket being destroyed on its first use. It has driven me nuts for months.

The 1 opening of the TST reset ticket is a dead end when:

-  having users from multiple horizons and some under highly secured environments (gov) where links inside emails are pre opened by their security solutions

- users use Outlook Web Access which has the link preview activated by default

- users of Windows with remnant Internet Explorer declared as the default internet browser in the OS

      - upon the first opening, IE opens but the handling of the scripts for input overlay (pushing the labels away from the input box), password strength feature, and the enabling of the submit button are not working (yes, gov users... what else?)

I would very much like to be able to set the number of times TST reset token could stay alive. To me this should be a native feature of CAS as for its TTL property.

I clearly understand why it should get destroyed but the 1 opening is a generating tons of user support requests, that is when people actually ask for support instead of simply abandoning.

I am no longer up to speed for developments, despite understanding it, especially when it comes to overlay and the complexity of CAS. Setting it up, modifying some parts of the interface has already been a huge challenge for me.

Could one of you elaborate on how I can get around this TST self destruct on the 1st opening?

I will be thankful for ever :-)

Pierre