Reset Password not working in Crowd v3.5.0

[Dov Frankel]

Since recently upgrading to v3.5.0 (from 3.2.0), something I did frequently is no longer working. I think this is a bug.

Steps

1. Admin views a user
2. Admin clicks "Reset password" in the left column
3. User receives password reset email
4. User clicks link in email

Expected: User enters a new password and is able to log into crowd

Actual: Clicking on the link results in "We can't reset your password"

Workaround

1. Admin manually sets the user's password
2. Admin sets the requiresPasswordChange attribute to true
3. Give user temporary password and ask him to log in
4. Once logged in, user assigns new password

[Stephen Sifers]

Hello Dov,

Thanks for reaching out and including the steps and screenshots of your issue. We’ve attempted to recreate this issue with Crowd and have been unsuccessful in doing so. That’s not to say that there isn’t a bug, we just can’t recreate it. Before we go further into chasing a possible bug, could you confirm something for us?

Could you please confirm you users have access to Crowd as authorized users and are not administrators of Crowd? We want to check this for the following reason:

Non-administrators cannot affect other users or the Crowd installation

Granting Crowd user rights will give your users the power to update their own profiles and passwords and view their authorization details. But they will not be able to view or update other user profiles, nor perform any Crowd administration functions.

Source documentation: Granting Crowd User Rights to a User

We look forward to hearing back!

Regards,
Stephen Sifers

[Dov Frankel]

I didn't have the "Allow all users from this directory to authenticate" setting turned on for the "Crowd" application, but it was set to allow authentication for our "crowd-users" and "crowd-administrators" groups, one of which the user was a member ("crowd-users"). I turned "Allow all users from this directory to authenticate" on, and I still get the same error when I click the password reset link for a test account.

We're only using Crowd's internal directory, and no others.

[Stephen Sifers]

Hello Dov,

Thank you for getting back and ensuring your users are allowed to access crowd. I retested on Crowd 3.5 with an internal directory and confirmed when a user is sent a reset password email that the link within the email works as expected. To find out what's causing this issue we’ll need to review the logs, please use the support tools within Crowd to analyze the logs and let us know of the findings:

• For Crowd (2.11 and later) go to  the cog  > Support Tools

Support Tools Plugin

We look forward to hearing back to figure out what's causing the issue with Crowd.

Regards,
Stephen Sifers

[Dov Frankel]

This is what the log analysis shows:

The second one is from a year ago, whereas the first one says it's happened 5 times, the most recent being two days ago. I clicked on the link, and checked the setting it mentioned, and our config is already set up not to let passwords expire. I believe that error was because the user I was configuring did not have access to Crowd at first, but I had fixed that. Here's our Crowd directory configuration:

I reproduced the issue again just now, and re-analyzed the logs, and it still shows that error last happening 2 days ago. I tailed the logs into a file while I sent the reset and then opened the link. This is what the log contains:

2019-08-07 15:04:15,464 http-nio-8095-exec-7 INFO [crowd.manager.login.ForgottenLoginManagerImpl] "test" in directory "ORP Crowd server" is being e-mailed a password reset link.
2019-08-07 15:04:15,470 http-nio-8095-exec-7 INFO [javax.mail] JavaMail version 1.4.7
2019-08-07 15:04:15,482 http-nio-8095-exec-7 INFO [javax.mail] successfully loaded resource: /META-INF/javamail.default.providers
2019-08-07 15:04:15,482 http-nio-8095-exec-7 INFO [javax.mail] Tables of loaded providers
2019-08-07 15:04:15,482 http-nio-8095-exec-7 INFO [javax.mail] Providers Listed By Class Name: {com.sun.mail.smtp.SMTPSSLTransport=javax.mail.Provider[TRANSPORT,smtps,com.sun.mail.smtp.SMTPSSLTransport,Oracle], com.sun.mail.smtp.SMTPTransport=javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Oracle], com.sun.mail.imap.IMAPSSLStore=javax.mail.Provider[STORE,imaps,com.sun.mail.imap.IMAPSSLStore,Oracle], com.sun.mail.pop3.POP3SSLStore=javax.mail.Provider[STORE,pop3s,com.sun.mail.pop3.POP3SSLStore,Oracle], com.sun.mail.imap.IMAPStore=javax.mail.Provider[STORE,imap,com.sun.mail.imap.IMAPStore,Oracle], com.sun.mail.pop3.POP3Store=javax.mail.Provider[STORE,pop3,com.sun.mail.pop3.POP3Store,Oracle]}
2019-08-07 15:04:15,483 http-nio-8095-exec-7 INFO [javax.mail] Providers Listed By Protocol: {imaps=javax.mail.Provider[STORE,imaps,com.sun.mail.imap.IMAPSSLStore,Oracle], imap=javax.mail.Provider[STORE,imap,com.sun.mail.imap.IMAPStore,Oracle], smtps=javax.mail.Provider[TRANSPORT,smtps,com.sun.mail.smtp.SMTPSSLTransport,Oracle], pop3=javax.mail.Provider[STORE,pop3,com.sun.mail.pop3.POP3Store,Oracle], pop3s=javax.mail.Provider[STORE,pop3s,com.sun.mail.pop3.POP3SSLStore,Oracle], smtp=javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Oracle]}
2019-08-07 15:04:15,483 http-nio-8095-exec-7 INFO [javax.mail] successfully loaded resource: /META-INF/javamail.default.address.map
2019-08-07 15:04:47,250 http-nio-8095-exec-25 WARN [common.security.jersey.XsrfResourceFilter] Additional XSRF checks failed for request: http://crowd.orp.bluealba.com/crowd/rest/account/1/token-status , origin: https://crowd.orp.bluealba.com , referrer: https://crowd.orp.bluealba.com/crowd/console/login.action , credentials in request: true , allowed via CORS: false

It looks like the XSRF checks may be an issue? Maybe? Not sure if they are, and if so, what to do about it. I didn't mention before, but we're hosted on CentOS with a PostgreSQL DB, in case that matters.

[Stephen Sifers]

Hello Dov,

Thank you for reviewing the logs and sifting through them. Additionally, your tailed log does show some of the possible issue we need to resolve. If you’re using a proxy then you’ll need to modify your server.xml file to allow communication. There is a similar post to this that already exists and we would suggest reviewing the solution within there to see if it helps:

Crowd XSRF check failed

Please let us know if this assists with fixing your password reset email links.

Regards,
Stephen Sifers

[Dov Frankel]

That was definitely it. I updated the reverse proxy settings in the Tomcat server.xml, and now it's working. May I please suggest that this step be mentioned in the Crowd upgrade guide? I followed it during this upgrade, and it doesn't mention to copy over the server.xml settings from the old installation. Atlassian's other upgrade guides, for Confluence, Jira, and Bamboo do mention that, and I didn't have this problem with those.

I was about to accept the answer, but should you edit it first to mention the specific fix we arrived at?

[Stephen Sifers]

Hello Don,

I reviewed your referenced documentation and did not find any reference to migrating your server.xml file on upgrade. I have submitted feedback on that article to have it reviewed and updated.

Additionally, your crowd instance should also avoid being exposed externally and kept internally (Suggested to not allow Inbound traffic). While configuring it to allow communication through your proxy may be required, we would caution against exposing your Crowd instance externally. Just including this note in the event it's externally available.

Regards,
Stephen Sifers