Add latest changes from gitlab-org/gitlab@master

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