Add latest changes from gitlab-org/gitlab@13-4-stable-ee

3 files changed, 43 insertions, 13 deletions

diff --git a/doc/user/group/saml_sso/group_managed_accounts.md b/doc/user/group/saml_sso/group_managed_accounts.md
index 126970ebbb6..7497d036d31 100644
--- a/doc/user/group/saml_sso/group_managed_accounts.md
+++ b/doc/user/group/saml_sso/group_managed_accounts.md
@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Group Managed Accounts **(PREMIUM)**
 
 CAUTION: **Caution:**
-This [Closed Beta](https://about.gitlab.com/handbook/product/#closed-beta) feature is being re-evaluated in favor of a different
+This [Closed Beta](https://about.gitlab.com/handbook/product/gitlab-the-product/#sts=Closed%20Beta) feature is being re-evaluated in favor of a different
 [identity model](https://gitlab.com/gitlab-org/gitlab/-/issues/218631) that does not require separate accounts.
 We recommend that group administrators who haven't yet implemented this feature wait for
 the new solution.
@@ -76,7 +76,8 @@ This restriction also applies to projects forked from or to those groups.
 
 Groups with group-managed accounts can disallow forking of projects to destinations outside the group.
 To do so, enable the "Prohibit outer forks" option in **Settings > SAML SSO**.
-When enabled, projects within the group can only be forked to other destinations within the group (including its subgroups).
+When enabled **at the parent group level**, projects within the group can be forked
+only to other destinations within the group (including its subgroups).
 
 ## Credentials inventory for Group-managed accounts **(ULTIMATE)**
 
@@ -104,7 +105,7 @@ Since personal access tokens are the only token needed for programmatic access t
 
 ### Setting a limit
 
-Only a GitLab administrator or an owner of a group-managed account can set a limit. When this field is left empty, the [instance-level restriction](../../admin_area/settings/account_and_limit_settings.md#limiting-lifetime-of-personal-access-tokens-ultimate-only) on the lifetime of personal access tokens apply.
+Only a GitLab administrator or an owner of a group-managed account can set a limit. When this field is left empty, the [instance-level restriction](../../admin_area/settings/account_and_limit_settings.md#limiting-lifetime-of-personal-access-tokens) on the lifetime of personal access tokens apply.
 
 To set a limit on how long personal access tokens are valid for users in a group managed account:
 
diff --git a/doc/user/group/saml_sso/index.md b/doc/user/group/saml_sso/index.md
index f516f4080fa..57b9cc92c51 100644
--- a/doc/user/group/saml_sso/index.md
+++ b/doc/user/group/saml_sso/index.md
@@ -274,10 +274,10 @@ Group SAML on a self-managed instance is limited when compared to the recommende
 [instance-wide SAML](../../../integration/saml.md). The recommended solution allows you to take advantage of:
 
 - [LDAP compatibility](../../../administration/auth/ldap/index.md).
-- [LDAP Group Sync](../index.md#manage-group-memberships-via-ldap-starter-only).
-- [Required groups](../../../integration/saml.md#required-groups-starter-only).
-- [Admin groups](../../../integration/saml.md#admin-groups-starter-only).
-- [Auditor groups](../../../integration/saml.md#auditor-groups-starter-only).
+- [LDAP Group Sync](../index.md#manage-group-memberships-via-ldap).
+- [Required groups](../../../integration/saml.md#required-groups).
+- [Admin groups](../../../integration/saml.md#admin-groups).
+- [Auditor groups](../../../integration/saml.md#auditor-groups).
 
 ### Omnibus installations
 
@@ -361,7 +361,7 @@ Here are possible causes and solutions:
 
 Getting both of these errors at the same time suggests the NameID capitalization provided by the Identity Provider didn't exactly match the previous value for that user.
 
-This can be prevented by configuring the [NameID](#nameid) to return a consistent value. Fixing this for an individual user involves [unlinking SAML in the GitLab account](#unlinking-accounts), although this will cause group membership and Todos to be lost.
+This can be prevented by configuring the [NameID](#nameid) to return a consistent value. Fixing this for an individual user involves [unlinking SAML in the GitLab account](#unlinking-accounts), although this will cause group membership and to-dos to be lost.
 
 ### Message: "Request to link SAML account must be authorized"
 
@@ -377,7 +377,7 @@ Alternatively, when users need to [link SAML to their existing GitLab.com accoun
 
 | Cause                                                                                                                                                                                     | Solution                                                                                                                                                                                                                                           |
 |-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| As mentioned in the [NameID](#nameid) section, if the NameID changes for any user, the user can be locked out. This is a common problem when an email address is used as the identifier. | Follow the steps outlined in the ["SAML authentication failed: User has already been taken"](#message-saml-authentication-failed-user-has-already-been-taken) section. If many users are affected, we recommend that you use the appropriate API. |
+| As mentioned in the [NameID](#nameid) section, if the NameID changes for any user, the user can be locked out. This is a common problem when an email address is used as the identifier. | Follow the steps outlined in the ["SAML authentication failed: User has already been taken"](#message-saml-authentication-failed-user-has-already-been-taken) section. |
 
 ### I need to change my SAML app
 
diff --git a/doc/user/group/saml_sso/scim_setup.md b/doc/user/group/saml_sso/scim_setup.md
index 9a2bd2e8806..4f74e672392 100644
--- a/doc/user/group/saml_sso/scim_setup.md
+++ b/doc/user/group/saml_sso/scim_setup.md
@@ -159,7 +159,16 @@ application described above.
 
 ## User access and linking setup
 
-As long as [Group SAML](index.md) has been configured, prior to turning on sync, existing GitLab.com users can link to their accounts in one of the following ways, before synchronization is active:
+The following diagram is a general outline on what happens when you add users to your SCIM app:
+
+```mermaid
+graph TD
+  A[Add User to SCIM app] -->|IdP sends user info to GitLab| B(GitLab: Does the email exists?)
+  B -->|No| C[GitLab creates user with SCIM identity]
+  B -->|Yes| D[GitLab sends message back 'Email exists']
+```
+
+As long as [Group SAML](index.md) has been configured, existing GitLab.com users can link to their accounts in one of the following ways:
 
 - By updating their *primary* email address in their GitLab.com user account to match their identity provider's user profile email address.
 - By following these steps:
@@ -168,21 +177,41 @@ As long as [Group SAML](index.md) has been configured, prior to turning on sync,
   1. Click on the GitLab app in the identity provider's dashboard or visit the **GitLab single sign-on URL**.
   1. Click on the **Authorize** button.
 
+We recommend users do this prior to turning on sync, because while synchronization is active, there may be provisioning errors for existing users.
+
 New users and existing users on subsequent visits can access the group through the identify provider's dashboard or by visiting links directly.
 
 For role information, please see the [Group SAML page](index.md#user-access-and-management)
 
 ### Blocking access
 
-To rescind access to the group, we recommend removing the user from the identity
+To rescind access to the group, remove the user from the identity
 provider or users list for the specific app.
 
-Upon the next sync, the user will be deprovisioned, which means that the user will be removed from the group. The user account will not be deleted unless using [group managed accounts](group_managed_accounts.md).
+Upon the next sync, the user is deprovisioned, which means that the user is removed from the group.
+
+NOTE: **Note:**
+Deprovisioning does not delete the user account.
+
+```mermaid
+graph TD
+  A[Remove User from SCIM app] -->|IdP sends request to GitLab| B(GitLab: Is the user part of the group?)
+  B -->|No| C[Nothing to do]
+  B -->|Yes| D[GitLab removes user from GitLab group]
+```
 
 ## Troubleshooting
 
 This section contains possible solutions for problems you might encounter.
 
+### How come I can't add a user after I removed them?
+
+As outlined in the [Blocking access section](#blocking-access), when you remove a user, they are removed from the group. However, their account is not deleted.
+
+When the user is added back to the SCIM app, GitLab cannot create a new user because the user already exists.
+
+Solution: Have a user sign in directly to GitLab, then [manually link](#user-access-and-linking-setup) their account.
+
 ### Azure
 
 #### How do I verify my SCIM configuration is correct?
@@ -236,7 +265,7 @@ Alternatively, the [SCIM API](../../../api/scim.md#get-a-list-of-saml-users) can
 For example:
 
 ```shell
-curl 'https://example.gitlab.com/api/scim/v2/groups/GROUP_NAME/Users?startIndex=1"' --header "Authorization: Bearer <your_scim_token>" --header "Content-Type: application/scim+json"
+curl 'https://gitlab.example.com/api/scim/v2/groups/GROUP_NAME/Users?startIndex=1"' --header "Authorization: Bearer <your_scim_token>" --header "Content-Type: application/scim+json"
 ```
 
 To see how this compares to the value returned as the SAML NameId, you can have the user use a [SAML Tracer](index.md#saml-debugging-tools).