debian-mirror-gitlab/doc/user/admin_area/settings/sign_up_restrictions.md

stage	group	info	type
none	unassigned	To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments	reference

Sign-up restrictions (CORE ONLY)

You can enforce the following restrictions on sign ups:

• Disable new sign ups.
• Require administrator approval for new sign ups.
• Require user email confirmation.
• Allow or deny sign ups using specific email domains.

Disable new sign ups

By default, any user visiting your GitLab domain can sign up for an account. For customers running public-facing GitLab instances, we highly recommend that you consider disabling new sign ups if you do not expect public users to sign up for an account.

To disable sign ups:

1. Go to Admin Area > Settings > General and expand Sign-up restrictions.
2. Clear the Sign-up enabled checkbox, then select Save changes.

Require administrator approval for new sign ups

• Introduced in GitLab 13.5.
• Enabled by default in GitLab 13.6.

When this setting is enabled, any user visiting your GitLab domain and signing up for a new account must be explicitly approved by an administrator before they can start using their account. This setting is enabled by default for newly created instances. This setting is only applicable if sign ups are enabled.

To require administrator approval for new sign ups:

1. Go to Admin Area > Settings > General and expand Sign-up restrictions.
2. Select the Require admin approval for new sign-ups checkbox, then select Save changes.

In GitLab 13.7 and later, if an administrator disables this setting, the users in pending approval state are automatically approved in a background job.

Require email confirmation

You can send confirmation emails during sign up and require that users confirm their email address before they are allowed to sign in.

To enforce confirmation of the email address used for new sign ups:

1. Go to Admin Area > Settings > General and expand Sign-up restrictions.
2. Select the Enable email restrictions for sign ups checkbox, then select Save changes.

User cap (CORE ONLY)

• Introduced in GitLab 13.7.
• It's deployed behind a feature flag, enabled by default.
• It's recommended for production use.
• For GitLab self-managed instances, GitLab administrators can opt to disable it. (CORE ONLY)

When the number of billable users reaches the user cap, any user who is added or requests access must be approved by an administrator before they can start using their account.

If an administrator increases or removes the user cap, the users in pending approval state are automatically approved in a background job.

Enable or disable User cap (CORE ONLY)

User cap is under development but ready for production use. It is deployed behind a feature flag that is enabled by default. GitLab administrators with access to the GitLab Rails console can opt to disable it.

To disable it:

Feature.disable(:admin_new_user_signups_cap)

To enable it:

Feature.enable(:admin_new_user_signups_cap)

Soft email confirmation

• Introduced in GitLab 12.2.
• It's deployed behind a feature flag, disabled by default.
• It's enabled on GitLab.com.
• It's recommended for production use.
• To use it in GitLab self-managed instances, ask a GitLab administrator to enable it.

WARNING: This feature might not be available to you. Check the version history note above for details.

The soft email confirmation improves the signup experience for new users by allowing them to sign in without an immediate confirmation when an email confirmation is required. GitLab shows the user a reminder to confirm their email address, and the user can't create or update pipelines until their email address is confirmed.

Minimum password length limit

Introduced in GitLab 12.6

You can change the minimum number of characters a user must have in their password using the GitLab UI.

Allow or deny sign ups using specific email domains

You can specify an inclusive or exclusive list of email domains which can be used for user sign up.

These restrictions are only applied during sign up from an external user. An administrator can add a user through the admin panel with a disallowed domain. Also, note that the users can change their email addresses to disallowed domains after sign up.

Allowlist email domains

Introduced in GitLab 7.11.0

You can restrict users only to sign up using email addresses matching the given domains list.

Denylist email domains

Introduced in GitLab 8.10.

You can block users from signing up when using an email addresses of specific domains. This can reduce the risk of malicious users creating spam accounts with disposable email addresses.

Create email domain allowlist or denylist

To create an email domain allowlist or denylist:

1. Go to Admin Area > Settings > General and expand Sign-up restrictions.

2. For the allowlist, you must enter the list manually. For the denylist, you can enter the list manually or upload a .txt file that contains list entries.

   Both the allowlist and denylist accept wildcards. For example, you can use *.company.com to accept every company.com subdomain, or *.io to block all domains ending in .io. Domains must be separated by a whitespace, semicolon, comma, or a new line.

   

Enable or disable soft email confirmation

Soft email confirmation is under development but ready for production use. It is deployed behind a feature flag that is disabled by default. GitLab administrators with access to the GitLab Rails console can opt to disable it.

To enable it:

Feature.enable(:soft_email_confirmation)

To disable it:

Feature.disable(:soft_email_confirmation)