This workflow focuses on disabling Two-factor Authentication on a GitLab.com account.
It should also be used any time ownership of an account needs to be verified, such as for account changes.
2FA removal and other account actions can only be completed if the workflow below is successful.
In most cases, users can disable 2FA themselves and regain access to their accounts, using one of the following methods:
Permission denied (publickey)error, they may need to manually register their private SSH key using
ssh-agentif they're using a non-default SSH key pair file path. Direct the user to our documentation for guidance on how to solve this.
As of August 2020, free users won't be able restore access to accounts if self-service methods do not work for them.
If a user cannot make use of self-serve methods (lost their account recovery codes and has no SSH key registered), proving they own the account can be difficult. Support intervention for 2FA removal after the above steps have been attempted is only possible for users with an existing paid plan when the ticket was created.
If a paid user (part of paid group or paid user namespace) 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.
While Support typically identifies users by their membership in a paid namespace, there are cases where users cannot be added manually by group owners, such as with SSO enforcement enabled. In these cases:
As part of access recovery, if 2FA removal is not involved, then skip the following steps and move on to the next section.
Note: In case the user sends back very minimal information and it's clear it's not sufficient or the answers are vague, reply asking for more information immediately after their response. You can provide some additional guidance, such as "please provide the exact date and time of the commit, not just an approximate one".
Support::SaaS::2FA::2FA Internal Notemacro to put an internal note on the ticket with the table at the bottom of the sheet.
#support_gitlab-comif the account verification passed. If the verification failed, a peer review is optional, and you may opt to offer more challenges to the user.
This section will usually be done by the peer reviewer.
Edit, add an Admin Note, and save.
Support::SaaS::2FA::2FA Removal Verification - Successfulmacro.
Note: Do not provide hints to answers. That is how social engineering works!
Owner in the top level namespacevouch is requested. Use the
Support::SaaS::2FA::2FA ask owner vouchmacro. The originating email of this request should match a verified email of the Owner's account.
Support::SaaS::2FA::2FA Removal Verification - GitLab.com - Failedmacro.
If the user is a GitLab employee, have them contact IT Ops.
For customers who are large enough to have an account management project, an issue within their specific project can be used as verification.
The (Technical) Account Manager ((T)AM) is responsible for the setup. If a customer requests this workflow, please refer them to their (T)AM.
Create an issue template called
2FA Verification.md that contains the following:
- User to reset (required): `@user` - ZD Ticket: `#ticket number` /label ~"2FA Reset"
2FA Reset Owners.mdthat lists the customer's external Slack channel in the GitLab workspace, and the Slack handle of individuals who are authorized to request a 2FA reset.
Notes, such as
2FA owner vouch: [link to 2FA Reset Owners file].
If the ZenDesk organization's notes has a "2FA owner vouch" link, use the following process to ask for an owner vouch:
Use Slack and ping the individuals listed in the
2FA Reset Owners.md file in the listed Slack channel, 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 disable 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.
If the "2FA Reset Owners" file does not list a Slack channel and an issue hasn't already been submitted to Support, then ask the user for an owner vouch using
Support::SaaS::2FA::2FA ask large owner vouch.
If an issue has been submitted, then comment in the account management issue that you've included the owner vouch in the verification process, and close the issue.
There are some conditions under which a change of ownership may be requested by a company with a business relationship with GitLab. Our support page outlines that these processes are not available for unpaid groups.
The end result of a successful request is a new or existing user in the namespace will have the Owner role.
Account Ownership Change Requests are initiated when the sole Owner of a group leaves a company and an authorized representative of the company is seeking to regain access. This process should be a last resort, and self-service options should be pursued first.
If a request is received, verify:
Ensure that the requestor has exhausted all self-service options:
If no Self-service options are viable, follow the steps below:
Support::SaaS::Account ownership change verification (Self-service option not possible)macro
Legal::Generalmacro and set the ticket to "On-Hold". If you don't receive a reply after the On-Hold ticket reverts to open (4 days), ping in