Server: Easy registration of new accounts

[kaffeeringe]

I keep having problems with new users:

1. I add their account.
2. They receive their activation link
3. They don't have time to click on it in that instance
4. The mail moves down in their inbox
5. When they first have to use their account they remember the mail, click on the link and the token is invalid.

What works:

1. I add their account with a password
2. I send them username and password

Problem is: I can't force them to change the password after the first login, can I? That would be a good feature:

1. Add new account with autogenerated one-time-Password
2. Nextcloud sends it directly to the new user

[wiswedel]

Nextcloud sends it directly to the new user

@kaffeeringe
Wouldn't that email drown in the recipient's inbox just like with the current behavior?

What you already can do is manually trigger resending the invitation email for the users that have never logged in. You can find that out on the users page.

Or someone could automate that... 😉

[Dzeri96]

I guess this could be solved by introducing a long-lasting token that the admin could select when sending out invites.

Could this clash with best-practice security standards or is it safe to implement?

[compagnon]

see #16245
We have the same questions /problems with new users.
Do not want to let NC admin / server sending the very first email to new users
Do not want to have expired tokens in email and have a bad first experience
Be able to build easily an URL to go directly to the Lost page for new or reset password
Do not want to send email , even temporarily to email boxes
Do not want to let NC admin choosing a temp password with no sense to the new user

So the idea is to enhance with https://example.com/newpassword/[email protected]
Or https://example.com/newpassword/userI’d
And propose the user to begin a password reset process with email containing a classic tokenised url

[compagnon]

The very first email is managed and sent by sales in charge of the new users
This email is generated to include the https://example.com/newpassword/[email protected]

[fifkis]

Can i work on this issue ?

[Dzeri96]

I would also like some feedback on this issue. Either we extend the token validity, or make the server send a new email when the user opens an expired link, like @compagnon said.
Maybe have both variable validity and repeatable emails?

[ein-giga-self]

Hi all,

myself and @franziba would like to implement the initial password reset function described by @kaffeeringe. Should we open a new Issue specific to this, or should this be the issue we reference ?

Best wishes
@JonasBlaesche and @franziba

[paulvandenburg]

@JonasBlaesche I think referencing this issue would be fine. So far no one has provided a possible implementation to solve this issue, so if you'd like to provide one that would be great!

[kesselb]

Thanks @JonasBlaesche and @franziba :+1:

@jancborchardt could you add some input? Actual there are two options:

1) Send out the email with the set password link (and the token which expires after some time)
2) Admin sets a initial password and there is just a email with the username

If we're adding a third way "Create user and send him a one-time-password" how to trigger this? I think it's already confusing that we send out a email without or with password.

[kesselb]

@wiswedel is there a way to force a password change? If not I'm unsure about "good first issue".

[compagnon]

I have implemented and hosted the feature described in #16245

thanks to "./occ user:add " , the accounts are provisionned , and any time , a special email is sent to new user asking them to connect to https://example.com/newpassword/[email protected]
Or https://example.com/newpassword/userId

This is a new page (based on LostPassword), that makes the user to send to him an automatic email with an tokenized URL inside.

[ein-giga-self]

Hello there,
After the discussion here we were a bit confused about what to do exactly. Please help us with commenting our following suggestion.
As methods to create new users we identified following three options. The bold part of the use cases would be the newly created improvements from us.

• Add user with name and password: The user will not receive an E-Mail. The new user can login with the name and password. After the first login the user is forced to change the password by using the lostpassword/reset page. How the user is informed about username and password is up to the admin.

• Add user with name and E-Mail: In this case the user receives an E-Mail with a link to the lostpassword/reset page. This page lets the user set a new password. No change needed.

• Add user with name, password and E-Mail: In this case the user receives an E-Mail with a link to the normal login page. The user has to login using the username and password the admin chose. After the first login the user is forced to change the password by using the lostpassword/reset page. How the user is informed about the password is up to the admin. The E-Mail does not contain the password.

We don't see any need for machine-generated passwords so far.
Is this, or which parts would be a suitable solution for this issue?

Best regards
@JonasBlaesche and @franziba

[kesselb]

cc @nextcloud/designers

[franziba]

Hello,

we would start implementing our suggestion from above right now, as no one said anything against it. Still we would be happy about any annotations.

Best regards,
@JonasBlaesche and @franziba

[paulvandenburg]

I think the suggested change sounds great. It would certainly have my support.
The only note I'd place is that I don't mind how the forcing of setting a password is done. Whether the user is required to go through the lost password process or something else is not important for me. As long as new users (that I want to go through this new registration process) are forced to set their first own password.

[jancborchardt]

@jancborchardt could you add some input? Actual there are two options:

1. Send out the email with the set password link (and the token which expires after some time)

2. Admin sets a initial password and there is just a email with the username

@kesselb Option 1 absolutely. :) Admins shouldn’t mess around with passwords.

Any other open design questions at the moment? @JonasBlaesche @franziba?

[jancborchardt]

@JonasBlaesche @franziba only one thing about your proposal: I don’t see the need at all for the admin to set a password. They should not need to handle that.

We should always require username and email (so you can reset your password). Or are there any other requirements or special cases @rullzer?

[ein-giga-self]

@jancborchardt

I don’t see the need at all for the admin to set a password. They should not need to handle that.

Admins currently have the option to add users with a admin chosen password. This would not be anything new added by us. Our change would just ensure that a admin set password is changed by the user on his/her first login. This would ensure that the admin has no access to the user account after the first user login.

Or are there any other requirements or special cases

I personally know some installations that have not setup the E-Mail sending capabilities of Nextcloud, so they add users by username:password. This would no longer be possible if the only way to add a user would be by username and E-Mail.

Do you have any other comments on the reset proposal?

Best regards
@JonasBlaesche and @franziba

[rullzer]

@JonasBlaesche @franziba only one thing about your proposal: I don’t see the need at all for the admin to set a password. They should not need to handle that.

We should always require username and email (so you can reset your password). Or are there any other requirements or special cases @rullzer?

We don't require an e-mail currently.
Also, this falls back to the e-mail issue. RIght now we do not enforce unique e-mail addresses (or for a user to validate theirs).

[ein-giga-self]

Hi there,

we now have a working version of our idea. We will shortly describe what we did:

1. Changed the UserController in the provisioning app to set a flag in the oc_preferences table to indicate that this user has an initial password and needs to be redirected on the first login to change the password.

2. Changed the LoginController to check if the user currently trying to login, has the initial flag set. This check only happens after the LoginChain has returned successfully. If the user has the initial flag set, we redirect him/her to the password reset page.

3. Changed the LostController to remove the initial flag after the user has reseted his/her password.

The LostController usually expects a password-rest token, that is generated when a user requests a password reset. This token is generated by the NewUserMailHelper when the user requests a new password. Part of the information used to generate a token is the users E-Mail address. We neither have access to the NewUserMailHelper nor a user with an E-Mail address. Therefore passing a normal password-rest token is not possible. We currently worked around this problem by passing the users login token and added a new check in the LostController (if the user has the inital flag set and the passed token is equal to the login token, a password reset is allowed). After the password is reseted the login token is deleted, resulting in a new login token on the next login. Is this a save way to do it? If not does anybody have an idea on how to solve that problem?

Best regards
@JonasBlaesche and @franziba