diff options
Diffstat (limited to 'doc/administration/auth')
| -rw-r--r-- | doc/administration/auth/atlassian.md | 16 | ||||
| -rw-r--r-- | doc/administration/auth/ldap/ldap-troubleshooting.md | 14 |
2 files changed, 15 insertions, 15 deletions
diff --git a/doc/administration/auth/atlassian.md b/doc/administration/auth/atlassian.md index 7c6aee2c2da..6be53922a5a 100644 --- a/doc/administration/auth/atlassian.md +++ b/doc/administration/auth/atlassian.md @@ -13,14 +13,14 @@ To enable the Atlassian OmniAuth provider for passwordless authentication you mu 1. Go to <https://developer.atlassian.com/console/myapps/> and sign-in with the Atlassian account to administer the application. -1. Click **Create a new app**. -1. Choose an App Name, such as 'GitLab', and click **Create**. +1. Select **Create a new app**. +1. Choose an App Name, such as 'GitLab', and select **Create**. 1. Note the `Client ID` and `Secret` for the [GitLab configuration](#gitlab-configuration) steps. -1. On 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: +1. On the left sidebar under **APIS AND FEATURES**, select **OAuth 2.0 (3LO)**. +1. Enter the GitLab callback URL using the format `https://gitlab.example.com/users/auth/atlassian_oauth2/callback` and select **Save changes**. +1. Select **+ Add** in the left sidebar under **APIS AND FEATURES**. +1. Select **Add** for **Jira platform REST API** and then **Configure**. +1. Select **Add** next to the following scopes: - **View Jira issue data** - **View user profiles** - **Create and manage issues** @@ -73,6 +73,6 @@ To enable the Atlassian OmniAuth provider for passwordless authentication you mu 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. +On the sign-in page there should now be an Atlassian icon below the regular sign in form. Select the icon to begin the authentication process. If everything goes right, the user is signed in to GitLab using their Atlassian credentials. diff --git a/doc/administration/auth/ldap/ldap-troubleshooting.md b/doc/administration/auth/ldap/ldap-troubleshooting.md index 06fe579e101..b8391bec72f 100644 --- a/doc/administration/auth/ldap/ldap-troubleshooting.md +++ b/doc/administration/auth/ldap/ldap-troubleshooting.md @@ -89,14 +89,14 @@ established but GitLab doesn't show you LDAP users in the output, one of the following is most likely true: - The `bind_dn` user doesn't have enough permissions to traverse the user tree. -- The user(s) don't fall under the [configured `base`](index.md#configure-ldap). -- The [configured `user_filter`](index.md#set-up-ldap-user-filter) blocks access to the user(s). +- The users don't fall under the [configured `base`](index.md#configure-ldap). +- The [configured `user_filter`](index.md#set-up-ldap-user-filter) blocks access to the users. 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 sign-in +#### Users cannot sign-in A user can have trouble signing in for any number of reasons. To get started, here are some questions to ask yourself: @@ -284,7 +284,7 @@ If you don't find a particular user's GitLab email in the output, then that 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): +link between this user and the configured LDAP providers: ```sql Identity Load (0.9ms) SELECT "identities".* FROM "identities" WHERE "identities"."user_id" = 20 AND (provider LIKE 'ldap%') LIMIT 1 @@ -334,7 +334,7 @@ Gitlab::Auth::Ldap::Person.find_by_uid('<uid>', adapter) ### Group memberships **(PREMIUM SELF)** -#### Membership(s) not granted +#### Memberships not granted Sometimes you may think a particular user should be added to a GitLab group via LDAP group sync, but for some reason it's not happening. You can check several @@ -348,7 +348,7 @@ things to debug the situation. 1. On the top bar, select **Menu > Admin**. 1. On the left sidebar, select **Overview > Users**. 1. Search for the user. - 1. Open the user by clicking their name. Do not click **Edit**. + 1. Open the user by selecting their name. Do not select **Edit**. 1. Select the **Identities** tab. There should be an LDAP identity with an LDAP DN as the 'Identifier'. If not, this user hasn't signed in with LDAP yet and must do so first. @@ -558,7 +558,7 @@ aren't blocked or unable to access their accounts. NOTE: The following script requires that any new accounts with the new -email address are removed first. This is because emails have to be unique in GitLab. +email address are removed first. Email addresses must be unique in GitLab. Go to the [rails console](#rails-console) and then run: |