nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Admin views a user
Admin clicks "Reset password" in the left column
User receives password reset email
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

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

Accepted answers

All comments

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:

Log Analysis.png

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:

Directory Config.png

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.