Error while enabling 2FA

Summary

Not able to enable 2FA due to error "You must provide a valid current password."

Steps to reproduce

1. Log in to GitLab
2. Go to Account -> Enable 2FA
3. Register new authentication device using QR code. I am using Microsoft authenticator app.
4. Enter current password and token.

What is the current bug behavior?

The error "You must provide a valid current password." is thrown while enabling 2FA even though valid current password is used. The password used is valid as I am using the same for log-in.

What is the expected correct behavior?

Should be possible to enable 2FA with current password and token.

Relevant logs and/or screenshots

Priority

• Urgent
• High
• Medium
• Low

Severity

• Blocker
• Major
• Normal
• Low

Impact

(What is the impact of this issue? Is it blocking a release? Are there any time constraints?, for example: "We have a release tomorrow")

It seems that there are some quirks with gitlab that we are investigating.

The requested password is not your Eclipse Foundation account password. To fix it while we are investigating, please go to https://gitlab.eclipse.org/-/profile/password/edit and ask for a password reset (this will be only for the gitlab "local" identity, not your EF account). Once your "local password" is changed, you should be able to use it in the field where it's being requested.

This "local identity" password does not need to be remembered beyond this step as it's not used anywhere else.

I think the root cause of this is that we create the users through the API for most users via project participation, meaning a password is required to create the account:

Either password, reset_password, or force_random_password must be specified. If reset_password and force_random_password are both false, then password is required.

When we create accounts we force a random password to make sure that the account is safe. As most of the mechanisms with the site don't use a password, this hasn't been a problem until now. There are ways we might be able to get the password, though I'd have to check if they are possible, thought I doubt it. It also wouldn't be kept up to date after creation so we didn't invest time into it.

There are ways we might be able to get the password, though I'd have to check if they are possible, though I doubt it

Password hashes are securely stored in LDAP, making it computationally impossible to reverse-engineer them back into their original plain-text form. This means that it's impossible for Martin to retrieve a user password when creating a user with our committer sync script for GL.

To address this issue, I would suggest conducting a comprehensive review of how we can integrate our LDAP server with GitLab: https://docs.gitlab.com/ee/administration/auth/ldap/

@malowe, I've reviewed the API documentation you provided and am thinking that we should consider enabling reset_password when creating new users with our sync script:

reset_password Send user password reset link - true or false(default)

I believe this could streamline the process for new committer accounts that we create as they wouldn't need to trigger the password reset themself. Id want us to test the workflow ourselves to ensure this works like we expect before enabeling.

As for the LDAP integration, while it seems straightforward to set up, the documentation leaves some questions unanswered. Specifically, it's not clear whether GitLab will utilize LDAP authentication when a user tries to enable two-factor authentication. It's possible that our users may still be prompted to enter their GitLab-specific password.

We would need to investigate this further to see if my LDAP recommendation would help here.

I had a typo which I edited.

We should consider enabling reset_password not force_random_password. force_random_password is what we currently have.

We should consider enabling reset_password not force_random_password.

Easy peasy! I can create a patch for that today and have it out later next week when I do a general release of the sync script.

I would like us to test this before we deploy this to prod.

As you know, the GL docs are not always clear. It is best that we try this it out ourselves first as we might need to make some additional tweaks such as updating the password reset email from GL to better inform our users.

I am concerned that some users may be surprised to unexpectedly receive a password reset email without a good explanation..

added ~16083 team:security labels

added IT-priorityhigh IT-severitymajor statewip labels

mentioned in issue #1251 (closed)

Mika has provided a solution for the client.

I am closing this issue as a duplicate of #1251 (closed). It would be best for us to have our conversations about this on the same issue.

closed