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. -->
|