2FA removal and other account actions can only be taken if the workflow below is successful.
In many cases, users can regain access to their account using the following methods:
Users can try and login using their saved two-factor recovery codes.
If a user didn't save their recovery codes, new ones can be generated with the command below via SSH if they've previously added an SSH key to their account. The new recovery codes can then be used at sign in. This option is presented to users in the Zendesk macro and the auto-response they'll receive if they chose
Two-Factor Authentication (Account Recovery) as the problem type for the Zendesk ticket. If they cannot use this method then move on to the manual methods below.
ssh firstname.lastname@example.org 2fa_recovery_codes
If a user has added an SSH key to their account but receives a
Permission denied (publickey) error when using the command above, they may need to manually register their private SSH key using
ssh-agent if they're using a non-default SSH key pair file path. Direct the user to our documentation for guidance on how to solve this.
If the user is unable to remove 2FA or otherwise regain access to their account using the above methods and responds with the need for further verification, then the user will need to provide evidence of account ownership before we can disable 2FA on their account.
If a user has lost their account recovery codes and has no SSH key registered, proving they own the account can be difficult. In these cases, please use the workflow below.
As part of access recovery, if 2FA removal is not involved, then skip the following steps and move on to the next section.
Use the macro "Account::2FA::2FA Internal Note" It leaves an internal note on the ticket. Edit with the relevant admin link, your proposed data classification level, challenges and the risk factor.
Request that your decision be peer-reviewed by another member of the team via Slack.
Edit, add an Admin Note, and save.
Note: This only applies if you think the challenges were passed, in case the user sends back very minimal information and it's clear it's not sufficient, reply asking for more information immediately after their response.
If the user is a GitLab employee, follow the below process:
For customers who are large enough to have an account management project, an issue within their specific project can be used as verification.
Create an issue template called
2FA Verification.md that contains the following:
User to reset: `@user` ZD Ticket: `ZD ticket number` /label ~"2FA Reset"
Create a list of Slack handles in a file called
2FA Reset Owners.md that lists individuals who are authorized to request a 2FA reset.
When a user for a large customer writes in, use a shared communication medium (e.g. a shared Slack channel) to ping the folks listed in the
2FA Reset Owners.md file, alerting them that a request exists, and that they can expedite the processing of the request. You can use the following as a template for this message:
Hi @user - we got a request from `REQUESTOR_EMAIL` to reset 2FA on their account. Could you vouch for them by creating an issue via https://gitlab.com/path/to/account/project/issues/new?issuable_template=2FA%20Verification and filling in all of the details there? Once you've done that, link the issue here and I'll get them reset. If you don't get to this, we'll use our standard account verification procedures to determine if they're eligible for a 2FA reset.
2FA Reset Ownergets back to you, include that in your risk factor assessment.