GitLab Professional Services
Accelerate your software lifecycle with help from GitLab experts
Popular GitLab use cases
Enterprise Small Business Continuous Integration (CI/CD) Source Code Management (SCM) Out-of-the-box Pipelines (Auto DevOps) Security (DevSecOps) Agile Development Value Stream Management GitOpsGitLab Professional Services
Accelerate your software lifecycle with help from GitLab experts
Popular GitLab use cases
Enterprise Small Business Continuous Integration (CI/CD) Source Code Management (SCM) Out-of-the-box Pipelines (Auto DevOps) Security (DevSecOps) Agile Development Value Stream Management GitOpsThis 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.
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.
ssh git@gitlab.com 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.
Free users won't be able restore access to accounts if the recovery codes were lost and no ssh keys are available to generate more.
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.
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.
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".
Using the Risk Factor Worksheet (internal only), determine the appropriate data classification level and the risk factor you have determined from customer's answers to the challenges.
Use the macro "Support::SaaS::2FA::2FA Internal Note" to put an internal note on the ticket. Edit with the relevant admin link and copy the bottom table from the Risk Factor Worksheet into the note.
Request that your decision be peer-reviewed by another member of the team via Slack.
For the peer reviewer: In case you disagree, leave an internal note on the ticket stating your thoughts on what the risk factor should be and reply to the Slack conversation for further discussion. If you agree, move to the next section on what to do if successful.
https://gitlab.com/admin/users/usernamegoeshere
Edit
, add an Admin Note, and save.Disable 2FA
.Note: Do not provide hints to answers. That is how social engineering works!
Owner in the top level namespace
vouch is requested. The originating email of this request should match a verified email of the Owner's account.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.
Create an issue template called 2FA Verification.md
that contains the following:
User to reset: `@user`
ZD Ticket: `ZD ticket number`
/label ~"2FA Reset"
2FA Reset Owners.md
that lists individuals who are authorized to request a 2FA reset.Notes
, such as 2FA owner vouch: [link]
.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 Owner
gets back to you, include that in your risk factor assessment.In the event that a customer requests a report of their group's users from GLGL, consult the internal-requests wiki for the process of authenticating the requestor.
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 will be a new or existing user in the namespace will have Owner permissions.
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, send a message with the following blurb:
In order to transfer ownership, please provide a letter in PDF format outlining that the existing owner has left and ownership needs to be provided to a current employee. In the letter, please ensure that it is on company letterhead and includes:
- the name, email address, and GitLab username of the departed employee
- the name, email address (tied to the GitLab account), and GitLab username of employee who should be added
- that the current employee should be added to the group as an `Owner`
- the group name and full path (URL)
- name, position, and signature by authorized signatory
In addition, please include a copy of your last invoice from GitLab.
Whenever possible, include the current account owner from GitLab in the conversation.
Once received, double check all the requested information is included. If not, let them know what's missing.
If all required elements are present, then create a new issue in the Legal tracker requesting approval to add or upgrade the permissions of the requesting user. Note the issue in an internal comment on the ticket, then reply to the requestor using Legal::General
macro 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 #legal
.
After receiving approval: add or elevate the requested user to Owner role.