While this workflow focuses on disabling Two-factor Authentication on a GitLab.com account, this same workflow should be used any time ownership of an account needs to be verified.
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. 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 this documentation on how to resolve 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 can provide evidence of account ownership.
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 Risk Factor Worksheet (internal only).
Note: as of Aug 2018 GitLab is no longer accepting government issued ID as proof of account ownership
As part of access recovery, if 2FA removal is not involved, then skip the following steps and move on to the next section.
Leave an internal note on the ticket with the relevant admin link, your proposed data classification level, and verification challenges.
Request that your selections be peer-reviewed by another member of the team. If you’re reviewing the selections of another team member, ensure that you leave an internal note on the ticket that you approved them.
If the user is a GitLab employee, follow the below process: