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

185 lines
7.8 KiB
Markdown
Raw Normal View History

2019-09-04 21:01:54 +05:30
---
2021-01-29 00:20:46 +05:30
stage: none
group: unassigned
2021-02-22 17:27:13 +05:30
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/#assignments
2019-09-04 21:01:54 +05:30
type: reference
---
2021-03-11 19:13:27 +05:30
# Sign-up restrictions **(FREE SELF)**
2016-08-24 12:49:21 +05:30
2021-01-29 00:20:46 +05:30
You can enforce the following restrictions on sign ups:
2017-08-17 22:00:37 +05:30
2021-01-29 00:20:46 +05:30
- Disable new sign ups.
- Require administrator approval for new sign ups.
2020-03-13 15:44:24 +05:30
- Require user email confirmation.
2021-01-29 00:20:46 +05:30
- Allow or deny sign ups using specific email domains.
2020-03-13 15:44:24 +05:30
2021-01-29 00:20:46 +05:30
## Disable new sign ups
2017-08-17 22:00:37 +05:30
2021-01-29 00:20:46 +05:30
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.
2020-03-13 15:44:24 +05:30
2021-01-29 00:20:46 +05:30
To disable sign ups:
2020-03-13 15:44:24 +05:30
2021-11-11 11:23:49 +05:30
1. On the top bar, select **Menu > Admin**.
1. On the left sidebar, select **Settings > General**, and expand **Sign-up restrictions**.
2021-01-29 00:20:46 +05:30
1. Clear the **Sign-up enabled** checkbox, then select **Save changes**.
2020-03-13 15:44:24 +05:30
2021-01-29 00:20:46 +05:30
## Require administrator approval for new sign ups
2020-03-13 15:44:24 +05:30
2021-01-29 00:20:46 +05:30
> - [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.
2020-03-13 15:44:24 +05:30
2021-11-18 22:05:49 +05:30
When this setting is enabled, any user visiting your GitLab domain and signing up for a new account using the registration form
2021-10-27 15:23:28 +05:30
must be explicitly [approved](../moderate_users.md#approve-or-reject-a-user-sign-up) by an
administrator before they can start using their account. In GitLab 13.6 and later, this setting is
enabled by default for new GitLab instances. It is only applicable if sign ups are enabled.
2020-03-13 15:44:24 +05:30
2021-01-29 00:20:46 +05:30
To require administrator approval for new sign ups:
2020-03-13 15:44:24 +05:30
2021-11-11 11:23:49 +05:30
1. On the top bar, select **Menu > Admin**.
1. On the left sidebar, select **Settings > General**, and expand **Sign-up restrictions**.
2021-01-29 00:20:46 +05:30
1. Select the **Require admin approval for new sign-ups** checkbox, then select **Save changes**.
2021-01-03 14:25:43 +05:30
2021-02-22 17:27:13 +05:30
In [GitLab 13.7 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/273258), if an administrator disables this setting, the users in pending approval state are
automatically approved in a background job.
2021-11-18 22:05:49 +05:30
NOTE:
This setting doesn't apply to LDAP or OmniAuth users. To enforce approvals for new users
signing up using OmniAuth or LDAP, set `block_auto_created_users` to `true` in the
2021-12-11 22:18:48 +05:30
[OmniAuth configuration](../../../integration/omniauth.md#configure-initial-settings) or
2021-11-18 22:05:49 +05:30
[LDAP configuration](../../../administration/auth/ldap/index.md#basic-configuration-settings).
2021-01-29 00:20:46 +05:30
## Require email confirmation
2021-01-03 14:25:43 +05:30
2021-01-29 00:20:46 +05:30
You can send confirmation emails during sign up and require that users confirm
their email address before they are allowed to sign in.
2021-01-03 14:25:43 +05:30
2021-01-29 00:20:46 +05:30
To enforce confirmation of the email address used for new sign ups:
2021-01-03 14:25:43 +05:30
2021-11-11 11:23:49 +05:30
1. On the top bar, select **Menu > Admin**.
1. On the left sidebar, select **Settings > General**, and expand **Sign-up restrictions**.
2021-01-29 00:20:46 +05:30
1. Select the **Enable email restrictions for sign ups** checkbox, then select **Save changes**.
2019-10-12 21:52:04 +05:30
2021-11-18 22:05:49 +05:30
## User cap
2021-01-29 00:20:46 +05:30
2021-02-22 17:27:13 +05:30
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/4315) in GitLab 13.7.
2021-03-11 19:13:27 +05:30
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/292600) in GitLab 13.9.
2019-10-12 21:52:04 +05:30
2021-02-22 17:27:13 +05:30
When the number of billable users reaches the user cap, any user who is added or requests access must be
2021-10-27 15:23:28 +05:30
[approved](../moderate_users.md#approve-or-reject-a-user-sign-up) by an administrator before they can start using
2021-01-29 00:20:46 +05:30
their account.
2021-04-17 20:07:23 +05:30
If an administrator [increases](#set-the-user-cap-number) or [removes](#remove-the-user-cap) the
user cap, the users in pending approval state are automatically approved in a background job.
### Set the user cap number
2021-11-11 11:23:49 +05:30
1. On the top bar, select **Menu > Admin**.
1. On the left sidebar, select **Settings > General**.
2021-04-17 20:07:23 +05:30
1. Expand **Sign-up restrictions**.
1. Enter a number in **User cap**.
1. Select **Save changes**.
New user sign ups are subject to the user cap restriction.
## Remove the user cap
2021-11-11 11:23:49 +05:30
1. On the top bar, select **Menu > Admin**.
1. On the left sidebar, select **Settings > General**.
2021-04-17 20:07:23 +05:30
1. Expand **Sign-up restrictions**.
1. Remove the number from **User cap**.
1. Select **Save changes**.
New users sign ups are not subject to the user cap restriction. Users in pending approval state are
2021-02-22 17:27:13 +05:30
automatically approved in a background job.
2021-01-29 00:20:46 +05:30
## Soft email confirmation
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/47003) in GitLab 12.2.
2021-03-11 19:13:27 +05:30
> - It's [deployed behind a feature flag](../../../user/feature_flags.md), disabled by default.
2021-01-29 00:20:46 +05:30
> - 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).
2021-02-22 17:27:13 +05:30
WARNING:
2021-01-29 00:20:46 +05:30
This feature might not be available to you. Check the **version history** note above for details.
2021-03-11 19:13:27 +05:30
The soft email confirmation improves the sign-up experience for new users by allowing
2021-01-29 00:20:46 +05:30
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.
2019-10-12 21:52:04 +05:30
2020-01-01 13:55:28 +05:30
## Minimum password length limit
2020-03-13 15:44:24 +05:30
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20661) in GitLab 12.6
2020-01-01 13:55:28 +05:30
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.
2021-01-29 00:20:46 +05:30
## 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
2021-11-18 22:05:49 +05:30
user through the administrator panel with a disallowed domain. Also, note that the users can change their
2021-01-29 00:20:46 +05:30
email addresses to disallowed domains after sign up.
### Allowlist email domains
2017-08-17 22:00:37 +05:30
2020-11-24 15:15:51 +05:30
You can restrict users only to sign up using email addresses matching the given
2017-08-17 22:00:37 +05:30
domains list.
2021-01-29 00:20:46 +05:30
### Denylist email domains
2016-08-24 12:49:21 +05:30
2021-01-29 00:20:46 +05:30
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.
2017-08-17 22:00:37 +05:30
2021-01-29 00:20:46 +05:30
### Create email domain allowlist or denylist
2016-08-24 12:49:21 +05:30
2021-01-29 00:20:46 +05:30
To create an email domain allowlist or denylist:
2019-09-30 21:07:59 +05:30
2021-11-11 11:23:49 +05:30
1. On the top bar, select **Menu > Admin**.
1. On the left sidebar, select **Settings > General**, and expand **Sign-up restrictions**.
2021-01-29 00:20:46 +05:30
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.
2019-09-30 21:07:59 +05:30
2021-01-29 00:20:46 +05:30
Both the allowlist and denylist accept wildcards. For example, you can use
2017-08-17 22:00:37 +05:30
`*.company.com` to accept every `company.com` subdomain, or `*.io` to block all
2021-01-29 00:20:46 +05:30
domains ending in `.io`. Domains must be separated by a whitespace,
2017-08-17 22:00:37 +05:30
semicolon, comma, or a new line.
2016-08-24 12:49:21 +05:30
2021-10-27 15:23:28 +05:30
![Domain Denylist](img/domain_denylist_v14_1.png)
2021-01-29 00:20:46 +05:30
### 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)
```
2016-08-24 12:49:21 +05:30
2019-09-04 21:01:54 +05:30
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->