This workflow covers how a user can provide account verification. While the workflow focuses on disabling Two-factor Authentication on a GitLab.com account, it should be used for any account changes.
2FA removal and other account actions can only be completed if the workflow below is successful.
If the user is a GitLab team member, have them contact IT Ops.
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-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.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.
For security purposes, support will not process 2FA resets for users who are added to a paid subscription for the express purpose of having 2FA disabled on their account.
The workflow applies to all cases where account verification is required.
Because an ownership-verification ticket is a matter of record, the ticket must be simple, accurate, and tightly focused on the access issue.
Before you send the challenges, make sure the user is eligible to receive support for 2FA removal.
A SaaS user must meet one of the following conditions to be eligible for a 2FA reset.
More succinctly: they're paid, they use the account to pay, or we use the account to communicate with them.
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:
Customers Portal requires all customers to access through a Linked Gitlab Account.
2FA can be reset when one of following conditions are met:
If one of the above conditions is met the user is eligible for our 2FA reset process.
If an invoice can not be provided, suggest sign in with legacy email/password, where an invoice can be downloaded.
If you need a basis for a response where you send the challenges, or in a 2FA ticket, if the user has not answered the challenges, use the Support::SaaS::2FA::2FA Challenges
macro.
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".
https://gitlab.com/admin/users/USERNAME
.Support::SaaS::2FA::2FA Internal Note
macro to put an internal note on the ticket.
#support_gitlab-com
.In a paid namespace: If the user elects to have an Owner vouch for their request, apply the macro Support::SaaS::2FA::2FA ask owner vouch
. This will direct the requestor to have an Owner (top-level) create a Snippet with a Support-provided string. Once they have replied verifying they have done so:
https://gitlab.com/-/snippets/2057341
)
Note: Due to this bug some group owners are not able to create snippets. In that case use a backup method instead.
If a group owner is unable to create a snippet, you may use another method to verify their identity. It must be an action that has been specifically instructed by Support and identifiably unique to the situation. Some examples include having the owner:
This section is typically done by the peer reviewer. If needed, the peer reviewer (or approving manager) may leave an approval note, in which case the original reviewer will perform the actions.
https://gitlab.com/admin/users/usernamegoeshere
Edit
, add an Admin Note, and save.Disable 2FA
.Support::SaaS::2FA::2FA Removal Verification - Successful
macro.Note: Do not provide hints to answers, or let the user know which challenges they got right or wrong. That is how social engineering works!
Owner in the top level namespace
(with a valid subscription) vouch is requested. Use the Support::SaaS::2FA::2FA ask owner vouch
macro. See the Verifying an Owner Vouch section for more information. The originating email of this request should match a verified email of the Owner's account. If the user is an Owner, vouch must be from a different Owner.Support::SaaS::2FA::2FA Removal Verification - GitLab.com - Failed - Ask colleagues for help
macro to let them know which challenges they can try to work with their colleagues to answer.Support::SaaS::2FA::2FA Removal Verification - GitLab.com - Failed - Final Response
macro.2FA removal and other account actions can only be completed if the workflow above is successful.
For customers who are large enough to have an account management project, a different workflow can be configured for them that will allow Support to more easily disable 2FA for any of their users that require it. Before this process can be used, a GitLab team member from either Customer Success or Sales must perform a few setup steps (described below). If a customer requests this workflow, please refer them to either of those individuals.
The steps to follow depend on whether or not the customer has a shared Slack channel with us. Either the customer's Customer Success Manager (CS) or Account Manager (Sales) is responsible for performing this setup. Please proceed to Shared Slack Channel if they do or No Shared Slack Channel if they don't.
2FA Verification.md
inside of the .gitlab/issue_templates
directory of the customer's Account Management project. If that directory does not exist, create it as well.2FA Verification.md
file with the template below, taking care to replace the following variables from it with your specific customer's information:
CUSTOMER_SLACK_CHANNEL
- The name of the shared Slack channel that the customer's organization has with us.SLACK_USERNAME
- The Slack handle of a user that is authorized to allow GitLab Support to disable 2FA for the customer's user accounts.GITLAB_USERNAME
- The GitLab username of a user that is authorized to allow GitLab Support to disable 2FA for the customer's user accounts.
A user in your organization is requesting to have [GitLab two-factor authentication](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html) removed from their account. Please review and complete the highlighted sections below.
## Support Engineer Instructions
- [ ] Ping the customer's organization owners in CUSTOMER_SLACK_CHANNEL using the [Notify Customer - Slack](https://about.gitlab.com/handbook/support/workflows/account_verification.html#2-contact-through-slack) template. For this organization the owners are SLACK_USERNAME, SLACK_USERNAME, and SLACK_USERNAME.
- [ ] Fill out the `Request Details` section below.
## {+Request Details+}
- {+User Requesting Reset: USERS_GITLAB_USERNAME+}
- {+Support Ticket: TICKET_NUMBER+}
## {+Customer Instructions+}
- [ ] {+Review the request and get in contact with the user requesting the reset to verify its authenticity.+}
- [ ] {+Comment on this issue indicating your approval.+}
- [ ] {+Unassign yourself and any others from this issue.+}
- [ ] {+Assign to the Support Engineer who opened this issue.+}
/assign GITLAB_USERNAME GITLAB_USERNAME GITLAB_USERNAME
/label ~"2FA Reset" ~"Awaiting confirmation"
2FA Verification.md
file you created in the previous step, such as 2FA owner vouch: /path/to/2FA Verification.md/
in the notes.skip_2fa_automation
tag so that users requesting this won't get the autoresponder.2FA Verification.md
inside of the .gitlab/issue_templates
directory of the customer's Account Management project. If that directory does not exist, create it as well.2FA Verification.md
file with the template below, taking care to replace the following variables from it with your specific customer's information:
GITLAB_USERNAME
- The GitLab username of a user that is authorized to allow GitLab Support to disable 2FA for the customer's user accounts.
A user in your organization is requesting to have [GitLab two-factor authentication](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html) removed from their account. Please review and complete the highlighted sections below.
## Support Engineer Instructions
- [ ] Fill out the `Request Details` section below.
## {+Request Details+}
- {+User Requesting Reset: USERS_GITLAB_USERNAME+}
- {+Support Ticket: TICKET_NUMBER+}
## {+Customer Instructions+}
- [ ] {+Review the request and get in contact with the user requesting the reset to verify its authenticity.+}
- [ ] {+Comment on this issue indicating your approval.+}
- [ ] {+Unassign yourself and any others from this issue.+}
- [ ] {+Assign to the Support Engineer who opened this issue.+}
/assign GITLAB_USERNAME GITLAB_USERNAME GITLAB_USERNAME
/label ~"2FA Reset" ~"Awaiting confirmation"
2FA Verification.md
file you created in the previous step, such as 2FA owner vouch: /path/to/2FA Verification.md/
.If a 2FA ticket is opened by an organization that has had this workflow configured for them, perform the following steps to process the request depending on whether or not the customer has a shared Slack channel with us.
Note: 2FA removal for the user is approved by the Customer via the 2FA Verification template. This means the Customer will confirm with the User having 2FA removed and not support.
2FA Verification
template and follow all instructions within it. A link to this template should be in the notes for the organization in Zendesk.SLACK_USERNAME
- The Slack handle of a user that is authorized to allow GitLab Support to disable 2FA for the customer's user accounts. If there are more than one, add them as well.
Hi Could you vouch for them by following the steps in this issue: Once you've done that, please let me know. If you don't get to this within 24 hours, we'll use our standard account verification procedures to determine if they're eligible for a 2FA reset.
Note: If the customer has created an issue using the
2FA Verification
template themselves and sent us a Zendesk ticket with a link to it, skip this step.
Wait for the customer to comment on the issue and approve the request to disable 2FA.
As stressed in the Slack notification template, we will wait for the customer's answer for 24 hours. If no response is received by then, regular 2FA verification will take place via the challenges workflow.
Once the customer has approved the request, disable 2FA on the user's account, add an Admin Note on the user's account, and then close both the support ticket and issue.
Peer review is not required. You may make the change yourself.
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 outcome 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 control. This process should be a last resort, and self-service options must first be explored.
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 Request (Self-Service Not Possible)
macro, adding the account owner or account manager in CC if possible.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 the #legal
Slack channel.Admin Account
, go to the requestor's 'Namespace - Group - Members' section.Max role
column, change the requestor's role to Owner
.Invite members
button at the top right, enter the requestor's email address, and set the role to Owner
. Press the Invite
button to save your changes.If a user has a pre-listed Twitter account on their GitLab profile, this may be used as an additional factor for proving account ownership.
@GLSupport2FA
in a reply to their ticket.Hi,
We recently got a request to <remove the 2FA on | delete | change the primary email address> your GitLab.com account. Since you listed this account there, we're reaching out for confirmation. Please let us know if it was you who initiated this request.
If you don't reply in the positive in 7 days we won't be able to count this towards your proof of account ownership.
Thanks,
GitLab Support
If a reply is received within 7 days, account for it in the Risk Factor Worksheet and continue with the workflow. Otherwise, this can be counted as a failed challenge.