debian-mirror-gitlab/doc/security/two_factor_authentication.md

92 lines
3.8 KiB
Markdown
Raw Normal View History

2019-09-04 21:01:54 +05:30
---
type: howto
---
2019-09-30 21:07:59 +05:30
# Enforce Two-factor Authentication (2FA)
Two-factor Authentication (2FA) provides an additional level of security to your
users' GitLab account. Once enabled, in addition to supplying their username and
password to login, they'll be prompted for a code generated by an application on
their phone.
You can read more about it here:
2019-02-15 15:39:39 +05:30
[Two-factor Authentication (2FA)](../user/profile/account/two_factor_authentication.md)
2017-08-17 22:00:37 +05:30
## Enforcing 2FA for all users
Users on GitLab, can enable it without any admin's intervention. If you want to
2018-12-05 23:21:45 +05:30
enforce everyone to set up 2FA, you can choose from two different ways:
2019-02-15 15:39:39 +05:30
- Enforce on next login.
- Suggest on next login, but allow a grace period before enforcing.
2019-09-04 21:01:54 +05:30
After the configured grace period has elapsed, users will be able to log in but
won't be able to leave the 2FA configuration area at `/profile/two_factor_auth`.
To enable 2FA for all users:
1. Navigate to **Admin area > Settings > General** (`/admin/application_settings`).
1. Expand the **Sign-in restrictions** section, where you can configure both.
If you want 2FA enforcement to take effect on next login, change the grace
2016-04-02 18:10:28 +05:30
period to `0`.
2019-09-04 21:01:54 +05:30
## Enforcing 2FA for all users in a group
2016-04-02 18:10:28 +05:30
2019-09-04 21:01:54 +05:30
If you want to enforce 2FA only for certain groups, you can:
2016-04-02 18:10:28 +05:30
2019-09-04 21:01:54 +05:30
1. Enable it in the group's **Settings > General** page.
1. Optionally specify a grace period as above.
2019-09-04 21:01:54 +05:30
To change this setting, you need to be administrator or owner of the group.
> [From](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/24965) GitLab 12.0, 2FA settings for a group are also applied to subgroups.
2017-08-17 22:00:37 +05:30
If you want to enforce 2FA only for certain groups, you can enable it in the
group settings and specify a grace period as above. To change this setting you
need to be administrator or owner of the group.
2019-09-04 21:01:54 +05:30
The following are important notes about 2FA:
- Projects belonging to a 2FA-enabled group that
2019-09-30 21:07:59 +05:30
[is shared](../user/project/members/share_project_with_groups.md)
2019-09-04 21:01:54 +05:30
with a 2FA-disabled group will *not* require members of the 2FA-disabled group to use
2019-09-30 21:07:59 +05:30
2FA for the project. For example, if project *P* belongs to 2FA-enabled group *A* and
2019-09-04 21:01:54 +05:30
is shared with 2FA-disabled group *B*, members of group *B* can access project *P*
2019-09-30 21:07:59 +05:30
without 2FA. To ensure this scenario doesn't occur,
2019-09-04 21:01:54 +05:30
[prevent sharing of projects](../user/group/index.md#share-with-group-lock)
for the 2FA-enabled group.
- If you add additional members to a project within a group or subgroup that has
2FA enabled, 2FA is **not** required for those individually added members.
- If there are multiple 2FA requirements (for example, group + all users, or multiple
groups) the shortest grace period will be used.
2017-08-17 22:00:37 +05:30
## Disabling 2FA for everyone
There may be some special situations where you want to disable 2FA for everyone
even when forced 2FA is disabled. There is a rake task for that:
2019-09-04 21:01:54 +05:30
```sh
2016-04-02 18:10:28 +05:30
# Omnibus installations
sudo gitlab-rake gitlab:two_factor:disable_for_all_users
2016-04-02 18:10:28 +05:30
# Installations from source
sudo -u git -H bundle exec rake gitlab:two_factor:disable_for_all_users RAILS_ENV=production
```
2019-09-04 21:01:54 +05:30
CAUTION: **Caution:**
This is a permanent and irreversible action. Users will have to
reactivate 2FA from scratch if they want to use it again.
<!-- ## 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. -->