Add latest changes from gitlab-org/gitlab@13-2-stable-ee

6 files changed, 39 insertions, 32 deletions

diff --git a/doc/administration/auth/jwt.md b/doc/administration/auth/jwt.md
index 29b192a4845..d3a77fdaca5 100644
--- a/doc/administration/auth/jwt.md
+++ b/doc/administration/auth/jwt.md
@@ -62,7 +62,8 @@ JWT will provide you with a secret key for you to use.
      }
    ```
 
-   NOTE: **Note:** For more information on each configuration option refer to
+   NOTE: **Note:**
+   For more information on each configuration option refer to
    the [OmniAuth JWT usage documentation](https://github.com/mbleigh/omniauth-jwt#usage).
 
 1. Change `YOUR_APP_SECRET` to the client secret and set `auth_url` to your redirect URL.
diff --git a/doc/administration/auth/ldap/google_secure_ldap.md b/doc/administration/auth/ldap/google_secure_ldap.md
index 2271ce93b6f..1f8fca33811 100644
--- a/doc/administration/auth/ldap/google_secure_ldap.md
+++ b/doc/administration/auth/ldap/google_secure_ldap.md
@@ -34,7 +34,8 @@ The steps below cover:
    'Entire domain (GitLab)' or 'Selected organizational units' for both 'Verify user
    credentials' and 'Read user information'. Select 'Add LDAP Client'
 
-   TIP: **Tip:** If you plan to use GitLab [LDAP Group Sync](index.md#group-sync-starter-only)
+   TIP: **Tip:**
+   If you plan to use GitLab [LDAP Group Sync](index.md#group-sync-starter-only)
    , turn on 'Read group information'.
 
    ![Add LDAP Client Step 2](img/google_secure_ldap_add_step_2.png)
diff --git a/doc/administration/auth/ldap/index.md b/doc/administration/auth/ldap/index.md
index 4a7a972596f..aef6c70ff92 100644
--- a/doc/administration/auth/ldap/index.md
+++ b/doc/administration/auth/ldap/index.md
@@ -53,7 +53,7 @@ are already logged in or are using Git over SSH will still be able to access
 GitLab for up to one hour. Manually block the user in the GitLab Admin Area to
 immediately block all access.
 
-NOTE: **Note**:
+NOTE: **Note:**
 GitLab Enterprise Edition Starter supports a
 [configurable sync time](#adjusting-ldap-user-sync-schedule-starter-only).
 
@@ -99,7 +99,7 @@ Normally, if you specify `simple_tls` it will be on port 636, while `start_tls`
 would be on port 389. `plain` also operates on port 389. Removed values: `tls` was replaced with `start_tls` and `ssl` was replaced with `simple_tls`.
 
 NOTE: **Note:**
-LDAP users must have an email address set, regardless of whether it is used to log in.
+LDAP users must have an email address set, regardless of whether it is used to sign-in.
 
 ### Example Configurations **(CORE ONLY)**
 
@@ -169,7 +169,7 @@ production:
 
 | Setting | Description | Required | Examples |
 | ------- | ----------- | -------- | -------- |
-| `label` | A human-friendly name for your LDAP server. It will be displayed on your login page. | yes | `'Paris'` or `'Acme, Ltd.'` |
+| `label` | A human-friendly name for your LDAP server. It will be displayed on your sign-in page. | yes | `'Paris'` or `'Acme, Ltd.'` |
 | `host`  | IP address or domain name of your LDAP server. | yes | `'ldap.mydomain.com'` |
 | `port`  | The port to connect with on your LDAP server. Always an integer, not a string. | yes | `389` or `636` (for SSL) |
 | `uid`   | LDAP attribute for username. Should be the attribute, not the value that maps to the `uid`. | yes | `'sAMAccountName'`, `'uid'`, `'userPrincipalName'` |
@@ -179,7 +179,7 @@ production:
 | `verify_certificates` | Enables SSL certificate verification if encryption method is `start_tls` or `simple_tls`. Defaults to true. | no | boolean |
 | `timeout` | Set a timeout, in seconds, for LDAP queries. This helps avoid blocking a request if the LDAP server becomes unresponsive. A value of 0 means there is no timeout. | no | `10` or `30` |
 | `active_directory` | This setting specifies if LDAP server is Active Directory LDAP server. For non-AD servers it skips the AD specific queries. If your LDAP server is not AD, set this to false. | no | boolean |
-| `allow_username_or_email_login` | If enabled, GitLab will ignore everything after the first `@` in the LDAP username submitted by the user on login. If you are using `uid: 'userPrincipalName'` on ActiveDirectory you need to disable this setting, because the userPrincipalName contains an `@`. | no | boolean |
+| `allow_username_or_email_login` | If enabled, GitLab will ignore everything after the first `@` in the LDAP username submitted by the user on sign-in. If you are using `uid: 'userPrincipalName'` on ActiveDirectory you need to disable this setting, because the userPrincipalName contains an `@`. | no | boolean |
 | `block_auto_created_users` | To maintain tight control over the number of active users on your GitLab installation, enable this setting to keep new users blocked until they have been cleared by the admin (default: false). | no | boolean |
 | `base` | Base where we can search for users. | yes | `'ou=people,dc=gitlab,dc=example'` or `'DC=mydomain,DC=com'` |
 | `user_filter` | Filter LDAP users. Format: [RFC 4515](https://tools.ietf.org/search/rfc4515) Note: GitLab does not support `omniauth-ldap`'s custom filter syntax. | no | `'(employeeType=developer)'` or `'(&(objectclass=user)(|(samaccountname=momo)(samaccountname=toto)))'` |
@@ -197,7 +197,7 @@ production:
 
 ### Attribute Configuration Settings **(CORE ONLY)**
 
-LDAP attributes that GitLab will use to create an account for the LDAP user. The specified attribute can either be the attribute name as a string (e.g. `'mail'`), or an array of attribute names to try in order (e.g. `['mail', 'email']`). Note that the user's LDAP login will always be the attribute specified as `uid` above.
+LDAP attributes that GitLab will use to create an account for the LDAP user. The specified attribute can either be the attribute name as a string (e.g. `'mail'`), or an array of attribute names to try in order (e.g. `['mail', 'email']`). Note that the user's LDAP sign-in will always be the attribute specified as `uid` above.
 
 | Setting | Description | Required | Examples |
 | ------- | ----------- | -------- | -------- |
@@ -396,7 +396,7 @@ Be sure to choose a different provider ID made of letters a-z and numbers 0-9.
 This ID will be stored in the database so that GitLab can remember which LDAP
 server a user belongs to.
 
-![Multiple LDAP Servers Login](img/multi_login.gif)
+![Multiple LDAP Servers Sign in](img/multi_login.gif)
 
 Based on the example illustrated on the image above,
 our `gitlab.rb` configuration would look like:
@@ -424,7 +424,7 @@ gitlab_rails['ldap_servers'] = {
   'port' => 636,
   ...
   }
-  
+
 }
 ```
 
@@ -450,7 +450,7 @@ has bit 2 set. See <https://ctovswild.com/2009/09/03/bitmask-searches-in-ldap/>
 for more information.
 
 The user will be set to `ldap_blocked` state in GitLab if the above conditions
-fail. This means the user will not be able to login or push/pull code.
+fail. This means the user will not be able to sign-in or push/pull code.
 
 The process will also update the following user information:
 
@@ -605,6 +605,12 @@ When enabled, the following applies:
 - Users are not allowed to share project with other groups or invite members to
   a project created in a group.
 
+To enable it you need to:
+
+1. [Enable LDAP](#configuration-core-only)
+1. Navigate to **(admin)** **Admin Area > Settings -> Visibility and access controls**.
+1. Make sure the "Lock memberships to LDAP synchronization" checkbox is enabled.
+
 ### Adjusting LDAP group sync schedule **(STARTER ONLY)**
 
 NOTE: **Note:**
diff --git a/doc/administration/auth/ldap/ldap-troubleshooting.md b/doc/administration/auth/ldap/ldap-troubleshooting.md
index 909802b5dec..75183f54990 100644
--- a/doc/administration/auth/ldap/ldap-troubleshooting.md
+++ b/doc/administration/auth/ldap/ldap-troubleshooting.md
@@ -27,7 +27,7 @@ Could not authenticate you from Ldapmain because "Connection timed out - user sp
 ```
 
 If your configured LDAP provider and/or endpoint is offline or otherwise
-unreachable by GitLab, no LDAP user will be able to authenticate and log in.
+unreachable by GitLab, no LDAP user will be able to authenticate and sign-in.
 GitLab does not cache or store credentials for LDAP users to provide authentication
 during an LDAP outage.
 
@@ -81,7 +81,7 @@ adapter.ldap_search(options)
 For examples of how this is run,
 [review the `Adapter` module](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/lib/ee/gitlab/auth/ldap/adapter.rb).
 
-### User logins
+### User sign-ins
 
 #### No users are found
 
@@ -97,24 +97,24 @@ In this case, you con confirm which of the above is true using
 [ldapsearch](#ldapsearch) with the existing LDAP configuration in your
 `/etc/gitlab/gitlab.rb`.
 
-#### User(s) cannot login
+#### User(s) cannot sign-in
 
-A user can have trouble logging in for any number of reasons. To get started,
+A user can have trouble signing in for any number of reasons. To get started,
 here are some questions to ask yourself:
 
 - Does the user fall under the [configured `base`](index.md#configuration-core-only) in
-  LDAP? The user must fall under this `base` to login.
+  LDAP? The user must fall under this `base` to sign-in.
 - Does the user pass through the [configured `user_filter`](index.md#set-up-ldap-user-filter-core-only)?
   If one is not configured, this question can be ignored. If it is, then the
-  user must also pass through this filter to be allowed to login.
+  user must also pass through this filter to be allowed to sign-in.
   - Refer to our docs on [debugging the `user_filter`](#debug-ldap-user-filter).
 
 If the above are both okay, the next place to look for the problem is
 the logs themselves while reproducing the issue.
 
-- Ask the user to login and let it fail.
+- Ask the user to sign-in and let it fail.
 - [Look through the output](#gitlab-logs) for any errors or other
-  messages about the login. You may see one of the other error messages on
+  messages about the sign-in. You may see one of the other error messages on
   this page, in which case that section can help resolve the issue.
 
 If the logs don't lead to the root of the problem, use the
@@ -125,9 +125,9 @@ It can also be helpful to
 [debug a user sync](#sync-all-users-starter-only) to
 investigate further.
 
-#### Invalid credentials on login
+#### Invalid credentials on sign-in
 
-If that the login credentials used are accurate on LDAP, ensure the following
+If that the sign-in credentials used are accurate on LDAP, ensure the following
 are true for the user in question:
 
 - Make sure the user you are binding with has enough permissions to read the user's
@@ -138,7 +138,7 @@ are true for the user in question:
 
 #### Email has already been taken
 
-A user tries to login with the correct LDAP credentials, is denied access,
+A user tries to sign-in with the correct LDAP credentials, is denied access,
 and the [production.log](../../logs.md#productionlog) shows an error that looks like this:
 
 ```plaintext
@@ -163,7 +163,7 @@ user.username
 This will show you which user has this email address. One of two steps will
 have to be taken here:
 
-- To create a new GitLab user/username for this user when logging in with LDAP,
+- To create a new GitLab user/username for this user when signing in with LDAP,
   remove the secondary email to remove the conflict.
 - To use an existing GitLab user/username for this user to use with LDAP,
   remove this email as a secondary email and make it a primary one so GitLab
@@ -235,7 +235,7 @@ uid: John
 There's a lot here, so let's go over what could be helpful when debugging.
 
 First, GitLab will look for all users that have previously
-logged in with LDAP and iterate on them. Each user's sync will start with
+signed in with LDAP and iterate on them. Each user's sync will start with
 the following line that contains the user's username and email, as they
 exist in GitLab now:
 
@@ -244,7 +244,7 @@ Syncing user John, email@example.com
 ```
 
 If you don't find a particular user's GitLab email in the output, then that
-user hasn't logged in with LDAP yet.
+user hasn't signed in with LDAP yet.
 
 Next, GitLab searches its `identities` table for the existing
 link between this user and the configured LDAP provider(s):
@@ -313,7 +313,7 @@ things to check to debug the situation.
   1. Search for the user
   1. Open the user, by clicking on their name. Do not click 'Edit'.
   1. Navigate to the **Identities** tab. There should be an LDAP identity with
-     an LDAP DN as the 'Identifier'. If not, this user hasn't logged in with
+     an LDAP DN as the 'Identifier'. If not, this user hasn't signed in with
      LDAP yet and must do so first.
 - You've waited an hour or [the configured
   interval](index.md#adjusting-ldap-group-sync-schedule-starter-only) for the group to
@@ -346,7 +346,7 @@ the following are true:
 - A [`group_base` is also configured](index.md#group-sync-starter-only).
 - The configured `admin_group` in the `gitlab.rb` is a CN, rather than a DN or an array.
 - This CN falls under the scope of the configured `group_base`.
-- The members of the `admin_group` have already logged into GitLab with their LDAP
+- The members of the `admin_group` have already signed into GitLab with their LDAP
   credentials. GitLab will only grant this admin access to the users whose
   accounts are already connected to LDAP.
 
@@ -357,7 +357,7 @@ GitLab syncs the `admin_group`.
 
 #### Sync all groups **(STARTER ONLY)**
 
-NOTE: **NOTE:**
+NOTE: **Note:**
 To sync all groups manually when debugging is unnecessary, [use the Rake
 task](../../raketasks/ldap.md#run-a-group-sync-starter-only) instead.
 
@@ -571,7 +571,7 @@ If a user account is blocked or unblocked due to the LDAP configuration, a
 message will be [logged to `application.log`](../../logs.md#applicationlog).
 
 If there is an unexpected error during an LDAP lookup (configuration error,
-timeout), the login is rejected and a message will be [logged to
+timeout), the sign-in is rejected and a message will be [logged to
 `production.log`](../../logs.md#productionlog).
 
 ### ldapsearch
@@ -653,7 +653,7 @@ adfind -h ad.example.org:636 -ssl -u "CN=GitLabSRV,CN=Users,DC=GitLab,DC=org" -u
 
 ### Rails console
 
-CAUTION: **CAUTION:**
+CAUTION: **Caution:**
 Please note that it is very easy to create, read, modify, and destroy data on the
 rails console, so please be sure to run commands exactly as listed.
 
diff --git a/doc/administration/auth/okta.md b/doc/administration/auth/okta.md
index f7ab60ab56b..78b10aedb77 100644
--- a/doc/administration/auth/okta.md
+++ b/doc/administration/auth/okta.md
@@ -159,8 +159,7 @@ You might want to try this out on an incognito browser window.
 >**Note:**
 Make sure the groups exist and are assigned to the Okta app.
 
-You can take a look of the [SAML documentation](../../integration/saml.md#marking-users-as-external-based-on-saml-groups) on external groups since
-it works the same.
+You can take a look of the [SAML documentation](../../integration/saml.md#saml-groups) on configuring groups.
 
 <!-- ## Troubleshooting
 
diff --git a/doc/administration/auth/smartcard.md b/doc/administration/auth/smartcard.md
index 9ad1e0641f6..80d2efbad84 100644
--- a/doc/administration/auth/smartcard.md
+++ b/doc/administration/auth/smartcard.md
@@ -208,7 +208,7 @@ attribute. As a prerequisite, you must use an LDAP server that:
      client_certificate_required_port: 3443
    ```
 
-   NOTE: **Note**
+   NOTE: **Note:**
    Assign a value to at least one of the following variables:
    `client_certificate_required_host` or `client_certificate_required_port`.