Replace login with sign-in

doc/administration/auth/ldap/index.md

@@ -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:
 

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