diff options
Diffstat (limited to 'doc/security/two_factor_authentication.md')
| -rw-r--r-- | doc/security/two_factor_authentication.md | 57 |
1 files changed, 28 insertions, 29 deletions
diff --git a/doc/security/two_factor_authentication.md b/doc/security/two_factor_authentication.md index f2728f95b96..a009fa9964d 100644 --- a/doc/security/two_factor_authentication.md +++ b/doc/security/two_factor_authentication.md @@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w Two-factor Authentication (2FA) provides an additional level of security to your users' GitLab account. After being enabled, in addition to supplying their -username and password to sign in, they'll be prompted for a code generated by an +username and password to sign in, they are prompted for a code generated by an application on their phone. You can read more about it here: @@ -24,12 +24,12 @@ want to enforce everyone to set up 2FA, you can choose from two different ways: - Suggest on next login, but allow a grace period before enforcing. After the configured grace period has elapsed, users can sign in but -cannot leave the 2FA configuration area at `/profile/two_factor_auth`. +cannot 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/general`). +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Settings > General** (`/admin/application_settings/general`). 1. Expand the **Sign-in restrictions** section, where you can configure both. If you want 2FA enforcement to take effect during the next sign-in attempt, @@ -39,13 +39,13 @@ change the grace period to `0`. > [Introduced in](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/24965) GitLab 12.0, 2FA settings for a group are also applied to subgroups. -If you want to enforce 2FA only for certain groups, you can: +If you want to enforce 2FA only for certain groups: -1. Enable it in the group's **Settings > General** page. Navigate to - **Permissions, LFS, 2FA > Two-factor authentication**. You can then select - the **Require all users in this group to setup Two-factor authentication** - option. -1. You can also specify a grace period in the **Time before enforced** option. +1. Go to the group's **Settings > General** page. +1. Expand the **Permissions, LFS, 2FA** section. +1. Select the **Require all users in this group to setup two-factor authentication** option. + +You can also specify a grace period in the **Time before enforced** option. To change this setting, you need to be administrator or owner of the group. @@ -67,8 +67,12 @@ The following are important notes about 2FA: 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 is used. -- It is possible to disallow subgroups from setting up their own 2FA requirements. - Navigate to the top-level group's **Settings > General > Permissions, LFS, 2FA > Two-factor authentication** and uncheck the **Allow subgroups to set up their own two-factor authentication rule** field. This action causes all subgroups with 2FA requirements to stop requiring that from their members. +- It is possible to disallow subgroups from setting up their own 2FA requirements: + 1. Go to the top-level group's **Settings > General**. + 1. Expand the **Permissions, LFS, 2FA** section. + 1. Uncheck the **Allow subgroups to set up their own two-factor authentication rule** field. + + This action causes all subgroups with 2FA requirements to stop requiring that from their members. ## Disabling 2FA for everyone @@ -77,11 +81,6 @@ Disabling 2FA for everyone does not disable the [enforce 2FA for all users](#enf or [enforce 2FA for all users in a group](#enforcing-2fa-for-all-users-in-a-group) settings. In addition to the steps in this section, you must disable any enforced 2FA settings so users aren't asked to set up 2FA again, the next time the user signs in to GitLab. -Disabling 2FA for everyone does not disable the [enforce 2FA for all users](#enforcing-2fa-for-all-users) -or [enforce 2FA for all users in a group](#enforcing-2fa-for-all-users-in-a-group) -settings if they have been configured. In addition to the steps in this section, -you must disable any enforced 2FA settings so users aren't asked to setup -2FA again when the next login to GitLab. 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: @@ -98,18 +97,6 @@ WARNING: This is a permanent and irreversible action. Users 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. --> - ## Two-factor Authentication (2FA) for Git over SSH operations **(PREMIUM)** > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/270554) in GitLab 13.7. @@ -162,3 +149,15 @@ The feature flag affects these features: - [Two-factor Authentication (2FA) for Git over SSH operations](#two-factor-authentication-2fa-for-git-over-ssh-operations). - [Customize session duration for Git Operations when 2FA is enabled](../user/admin_area/settings/account_and_limit_settings.md#customize-session-duration-for-git-operations-when-2fa-is-enabled). + +<!-- ## 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. --> |