Disable password resets (or at least require intervention) for Crowd users?
Asked by KMP:

We're looking at possibly moving certain authentication systems to Crowd. One issue that we've come upon is the user password reset feature.

While this is very useful, our security policy requires administrator approval of password resets.

Ideally, we'd like to forward password reset mail to the administrator to relay to the end-user. I can certainly think of ways to hack around this once a request hits the Crowd host's mail server, but I'm wondering whether there's another somewhat more "regular" approach.

If we can't do this, then we would like to figure out a way to just remove the functionality from the UI if possible. It would be nice to keep the "reset" function that's implemented in the administrator UI (generating a random URL) - that might be helpful. But if someone's email account gets hacked, we need to limit exposure there (not to mention that we are looking at having user email also managed by Crowd...)

I'm finding Crowd both very interesting and useful at the same time I'm having to come to terms with what we really want in a system for managing users... thanks for any ideas!


Answers:
author: AnnWorley
body: Users don't have access to the Crowd console by default so if you don't set them up for self service they won't be able to change their passwords in Crowd. Administrative functions will remain as they are.

Here is what not to do [Granting Crowd User Rights to a User](https://confluence.atlassian.com/crowd/granting-crowd-user-rights-to-a-user-152045076.html)

Please let us know any follow-up questions.

comments: author: KMP
body: Hi, Ann, thanks for the response.

I think what I'm trying to do - or perhaps not approaching this correctly - is to use the functionality that Crowd has to generate an authentication URL for a user to employ to reset their password - but to not do so automatically.

In other words, now a user can go to the Crowd sign in page and get a password reset URL sent to them. The risk is that a compromised email account leads to all authentication managed by Crowd being compromised.

On the other hand, denying crowd user rights would seem to preclude an administrator's ability to allow a user to reset their password (unless - please let me know if I'm wrong about this - an admin can still use the "Reset Password" link to generate an email to a user, and the user can use that link to reset their password).

Again, it's all good if there is some sort of step between a user clicking on the "forgot password" link and getting an email with a reset URL. (I suspect that I could engineer routing in the mail server to intercept these emails and forward to an administrator... but that strikes me as suboptimal.)

By the way, I'd also assume that unless two-way authentication is set up between Crowd and (at least one) Crowd-managed applications there's no other way to enforce a password expiration requirement?


author: AnnWorley
body: One approach would be to change the reset password email template so it doesn't include the reset link, but redirects the customer to contact an admin: [Creating an Email Notification Template](https://confluence.atlassian.com/crowd/creating-an-email-notification-template-17956966.html) In that case a reset password email generated by the admin would also omit the link, however. I am sure you don't want the admins to explicitly set the passwords for the users, so we need to get the users that reset link one way or another.

Perhaps you could set up the email server to copy admins on emails sent from Crowd, so the user has the reset password link, but the admin is aware of it?

Or deny users access to the Crowd application URL via proxy or other method and have them contact an admin, who could go in and generate the email with the reset link by clicking the reset password button while viewing the user.

If an Atlassian application is using a Crowd user directory for user management and the "Days until password expiry" (on the Configuration tab under the Directory in Crowd 3.1.2) is set, that setting will be enforced for the applications. [Users Can't Login Due to Expired Passwords](https://confluence.atlassian.com/crowdkb/users-can-t-login-due-to-expired-passwords-218268801.html)


author: AVOKEO
body: Thanks... that gives me a few ideas to investigate! We'll go from there.