diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2023-12-04 15:12:44 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2023-12-04 15:12:44 +0300 |
commit | 157061839634d24bdb937316373f35bf1fb1f71e (patch) | |
tree | cfdf79f0a03d105c7cc2c66805e164f68d77d92c /doc/user | |
parent | 6974ffffd292657d8257826b2e09a0a8fff6c6a8 (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/user')
-rw-r--r-- | doc/user/group/saml_sso/troubleshooting_scim.md | 41 | ||||
-rw-r--r-- | doc/user/workspace/configuration.md | 7 | ||||
-rw-r--r-- | doc/user/workspace/gitlab_agent_configuration.md | 23 |
3 files changed, 56 insertions, 15 deletions
diff --git a/doc/user/group/saml_sso/troubleshooting_scim.md b/doc/user/group/saml_sso/troubleshooting_scim.md index 5140e121bfb..1a8a719f98b 100644 --- a/doc/user/group/saml_sso/troubleshooting_scim.md +++ b/doc/user/group/saml_sso/troubleshooting_scim.md @@ -127,6 +127,47 @@ For example, use these values as a definitive source on why an account was provi details. This information can help where an account was SCIM provisioned with details that do not match the SCIM app configuration. +## Member's email address is not linked error in SCIM log + +When you attempt to provision a SCIM user on GitLab.com, GitLab checks to see if +a user with that email address already exists. You might see the following error +when the: + +- User exists, but does not have a SAML identity linked. +- User exists, has a SAML identity, **and** has a SCIM identity that is set to `active: false`. + +```plaintext +The member's email address is not linked to a SAML account or has an inactive +SCIM identity. +``` + +This error message is returned with the status `412`. + +This might prevent the affected end user from accessing their account correctly. + +The first workaround is: + +1. Have the end user [link SAML to their existing GitLab.com account](index.md#link-saml-to-your-existing-gitlabcom-account). +1. After the user has done this, initiate a SCIM sync from your identity provider. +If the SCIM sync completes without the same error, GitLab has +successfully linked the SCIM identity to the existing user account, and the user +should now be able to sign in using SAML SSO. + +If the error persists, the user most likely already exists, has both a SAML and +SCIM identity, and a SCIM identity that is set to `active: false`. To resolve +this: + +1. Optional. If you did not save your SCIM token when you first configured SCIM, [generate a new token](scim_setup.md#configure-gitlab). If you generate a new SCIM token, you **must** update the token in your identity provider's SCIM configuration, or SCIM will stop working. +1. Locate your SCIM token. +1. Use the API to [get a single SCIM provisioned user](/ee/development/internal_api/index.md#get-a-single-scim-provisioned-user). +1. Check the returned information to make sure that: + - The user's identifier (`id`) and email match what your identity provider is sending. + - `active` is set to `false`. + If any of this information does not match, [contact GitLab Support](https://support.gitlab.com/). +1. Use the API to [update the SCIM provisioned user's `active` value to `true`](/ee/development/internal_api/index.md#update-a-single-scim-provisioned-user). +1. If the update returns a status code `204`, have the user attempt to sign in +using SAML SSO. + ## Azure Active Directory The following troubleshooting information is specifically for SCIM provisioned through Azure Active Directory. diff --git a/doc/user/workspace/configuration.md b/doc/user/workspace/configuration.md index a1308d04653..ae49b866bbd 100644 --- a/doc/user/workspace/configuration.md +++ b/doc/user/workspace/configuration.md @@ -30,12 +30,7 @@ which you can customize to meet the specific needs of each project. that controller accessible over a domain. For example, point `*.workspaces.example.dev` and `workspaces.example.dev` to the load balancer exposed by the Ingress controller. - [Install `gitlab-workspaces-proxy`](https://gitlab.com/gitlab-org/remote-development/gitlab-workspaces-proxy#installation-instructions). - - [Install the GitLab agent](../clusters/agent/install/index.md). -- Configure [remote development settings for the GitLab agent](gitlab_agent_configuration.md). - - You can use any agent defined under the root group of your project, - provided that remote development is properly configured for that agent. - + - [Install](../clusters/agent/install/index.md) and [configure](gitlab_agent_configuration.md) the GitLab agent. - You must have at least the Developer role in the root group. - In each project you want to use this feature for, create a [devfile](index.md#devfile): 1. On the left sidebar, select **Search or go to** and find your project. diff --git a/doc/user/workspace/gitlab_agent_configuration.md b/doc/user/workspace/gitlab_agent_configuration.md index d74014e9f1f..8f8ae397f5d 100644 --- a/doc/user/workspace/gitlab_agent_configuration.md +++ b/doc/user/workspace/gitlab_agent_configuration.md @@ -4,11 +4,16 @@ group: IDE info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# GitLab agent configuration +# GitLab agent configuration **(PREMIUM ALL)** + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/112397) in GitLab 15.11 [with a flag](../../administration/feature_flags.md) named `remote_development_feature_flag`. Disabled by default. +> - [Enabled on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/391543) in GitLab 16.0. +> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/136744) in GitLab 16.7. Feature flag `remote_development_feature_flag` removed. When you [set up a workspace](configuration.md#set-up-a-workspace), -you must configure remote development settings for the GitLab agent. -These settings are available in the agent configuration file under `remote_development`. +you must configure remote development for the GitLab agent. +The remote development settings are available in the agent +configuration file under `remote_development`. You can use any agent defined under the root group of your project, provided that remote development is properly configured for that agent. @@ -23,7 +28,7 @@ provided that remote development is properly configured for that agent. | [`network_policy`](#network_policy) | Firewall rules for workspaces | NOTE: -If any setting has an invalid value, all settings cannot be updated until you fix that value. +If a setting has an invalid value, it's not possible to update any setting until you fix that value. ### `enabled` @@ -109,12 +114,12 @@ Use this setting to define a list of IP CIDR ranges to allow as egress destinati Define egress rules when: -- The GitLab instance is available on a private IP. -- Workspace users must access a cloud resource available on a private IP. +- The GitLab instance is on a private IP range. +- Workspace users must access a cloud resource on a private IP range. Each element of the list defines an `allow` attribute with an optional `except` attribute. -The `allow` attribute defines an IP CIDR range to allow traffic from. -The `except` attribute lists IP CIDR ranges to exclude from the `allow` range. +`allow` defines an IP range to allow traffic from. +`except` lists IP ranges to exclude from the `allow` range. **Example configuration:** @@ -132,5 +137,5 @@ remote_development: In this example, traffic from the workspace is allowed if: -- The destination IP is any IP except `10.0.0.0/8`, `172.16.0.0/12`, or `192.168.0.0/16`. +- The destination IP is any range except `10.0.0.0/8`, `172.16.0.0/12`, or `192.168.0.0/16`. - The destination IP is `172.16.123.1/32`. |