Add latest changes from gitlab-org/gitlab@14-2-stable-eev14.2.0-rc42

5 files changed, 12 insertions, 24 deletions

diff --git a/doc/administration/auth/atlassian.md b/doc/administration/auth/atlassian.md
index b3892f8f5d9..868482148e5 100644
--- a/doc/administration/auth/atlassian.md
+++ b/doc/administration/auth/atlassian.md
@@ -12,22 +12,14 @@ To enable the Atlassian OmniAuth provider for passwordless authentication you mu
 ## Atlassian application registration
 
 1. Go to <https://developer.atlassian.com/console/myapps/> and sign-in with the Atlassian
-   account that will administer the application.
-
+   account to administer the application.
 1. Click **Create a new app**.
-
 1. Choose an App Name, such as 'GitLab', and click **Create**.
-
 1. Note the `Client ID` and `Secret` for the [GitLab configuration](#gitlab-configuration) steps.
-
 1. In the left sidebar under **APIS AND FEATURES**, click **OAuth 2.0 (3LO)**.
-
 1. Enter the GitLab callback URL using the format `https://gitlab.example.com/users/auth/atlassian_oauth2/callback` and click **Save changes**.
-
 1. Click **+ Add** in the left sidebar under **APIS AND FEATURES**.
-
 1. Click **Add** for **Jira platform REST API** and then **Configure**.
-
 1. Click **Add** next to the following scopes:
     - **View Jira issue data**
     - **View user profiles**
@@ -50,7 +42,6 @@ To enable the Atlassian OmniAuth provider for passwordless authentication you mu
    ```
 
 1. See [Initial OmniAuth Configuration](../../integration/omniauth.md#initial-omniauth-configuration) for initial settings to enable single sign-on and add `atlassian_oauth2` as an OAuth provider.
-
 1. Add the provider configuration for Atlassian:
 
    For Omnibus GitLab installations:
@@ -76,9 +67,7 @@ To enable the Atlassian OmniAuth provider for passwordless authentication you mu
    ```
 
 1. Change `YOUR_CLIENT_ID` and `YOUR_CLIENT_SECRET` to the Client credentials you received in [application registration](#atlassian-application-registration) steps.
-
 1. Save the configuration file.
-
 1. [Reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) or [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect if you installed GitLab via Omnibus or from source respectively.
 
 On the sign-in page there should now be an Atlassian icon below the regular sign in form. Click the icon to begin the authentication process.
diff --git a/doc/administration/auth/cognito.md b/doc/administration/auth/cognito.md
index de5fa991abe..41e77c10e27 100644
--- a/doc/administration/auth/cognito.md
+++ b/doc/administration/auth/cognito.md
@@ -12,8 +12,7 @@ The following documentation enables Cognito as an OAuth2 provider.
 
 ## Configure AWS Cognito
 
-To enable the [AWS Cognito](https://aws.amazon.com/cognito/) OAuth2 OmniAuth provider, register your application with Cognito,
-where it will generate a Client ID and Client Secret for your application.
+To enable the [AWS Cognito](https://aws.amazon.com/cognito/) OAuth2 OmniAuth provider, register your application with Cognito. This process generates a Client ID and Client Secret for your application.
 Any settings you configure in the following procedure can be modified later.
 The following steps enable AWS Cognito as an authentication provider:
 
@@ -24,7 +23,7 @@ The following steps enable AWS Cognito as an authentication provider:
 1. Under **How do you want your end users to sign in?**, select **Email address or phone number** and **Allow email addresses**.
 1. Under **Which standard attributes do you want to require?**, select **email**.
 1. Go to the next steps of configuration and set the rest of the settings to suit your needs - in the basic setup they are not related to GitLab configuration.
-1. In the **App clients** settings, click **Add an app client**, add **App client name** and select the **Enable username password based authentication** check box.
+1. In the **App clients** settings, click **Add an app client**, add **App client name** and select the **Enable username password based authentication** checkbox.
 1. Click **Create app client**.
 1. In the next step, you can set up AWS Lambda functions for sending emails. You can then finish creating the pool.
 1. After creating the user pool, go to **App client settings** and provide the required information:
@@ -86,7 +85,7 @@ Include the code block in the `/etc/gitlab/gitlab.rb` file:
 1. Save the file and [reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) GitLab for the changes to take effect.
 
 Your sign-in page should now display a Cognito button below the regular sign-in form.
-To begin the authentication process, click the icon, and AWS Cognito will ask the user to sign in and authorize the GitLab application.
-If successful, the user will be redirected and signed in to your GitLab instance.
+To begin the authentication process, click the icon, and AWS Cognito asks the user to sign in and authorize the GitLab application.
+If successful, the user is redirected and signed in to your GitLab instance.
 
 For more information, see the [Initial OmniAuth Configuration](../../integration/omniauth.md#initial-omniauth-configuration).
diff --git a/doc/administration/auth/ldap/index.md b/doc/administration/auth/ldap/index.md
index a9d59ca0983..63e3a0a3686 100644
--- a/doc/administration/auth/ldap/index.md
+++ b/doc/administration/auth/ldap/index.md
@@ -197,8 +197,8 @@ Some examples of the `user_filter` field syntax:
 
 LDAP attributes that GitLab uses to create an account for the LDAP user. The specified
 attribute can either be the attribute name as a string (for example, `'mail'`), or an
-array of attribute names to try in order (for example, `['mail', 'email']`). Note that
-the user's LDAP sign-in is the attribute specified as `uid` above.
+array of attribute names to try in order (for example, `['mail', 'email']`).
+The user's LDAP sign-in is the attribute specified as `uid` above.
 
 | Setting      | Description | Required | Examples |
 |--------------|-------------|----------|----------|
@@ -654,7 +654,7 @@ NOTE:
 Administrators are not synced unless `group_base` is also
 specified alongside `admin_group`. Also, only specify the CN of the `admin_group`,
 as opposed to the full DN.
-Additionally, note that if an LDAP user has an `admin` role, but is not a member of the `admin_group`
+Additionally, if an LDAP user has an `admin` role, but is not a member of the `admin_group`
 group, GitLab revokes their `admin` role when syncing.
 
 **Omnibus configuration**
diff --git a/doc/administration/auth/ldap/ldap-troubleshooting.md b/doc/administration/auth/ldap/ldap-troubleshooting.md
index 5e6c3443e44..15e8496e915 100644
--- a/doc/administration/auth/ldap/ldap-troubleshooting.md
+++ b/doc/administration/auth/ldap/ldap-troubleshooting.md
@@ -426,7 +426,7 @@ Started syncing 'ldapmain' provider for 'my_group' group
 ```
 
 The following entry shows an array of all user DNs GitLab sees in the LDAP server.
-Note that these are the users for a single LDAP group, not a GitLab group. If
+These are the users for a single LDAP group, not a GitLab group. If
 you have multiple LDAP groups linked to this GitLab group, you see multiple
 log entries like this - one for each LDAP group. If you don't see an LDAP user
 DN in this log entry, LDAP is not returning the user when we do the lookup.
@@ -666,7 +666,7 @@ ldapsearch -D "cn=admin,dc=ldap-testing,dc=example,dc=com" \
   -b "dc=ldap-testing,dc=example,dc=com"
 ```
 
-Note that the `bind_dn`, `password`, `port`, `host`, and `base` are all
+The `bind_dn`, `password`, `port`, `host`, and `base` are all
 identical to what's configured in the `gitlab.rb`.
 
 For more information, see the [official `ldapsearch` documentation](https://linux.die.net/man/1/ldapsearch).
diff --git a/doc/administration/auth/oidc.md b/doc/administration/auth/oidc.md
index 951c7df26ef..6a037e75f54 100644
--- a/doc/administration/auth/oidc.md
+++ b/doc/administration/auth/oidc.md
@@ -280,7 +280,7 @@ but `LocalAccounts` works for authenticating against local, Active Directory acc
    The policy name is lowercased in the URL. For example, `B2C_1A_signup_signin`
    policy appears as `b2c_1a_signup_sigin`.
 
-   Note that the trailing forward slash is required.
+The trailing forward slash is required.
 
 1. Verify the operation of the OIDC discovery URL and issuer URL, append `.well-known/openid-configuration`
    to the issuer URL:
@@ -336,7 +336,7 @@ but `LocalAccounts` works for authenticating against local, Active Directory acc
   - `"accessTokenAcceptedVersion": null`
   - `"signInAudience": "AzureADMyOrg"`
 
-  Note that this configuration corresponds with the `Supported account types` setting used when
+This configuration corresponds with the `Supported account types` setting used when
   creating the `IdentityExperienceFramework` app.
 
 #### Keycloak