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 (Locked)
or (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.
Process:
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.
Process:
arkose_risk_band
from high
to medium
.Save
when done.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 Safety
Account Reinstatement Request template in the Trust and Safety Operations tracker. Otherwise, reaffirm the block cannot be removed.owner
of 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-TrustAndSafety
macro for the initial response to the user.Support::SaaS::Blocked Accounts::Account Reinstated- Success
macro 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.