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

97 lines
3.5 KiB
Markdown
Raw Normal View History

2019-09-04 21:01:54 +05:30
---
type: reference
---
2019-12-04 20:38:33 +05:30
# Sign-up restrictions **(CORE ONLY)**
2016-08-24 12:49:21 +05:30
2020-03-13 15:44:24 +05:30
You can use sign-up restrictions to:
2017-08-17 22:00:37 +05:30
2020-03-13 15:44:24 +05:30
- Disable new signups.
- Require user email confirmation.
- Blacklist or whitelist email addresses belonging to specific domains.
NOTE: **Note:**
These restrictions are only applied during sign-up from an external user. An admin is
2019-02-15 15:39:39 +05:30
able to add a user through the admin panel with a disallowed domain. Also
2017-08-17 22:00:37 +05:30
note that the users can change their email addresses after signup to
disallowed domains.
2020-03-13 15:44:24 +05:30
## Disable new signups
When this setting is enabled, any user visiting your GitLab domain will be able to sign up for an account.
![Disable signups](img/disable_signup_v12_7.png)
You can restrict new users from signing up by themselves for an account in your instance by disabling this setting.
### Recommendations
For customers running public facing GitLab instances, we highly recommend that you
consider disabling new signups if you do not expect public users to sign up for an
account.
Alternatively, you could also consider setting up a
[whitelist](#whitelist-email-domains) or [blacklist](#blacklist-email-domains) on
email domains to prevent malicious users from creating accounts.
2019-10-12 21:52:04 +05:30
## 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.
2020-03-13 15:44:24 +05:30
![Email confirmation](img/email_confirmation_v12_7.png)
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.
2017-08-17 22:00:37 +05:30
## Whitelist email domains
2020-05-24 23:13:21 +05:30
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/598) in GitLab 7.11.0
2017-08-17 22:00:37 +05:30
2019-10-12 21:52:04 +05:30
You can restrict users to only sign up using email addresses matching the given
2017-08-17 22:00:37 +05:30
domains list.
2016-08-24 12:49:21 +05:30
## Blacklist email domains
2020-05-24 23:13:21 +05:30
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/5259) in GitLab 8.10.
2016-08-24 12:49:21 +05:30
With this feature enabled, you can block email addresses of a specific domain
2019-10-12 21:52:04 +05:30
from creating an account on your GitLab server. This is particularly useful
to prevent malicious users from creating spam accounts with disposable email
addresses.
2016-08-24 12:49:21 +05:30
2017-08-17 22:00:37 +05:30
## Settings
2019-09-30 21:07:59 +05:30
To access this feature:
2016-08-24 12:49:21 +05:30
2020-03-13 15:44:24 +05:30
1. Navigate to the **Admin Area > Settings > General**.
2019-09-30 21:07:59 +05:30
1. Expand the **Sign-up restrictions** section.
2019-10-12 21:52:04 +05:30
For the blacklist, you can enter the list manually or upload a `.txt` file that
contains list entries.
2019-09-30 21:07:59 +05:30
2019-10-12 21:52:04 +05:30
For the whitelist, you must enter the list manually.
2019-09-30 21:07:59 +05:30
Both the whitelist and blacklist 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
domains ending in `.io`. Domains should be separated by a whitespace,
semicolon, comma, or a new line.
2016-08-24 12:49:21 +05:30
![Domain Blacklist](img/domain_blacklist.png)
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. -->