diff options
Diffstat (limited to 'doc/user/admin_area/settings/sign_up_restrictions.md')
| -rw-r--r-- | doc/user/admin_area/settings/sign_up_restrictions.md | 132 |
1 files changed, 88 insertions, 44 deletions
diff --git a/doc/user/admin_area/settings/sign_up_restrictions.md b/doc/user/admin_area/settings/sign_up_restrictions.md index f57cf7c2045..5ea034ff4d2 100644 --- a/doc/user/admin_area/settings/sign_up_restrictions.md +++ b/doc/user/admin_area/settings/sign_up_restrictions.md @@ -1,52 +1,75 @@ --- +stage: none +group: unassigned +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers type: reference --- # Sign-up restrictions **(CORE ONLY)** -You can use sign-up restrictions to: +You can enforce the following restrictions on sign ups: -- Disable new sign-ups. -- Require admin approval for new sign-ups. +- Disable new sign ups. +- Require administrator approval for new sign ups. - Require user email confirmation. -- Denylist or allowlist email addresses belonging to specific domains. +- Allow or deny sign ups using specific email domains. -NOTE: **Note:** -These restrictions are only applied during sign-up from an external user. An admin can add a user through the admin panel with a disallowed domain. Also, note that the users can change their email addresses after sign-up to -disallowed domains. +## Disable new sign ups -## Disable new signups +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. -When this setting is enabled, any user visiting your GitLab domain will be able to sign up for an account. +To disable sign ups: - +1. Go to **Admin Area > Settings > General** and expand **Sign-up restrictions**. +1. Clear the **Sign-up enabled** checkbox, then select **Save changes**. -You can restrict new users from signing up by themselves for an account in your instance by disabling this setting. +## Require administrator approval for new sign ups -### Recommendations +> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/4491) in GitLab 13.5. +> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/267568) in GitLab 13.6. -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. +When this setting is enabled, any user visiting your GitLab domain and signing up for a new account must be explicitly [approved](../approving_users.md#approving-a-user) 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. -Alternatively, you could also consider setting up a -[allowlist](#allowlist-email-domains) or [denylist](#denylist-email-domains) on -email domains to prevent malicious users from creating accounts. +To require administrator approval for new sign ups: -## Require admin approval for new sign-ups +1. Go to **Admin Area > Settings > General** and expand **Sign-up restrictions**. +1. Select the **Require admin approval for new sign-ups** checkbox, then select **Save changes**. -> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/4491) in GitLab 13.5. +## Require email confirmation -When this setting is enabled, any user visiting your GitLab domain and signing up for a new account will have to be explicitly [approved](../approving_users.md#approving-a-user) by an administrator before they can start using their account. +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: -## Require email confirmation +1. Go to **Admin Area > Settings > General** and expand **Sign-up restrictions**. +1. Select the **Enable email restrictions for sign ups** checkbox, then select **Save changes**. -You can send confirmation emails during sign-up and require that users confirm -their email address before they are allowed to sign in. +## User cap **(CORE ONLY)** + +> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/4315) in GitLab 13.6. - +When the number of users reaches the user cap, any user who is added or requests access must be +[approved](../approving_users.md#approving-a-user) by an administrator before they can start using +their account. + +## Soft email confirmation + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/47003) in GitLab 12.2. +> - It's [deployed behind a feature flag](../../..//user/feature_flags.md), 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](#enable-or-disable-soft-email-confirmation). + +CAUTION: **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 @@ -55,40 +78,61 @@ their email address before they are allowed to sign in. You can [change](../../../security/password_length_limits.md#modify-minimum-password-length-using-gitlab-ui) the minimum number of characters a user must have in their password using the GitLab UI. -## Allowlist email domains +## 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](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/598) in GitLab 7.11.0 You can restrict users only to sign up using email addresses matching the given domains list. -## Denylist email domains +### Denylist email domains > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/5259) in GitLab 8.10. -With this feature enabled, you can block email addresses of a specific domain -from creating an account on your GitLab server. This is particularly useful -to prevent malicious users from creating spam accounts with disposable email -addresses. - -## Settings +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. -To access this feature: +### Create email domain allowlist or denylist -1. Navigate to the **Admin Area > Settings > General**. -1. Expand the **Sign-up restrictions** section. +To create an email domain allowlist or denylist: -For the denylist, you can enter the list manually or upload a `.txt` file that -contains list entries. +1. Go to **Admin Area > Settings > General** and expand **Sign-up restrictions**. +1. 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. -For the allowlist, you must enter the list manually. - -Both the allowlist and denylist accept wildcards. For example, you can use + 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 should be separated by a whitespace, +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](../../../administration/feature_flags.md) +can opt to disable it. + +To enable it: + +```ruby +Feature.enable(:soft_email_confirmation) +``` + +To disable it: + +```ruby +Feature.disable(:soft_email_confirmation) +``` <!-- ## Troubleshooting |