[Regression] Admin cannot set password for user

[Gummikavalier]

Description:

It seems that admins lost ability in Rocket.Chat 2.3.0 to set a password for new users or reset the password for any old user.

Issue may be related to removal of E2E-password reset functionality from admins in #15777

Steps to reproduce:

1. Go to Admin-console -> Users
2. Create a new user and try to set password for it, or try to reset password of any old user.
3. There is no password field or password reset option anywhere

Expected behavior:

Admins should be able to create accounts with known password to them (to give it out to new user), or reset passwords for old users.

Actual behavior:

There is no user password field or reset option to be found.

Server Setup Information:

• Version of Rocket.Chat Server: 2.3.0
• Operating System: CentOS 7
• Deployment Method: tar
• Number of Running Instances: 20
• DB Replicaset Oplog: enabled
• NodeJS Version: 8.15.1
• MongoDB Version: 3.6

Client Setup Information

• Desktop App or Browser Version: Firefox 70.0.1 and Chromium 78
• Operating System: Fedora 31

[JASG94]

Same problem here running on Docker containers with Kubernetes

[cygnusm]

Same problem!

[makibras]

Hi!

this change was intended to limit the admin having access to passwords so that passwords are secrets only known to the user himself.

To change/reset the password of an old user, you can go in the user administration for that user and toggle both "set random password" and "require password change", click "save". The user will receive an email with a temporary password and can then set his new password. This works as well for new users.

Sending passwords by mail will also be soon replaced by a new feature called "invite links".

I hope this solution helps you and you understand our motivation behind this change.

[wemu]

I think for human users this works ok. But when creating/editing a bot user this isn't so practical. It also conflicts with the instructions on this: https://rocket.chat/docs/bots/create-and-run-a-bot/

[Gummikavalier]

@makibras Thanks for opening up this a bit. I now understand the logic, but like @wemu mentioned, it does make creating bots and accounts for troubleshooting purposes bit too complex. Exactly the case where I stumbled upon it.

Our company process for creating routed (working) email accounts is time consuming process to begin with. So now to create a temporary test account I need to assign my own home email account to it (my company one already being reserved for the existing user in rocket.chat).

[makibras]

Technically, a bot user is the same as any other user and needs an email address, therefore can use the same process. This might change in the future. For now, I will close this.

[wemu]

@makibras I'm sorry but I have to disagree on this. The a bot user is more of a technical user that does not follow the same password policies as human users. In our case we authenticate users using the oauth features of rocket.chat - I could create the bot user in the forum (our main user source) but the password does not propagate. And after all the user is only required to exist in chat. And its settings/passwords are stored in configs for the bot software. This is nothing like any other user.

[makibras]

I read again my answer and it was a bit ambiguous. What I meant to say was that right now, the bot is treated technically like any other user in Rocket.Chat. It is simply a role you can add or remove. As a result, the bot user needs an email and follows the same password workflows.
In the future, we plan to differentiate out the bot user to fit in more of the technical user role, which will probably result in a different way to manage passwords for it, as a bot generally does not have privacy needs.
@wemu: are you blocked right now in setting the passwords for your bots?

[wemu]

Ah I see. Well, yes: in the role point of view I can follow now.

Blocked only sort of. I have an existing bot user, I tried adding another one to test the other bot variations possible with rocket.chat - but I can't create a bot user anymore. But there is no urgent need to do so for me, I can wait - not sure about others though.

[JASG94]

I'm dealing with the same problem @wemu told.

I understand the new password policy implemented for "normal" users, but, imho it would be great that admins can manage bot passwords, because with this new way of administrate them it's a little bit tricky to create temporaly bots for testing purposses.

[reetp]

@makibras

this change was intended to limit the admin having access to passwords so that passwords are secrets only known to the user himself.

I'm afraid I don't agree with this policy. You are dumbing down the admin role.

I have a system that uses a dummy domain and the users are unable to use email links.

I set them up with an account and they login JUST with their username and password - no email addresses are used.

And if I am admin and it is my system why CAN'T I reset a users password? It is MY system.

You are basically say I have no control over parts of my own system. I don't have this problem with any other server I run.

I suggest this should be re-opened and the policy rethought.

[makibras]

@reetp Thank you for your comment. The user password is not part of something the admin should ever know about and common practice. That kind of knowledge does not belong to an admin. The password is a secret only known by the user. The admin still has the power to trigger the reset so in your system you are still capable to do that if you would use regular emails. As you are using dummy emails, this is quite uncommon so we could try to figure out a workaround for you. But in general, you need a place outside the system where the user can receive his credentials. What would the options for you? We are working on a way to differentiate the reset out for technical user roles like bots.

…

On Wed, Dec 11, 2019, 05:09 John Crisp ***@***.***> wrote: @makibras <https://github.com/makibras> this change was intended to limit the admin having access to passwords so that passwords are secrets only known to the user himself. I'm afraid I don't agree with this policy. You are dumbing down the admin role. I have a system that uses a dummy domain and the users are unable to use email links. I set them up with an account and they login JUST with their username and password - no email addresses are used. And if I am admin and it is my system why CAN'T I reset a users password? It is MY system. You are basically say I have no control over parts of my own system. I don't have this problem with any other server I run. I suggest this should be re-opened and the policy rethought. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#15880?email_source=notifications&email_token=ALSYGMS3JNXQDOGVXOXKQCTQYDC7XA5CNFSM4JS3MLE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGSXU2Q#issuecomment-564492906>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALSYGMQTWCW4ZBLMPYQLRVDQYDC7XANCNFSM4JS3MLEQ> .