This workflow page will describe how to action on Locked & Blocked accounts. Sometimes users believe they are blocked, but their accounts are locked. The Admin User UI provides information regarding whether a user account is locked or blocked in
/admin/user/USERNAME. It will say
(Blocked) next to the name at the top. Currently, this functionality is not available in the API, but it has been requested in gitlab#391635.
Our implementation of Arkose Protect does not affect account locking, but instead can prevent users from signing in without solving the challenge.
When a user has been identified as locked, you can use the
Support::SaaS::Account Locked macro to help explain the situation to the user. A user can be locked if:
2FA is not enabled:
2FA is enabled:
If the user does not receive a verification email with the 6-digit code, it's likely that the primary email address is inactive or inaccessible. If a user does not have access to their primary email address, they cannot unlock their account or reset their password. Consider other workflows such as swapping email addresses if a user is not able to access their primary email.
All verification emails with unlock codes and password reset emails bypass Mailgun suppressions. Mail delivery of these emails can also be seen in Mailgun.
You can see
Account Locked states in Kibana by searching for
json.message: Account Locked. Here's an example of what it might look like it Kibana:
A user should attempt all self-serve methods first.
If self-serve methods have been exhausted and a member of a group with a paid subscription still cannot access their account, we can consider a manual unlock if necessary. For example, if a user cannot receive external email to receive codes, a manual unlock may be required. Note that only an admin user can modify a user account on SaaS.
Feature request for group owners to self-serve is in anti-abuse#339.
If a user has failed credit card verification or cannot use a credit card, follow the below process to verify the user in order to change their risk level. Please see this issue and the documentation for more details.
Note: This process can only be done for free users if it's determined that they are impacted by a GitLab bug, such as customers#3811.
This workflow is used to determine if a blocked user can be reinstated if it has been blocked by us. All blocked accounts should have an admin note with a link to a relevant issue.
/chatops run user find <username or email>
Support::SaaS::Abuse::TOS Section 10 (Embargoed Countries)macro.
Trust and SafetyAccount Reinstatement Request template in the Trust and Safety Operations tracker. Otherwise, reaffirm the block cannot be removed.
ownerof the top-level namespace the user belongs to can submit the ticket. Follow the account verification, and add an admin note as usual, including if it was user or owner requested.
Support::SaaS::Blocked Accounts::Escalated-TrustAndSafetymacro for the initial response to the user.
Support::SaaS::Blocked Accounts::Account Reinstated- Successmacro to notify the user the account has been unblocked. Otherwise, provide the reasoning from the Unblock Request as to why their account will remain blocked.
NOTE: The rest of this page is for reference only and should be updated to point to Security's workflow.