Add latest changes from gitlab-org/gitlab@15-8-stable-eev15.8.0-rc42

10 files changed, 205 insertions, 37 deletions

diff --git a/doc/administration/geo/disaster_recovery/bring_primary_back.md b/doc/administration/geo/disaster_recovery/bring_primary_back.md
index dda2c5d34d3..fe05b52cec9 100644
--- a/doc/administration/geo/disaster_recovery/bring_primary_back.md
+++ b/doc/administration/geo/disaster_recovery/bring_primary_back.md
@@ -26,6 +26,16 @@ Alternatively, you can [set up a new **secondary** GitLab instance](../setup/ind
 To bring the former **primary** site up to date:
 
 1. SSH into the former **primary** site that has fallen behind.
+1. Remove `/etc/gitlab/gitlab-cluster.json` if it exists.
+
+   If the site to be re-added as a **secondary** site was promoted with the `gitlab-ctl geo promote` command, then it may contain a `/etc/gitlab/gitlab-cluster.json` file. For example during `gitlab-ctl reconfigure`, you may notice output like:
+
+   ```plaintext
+   The 'geo_primary_role' is defined in /etc/gitlab/gitlab-cluster.json as 'true' and overrides the setting in the /etc/gitlab/gitlab.rb
+   ```
+
+   If so, then `/etc/gitlab/gitlab-cluster.json` must be deleted from every Sidekiq, PostgreSQL, Gitaly, and Rails node in the site, to make `/etc/gitlab/gitlab.rb` the single source of truth again.
+
 1. Make sure all the services are up:
 
    ```shell
diff --git a/doc/administration/geo/disaster_recovery/index.md b/doc/administration/geo/disaster_recovery/index.md
index a78350d9dba..b6703e8a5fb 100644
--- a/doc/administration/geo/disaster_recovery/index.md
+++ b/doc/administration/geo/disaster_recovery/index.md
@@ -460,9 +460,9 @@ required:
 
 ### Step 4. (Optional) Updating the primary domain DNS record
 
-Updating the DNS records for the primary domain to point to the **secondary** site
-to prevent the need to update all references to the primary domain to the
-secondary domain, like changing Git remotes and API URLs.
+Update DNS records for the primary domain to point to the **secondary** site.
+This removes the need to update all references to the primary domain, for example
+changing Git remotes and API URLs.
 
 1. SSH into the **secondary** site and login as root:
 
@@ -479,6 +479,21 @@ secondary domain, like changing Git remotes and API URLs.
    external_url 'https://<new_external_url>'
    ```
 
+   If you provide GitLab with its certificate
+   [manually](https://docs.gitlab.com/omnibus/settings/ssl/index.html#configure-https-manually),
+   ensure:
+
+   - The new URL is one of the subject alternative names:
+
+     ```shell
+     /opt/gitlab/embedded/bin/openssl x509 -noout -dates -subject -issuer \
+         -nameopt multiline -ext subjectAltName -in /etc/gitlab/ssl/new-gitlab.new-example.com.crt
+     ```
+
+   - The certificate and key filenames match the new `external_url`,
+     or those filenames are
+     [specified in `/etc/gitlab/gitlab.rb`](https://docs.gitlab.com/omnibus/settings/ssl/index.html#change-the-default-ssl-certificate-location).
+
    NOTE:
    Changing `external_url` does not prevent access via the old secondary URL, as
    long as the secondary DNS records are still intact.
diff --git a/doc/administration/geo/index.md b/doc/administration/geo/index.md
index 68fd0c63e37..8728ab57bba 100644
--- a/doc/administration/geo/index.md
+++ b/doc/administration/geo/index.md
@@ -124,7 +124,9 @@ The following are required to run Geo:
 - Git 2.9 or later
 - Git-lfs 2.4.2 or later on the user side when using LFS
 - All sites must run [the same GitLab and PostgreSQL versions](setup/database.md#postgresql-replication).
-- If using different operating system versions between Geo sites, [check OS locale data compatibility](replication/troubleshooting.md#check-os-locale-data-compatibility) across Geo sites.
+  - If using different operating system versions between Geo sites,
+    [check OS locale data compatibility](replication/troubleshooting.md#check-os-locale-data-compatibility)
+    across Geo sites to avoid silent corruption of database indexes.
 
 Additionally, check the GitLab [minimum requirements](../../install/requirements.md),
 and use the latest version of GitLab for a better experience.
@@ -163,15 +165,6 @@ To update the internal URL of the primary Geo site:
 1. Select **Edit** on the primary site.
 1. Change the **Internal URL**, then select **Save changes**.
 
-### LDAP
-
-We recommend that if you use LDAP on your **primary** site, you also set up secondary LDAP servers on each **secondary** site. Otherwise, users are unable to perform Git operations over HTTP(s) on the **secondary** site using HTTP Basic Authentication. However, Git via SSH and personal access tokens still works.
-
-NOTE:
-It is possible for all **secondary** sites to share an LDAP server, but additional latency can be an issue. Also, consider what LDAP server is available in a [disaster recovery](disaster_recovery/index.md) scenario if a **secondary** site is promoted to be a **primary** site.
-
-Check for instructions on how to set up replication in your LDAP service. Instructions are different depending on the software or service used. For example, OpenLDAP provides [these instructions](https://www.openldap.org/doc/admin24/replication.html).
-
 ### Geo Tracking Database
 
 The tracking database instance is used as metadata to control what needs to be updated on the disk of the local instance. For example:
@@ -224,6 +217,8 @@ An [epic exists](https://gitlab.com/groups/gitlab-org/-/epics/4623) to fix this
 The only way to view designs replication data for a particular secondary site is to visit that secondary site directly. For example, `https://<IP of your secondary site>/admin/geo/replication/designs`.
 An [epic exists](https://gitlab.com/groups/gitlab-org/-/epics/4624) to fix this limitation.
 
+Keep in mind that mentioned URLs don't work when [Admin Mode](../../user/admin_area/settings/sign_in_restrictions.md#admin-mode) is enabled.
+
 ## Setup instructions
 
 For setup instructions, see [Setting up Geo](setup/index.md).
@@ -292,6 +287,14 @@ For more information on how to replicate the Container Registry, see [Container
 
 For more information on using Geo proxying on secondary sites, see [Geo proxying for secondary sites](secondary_proxy/index.md).
 
+### Single Sign On (SSO)
+
+For more information on configuring Single Sign-On (SSO), see [Geo with Single Sign-On (SSO)](replication/single_sign_on.md).
+
+#### LDAP
+
+For more information on configuring LDAP, see [Geo with Single Sign-On (SSO) > LDAP](replication/single_sign_on.md#ldap).
+
 ### Security Review
 
 For more information on Geo security, see [Geo security review](replication/security_review.md).
diff --git a/doc/administration/geo/replication/configuration.md b/doc/administration/geo/replication/configuration.md
index d625b2a0324..79a3f65377b 100644
--- a/doc/administration/geo/replication/configuration.md
+++ b/doc/administration/geo/replication/configuration.md
@@ -104,7 +104,7 @@ keys must be manually replicated to the **secondary** site.
 1. Make a backup of any existing SSH host keys:
 
    ```shell
-   find /etc/ssh -iname ssh_host_* -exec cp {} {}.backup.`date +%F` \;
+   find /etc/ssh -iname 'ssh_host_*' -exec cp {} {}.backup.`date +%F` \;
    ```
 
 1. Copy OpenSSH host keys from the **primary** site:
diff --git a/doc/administration/geo/replication/datatypes.md b/doc/administration/geo/replication/datatypes.md
index 52cd64b8f33..26acab510cf 100644
--- a/doc/administration/geo/replication/datatypes.md
+++ b/doc/administration/geo/replication/datatypes.md
@@ -64,7 +64,7 @@ verification methods:
 | Blobs    | Alert Metric Images _(file system)_             | Geo with API                          | SHA256 checksum        |
 | Blobs    | Alert Metric Images _(object storage)_          | Geo with API/Managed (*2*)            | _Not implemented_      |
 | Blobs    | Dependency Proxy Images_(file system)_          | Geo with API                          | SHA256 checksum        |
-| Blobs    | Dependency Proxy Images _(object_storage)_      | Geo with API/managed (*2*)            | _Not implemented_      |
+| Blobs    | Dependency Proxy Images _(object storage)_      | Geo with API/managed (*2*)            | _Not implemented_      |
 
 - (*1*): Redis replication can be used as part of HA with Redis sentinel. It's not used between Geo sites.
 - (*2*): Object storage replication can be performed by Geo or by your object storage provider/appliance
diff --git a/doc/administration/geo/replication/location_aware_git_url.md b/doc/administration/geo/replication/location_aware_git_url.md
index 460de5f3232..4a3f9c86041 100644
--- a/doc/administration/geo/replication/location_aware_git_url.md
+++ b/doc/administration/geo/replication/location_aware_git_url.md
@@ -57,7 +57,7 @@ routing configurations.
 
    ![Traffic policies](img/single_git_traffic_policies.png)
 
-1. Select the **Create traffic policy** button.
+1. Select **Create traffic policy**.
 
    ![Name policy](img/single_git_name_policy.png)
 
diff --git a/doc/administration/geo/replication/remove_geo_site.md b/doc/administration/geo/replication/remove_geo_site.md
index 4b9f31dc08c..9d92652daf4 100644
--- a/doc/administration/geo/replication/remove_geo_site.md
+++ b/doc/administration/geo/replication/remove_geo_site.md
@@ -11,7 +11,7 @@ type: howto
 
 1. On the top bar, select **Main menu > Admin**.
 1. On the left sidebar, select **Geo > Nodes**.
-1. Select the **Remove** button for the **secondary** site you want to remove.
+1. For the **secondary** site you want to remove, select **Remove**.
 1. Confirm by selecting **Remove** when the prompt appears.
 
 After the **secondary** site is removed from the Geo administration page, you must
@@ -25,6 +25,9 @@ stop and uninstall this site. For each node on your secondary Geo site:
 
 1. Uninstall GitLab:
 
+   NOTE:
+   If GitLab data has to be cleaned from the instance as well, see how to [uninstall the Linux package and all its data](https://docs.gitlab.com/omnibus/installation/#uninstall-the-linux-package-omnibus).
+
    ```shell
    # Stop gitlab and remove its supervision process
    sudo gitlab-ctl uninstall
diff --git a/doc/administration/geo/replication/single_sign_on.md b/doc/administration/geo/replication/single_sign_on.md
new file mode 100644
index 00000000000..fc2f23552db
--- /dev/null
+++ b/doc/administration/geo/replication/single_sign_on.md
@@ -0,0 +1,122 @@
+---
+stage: Systems
+group: Geo
+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
+type: howto
+---
+
+# Geo with Single Sign On (SSO) **(PREMIUM SELF)**
+
+This documentation only discusses Geo-specific SSO considerations and configuration. For more information on general authentication, see [GitLab authentication and authorization](../../auth/index.md).
+
+## Configuring instance-wide SAML
+
+### Prerequisites
+
+[Instance-wide SAML](../../../integration/saml.md) must be working on your primary Geo site.
+
+You only configure SAML on the primary site. Configuring `gitlab_rails['omniauth_providers']` in `gitlab.rb` in a secondary site has no effect.
+
+### Determine the type of URL your secondary site uses
+
+How you configure instance-wide SAML differs depending on your secondary site configuration. Determine if your secondary site uses a:
+
+- [Unified URL](../secondary_proxy/index.md#set-up-a-unified-url-for-geo-sites), meaning the `external_url` exactly matches the `external_url` of the primary site.
+- [Separate URL](../secondary_proxy/index.md#geo-proxying-with-separate-urls) with proxying enabled. Proxying is enabled by default in GitLab 15.1 and later.
+- [Separate URL](../secondary_proxy/index.md#geo-proxying-with-separate-urls) with proxying disabled.
+
+### SAML with Unified URL
+
+If you have configured SAML on the primary site correctly, then it should work on the secondary site without additional configuration.
+
+### SAML with separate URL with proxying enabled
+
+If a secondary site uses a different `external_url` to the primary site, then configure your SAML Identity Provider (IdP) to allow the secondary site's SAML callback URL. For example, to configure Okta:
+
+1. [Sign in to Okta](https://www.okta.com/login/).
+1. Go to **Okta Admin Dashboard** > **Applications** > **Your App Name** > **General**.
+1. In **SAML Settings**, select **Edit**.
+1. In **General Settings**, select **Next** to go to **SAML Settings**.
+1. In **SAML Settings > General**, make sure the **Single sign-on URL** is your primary site's SAML callback URL. For example, `https://gitlab-primary.example.com/users/auth/saml/callback`. If it is not, enter your primary site's SAML callback URL into this field.
+1. Select **Show Advanced Settings**.
+1. In **Other Requestable SSO URLs**, enter your secondary site's SAML callback URL. For example, `https://gitlab-secondary.example.com/users/auth/saml/callback`. You can set **Index** to anything.
+1. Select **Next** and then **Finish**.
+
+You must not specify `assertion_consumer_service_url` in the SAML provider configuration in `gitlab_rails['omniauth_providers']` in `gitlab.rb` of the primary site. For example:
+
+```ruby
+gitlab_rails['omniauth_providers'] = [
+  {
+    name: "saml",
+    label: "Okta", # optional label for login button, defaults to "Saml"
+    args: {
+      idp_cert_fingerprint: "B5:AD:AA:9E:3C:05:68:AD:3B:78:ED:31:99:96:96:43:9E:6D:79:96",
+      idp_sso_target_url: "https://<dev-account>.okta.com/app/dev-account_gitlabprimary_1/exk7k2gft2VFpVFXa5d1/sso/saml",
+      issuer: "https://<gitlab-primary>",
+      name_identifier_format: "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
+    }
+  }
+]
+```
+
+This configuration causes:
+
+- Both your sites to use `/users/auth/saml/callback` as their assertion consumer service (ACS) URL.
+- The URL's host to be set to the corresponding site's host.
+
+You can check this by visiting each site's `/users/auth/saml/metadata` path. For example, visiting `https://gitlab-primary.example.com/users/auth/saml/metadata` may respond with:
+
+```xml
+<md:EntityDescriptor ID="_b9e00d84-d34e-4e3d-95de-122e3c361617" entityID="https://gitlab-primary.example.com"
+  xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
+  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
+  <md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
+    <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
+    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://gitlab-primary.example.com/users/auth/saml/callback"    index="0" isDefault="true"/>
+    <md:AttributeConsumingService index="1" isDefault="true">
+      <md:ServiceName xml:lang="en">Required attributes</md:ServiceName>
+      <md:RequestedAttribute FriendlyName="Email address" Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" isRequired="false"/>
+      <md:RequestedAttribute FriendlyName="Full name" Name="name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" isRequired="false"/>
+      <md:RequestedAttribute FriendlyName="Given name" Name="first_name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" isRequired="false"/>
+      <md:RequestedAttribute FriendlyName="Family name" Name="last_name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" isRequired="false"/>
+    </md:AttributeConsumingService>
+  </md:SPSSODescriptor>
+</md:EntityDescriptor>
+```
+
+Visiting `https://gitlab-secondary.example.com/users/auth/saml/metadata` may respond with:
+
+```xml
+<md:EntityDescriptor ID="_bf71eb57-7490-4024-bfe2-54cec716d4bf" entityID="https://gitlab-primary.example.com"
+  xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
+  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
+  <md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
+    <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
+    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://gitlab-secondary.example.com/users/auth/saml/callback"    index="0" isDefault="true"/>
+    <md:AttributeConsumingService index="1" isDefault="true">
+      <md:ServiceName xml:lang="en">Required attributes</md:ServiceName>
+      <md:RequestedAttribute FriendlyName="Email address" Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" isRequired="false"/>
+      <md:RequestedAttribute FriendlyName="Full name" Name="name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" isRequired="false"/>
+      <md:RequestedAttribute FriendlyName="Given name" Name="first_name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" isRequired="false"/>
+      <md:RequestedAttribute FriendlyName="Family name" Name="last_name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" isRequired="false"/>
+    </md:AttributeConsumingService>
+  </md:SPSSODescriptor>
+</md:EntityDescriptor>
+```
+
+The `Location` attribute of the `md:AssertionConsumerService` field points to `gitlab-secondary.example.com`.
+
+After configuring your SAML IdP to allow the secondary site's SAML callback URL, you should be able to sign in with SAML on your primary site as well as your secondary site.
+
+### SAML with separate URL with proxying disabled
+
+If you have configured SAML on the primary site correctly, then it should work on the secondary site without additional configuration.
+
+## LDAP
+
+If you use LDAP on your **primary** site, you should also set up secondary LDAP servers on each **secondary** site. Otherwise, users cannot perform Git operations over HTTP(s) on the **secondary** site using HTTP basic authentication. However, users can still use Git with SSH and personal access tokens.
+
+NOTE:
+It is possible for all **secondary** sites to share an LDAP server, but additional latency can be an issue. Also, consider what LDAP server is available in a [disaster recovery](../disaster_recovery/index.md) scenario if a **secondary** site is promoted to be a **primary** site.
+
+Check your LDAP service documentation for instructions on how to set up replication in your LDAP service. The process differs depending on the software or service used. For example, OpenLDAP provides this [replication documentation](https://www.openldap.org/doc/admin24/replication.html).
diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md
index 1dcced781ce..2f2759d7339 100644
--- a/doc/administration/geo/replication/troubleshooting.md
+++ b/doc/administration/geo/replication/troubleshooting.md
@@ -1100,6 +1100,10 @@ On the **primary** site:
 1. Ensure the **URL** field matches the value found in `/etc/gitlab/gitlab.rb`
    in `external_url "https://gitlab.example.com"` on the **Rails nodes of the secondary** site.
 
+### Authenticating with SAML on the secondary site always lands on the primary site
+
+This [problem is usually encountered when upgrading to GitLab 15.1](version_specific_upgrades.md#upgrading-to-151). To fix this problem, see [configuring instance-wide SAML in Geo with Single Sign-On](single_sign_on.md#configuring-instance-wide-saml).
+
 ## Fixing common errors
 
 This section documents common error messages reported in the Admin Area on the web interface, and how to fix them.
@@ -1313,6 +1317,18 @@ registry = Geo::PackageFileRegistry.find(registry_id)
 registry.replicator.send(:download)
 ```
 
+#### Find registry records of blobs that failed to sync
+
+```ruby
+Geo::PackageFileRegistry.failed
+```
+
+#### Find registry records of blobs that are missing on the primary site
+
+```ruby
+Geo::PackageFileRegistry.where(last_sync_failure: 'The file is missing on the Geo primary site')
+```
+
 #### Verify package files on the secondary manually
 
 This iterates over all package files on the secondary, looking at the
@@ -1340,7 +1356,7 @@ status.keys.each {|key| puts "#{key} count: #{status[key].count}"}
 status
 ```
 
-### Reverify all uploads (or any SSF data type which is verified)
+#### Reverify all uploads (or any SSF data type which is verified)
 
 1. SSH into a GitLab Rails node in the primary Geo site.
 1. Open [Rails console](../../../administration/operations/rails_console.md#starting-a-rails-console-session).
@@ -1396,21 +1412,6 @@ registry = Geo::SnippetRepositoryRegistry.find(registry_id)
 registry.replicator.send(:sync_repository)
 ```
 
-### Find failed artifacts
-
-[Start a Rails console session](../../../administration/operations/rails_console.md#starting-a-rails-console-session)
-to run the following commands:
-
-```ruby
-Geo::JobArtifactRegistry.failed
-```
-
-#### Find `ID` of synced artifacts that are missing on primary
-
-```ruby
-Geo::JobArtifactRegistry.synced.missing_on_primary.pluck(:artifact_id)
-```
-
 ### Project or project wiki repositories
 
 #### Find repository verification failures
@@ -1535,9 +1536,12 @@ If the above steps are **not successful**, proceed through the next steps:
 
 ## Check OS locale data compatibility
 
-If different operating systems or different operating system versions are deployed across Geo sites, we recommend that you perform a locale data compatibility check setting up Geo.
+If different operating systems or different operating system versions are deployed across Geo sites, you should perform a locale data compatibility check before setting up Geo.
 
-Geo uses PostgreSQL and Streaming Replication to replicate data across Geo sites. PostgreSQL uses locale data provided by the operating system’s C library for sorting text. If the locale data in the C library is incompatible across Geo sites, erroneous query results that lead to [incorrect behavior on secondary sites](https://gitlab.com/gitlab-org/gitlab/-/issues/360723). See [here](https://wiki.postgresql.org/wiki/Locale_data_changes) for more details.
+Geo uses PostgreSQL and Streaming Replication to replicate data across Geo sites. PostgreSQL uses locale data provided by the operating system's C library for sorting text. If the locale data in the C library is incompatible across Geo sites, erroneous query results that lead to [incorrect behavior on secondary sites](https://gitlab.com/gitlab-org/gitlab/-/issues/360723).
+
+For example, Ubuntu 18.04 (and earlier) and RHEL/Centos7 (and earlier) are incompatible with their later releases.
+See the [PostgreSQL wiki for more details](https://wiki.postgresql.org/wiki/Locale_data_changes).
 
 On all hosts running PostgreSQL, across all Geo sites, run the following shell command:
 
@@ -1561,4 +1565,8 @@ or the reverse order:
 
 If the output is identical on all hosts, then they running compatible versions of locale data.
 
-If the output differs on some hosts, then PostgreSQL replication will not work properly. We advise that you select operating system versions that are compatible.
+If the output differs on some hosts, PostgreSQL replication does not work properly: indexes are corrupted on the database replicas. You should select operating system versions that are compatible.
+
+A full index rebuild is required if the on-disk data is transferred 'at rest' to an operating system with an incompatible locale, or through replication.
+
+This check is also required when using a mixture of GitLab deployments. The locale might be different between an Linux package install, a GitLab Docker container, a Helm chart deployment, or external database services.
diff --git a/doc/administration/geo/replication/version_specific_upgrades.md b/doc/administration/geo/replication/version_specific_upgrades.md
index d981656f748..aa8e5d77f67 100644
--- a/doc/administration/geo/replication/version_specific_upgrades.md
+++ b/doc/administration/geo/replication/version_specific_upgrades.md
@@ -6,6 +6,13 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Version-specific upgrade instructions **(PREMIUM SELF)**
 
+NOTE:
+We're in the process of merging all the version-specific upgrade information
+into a single page. See [epic 9581](https://gitlab.com/groups/gitlab-org/-/epics/9581)
+for more information. For the time being, visit the
+[general upgrade page](../../../update/index.md)
+for the newest Geo version-specific upgrade instructions.
+
 Review this page for upgrade instructions for your version. These steps
 accompany the [general steps](upgrading_the_geo_sites.md#general-upgrade-steps)
 for upgrading Geo sites.
@@ -14,7 +21,7 @@ for upgrading Geo sites.
 
 [Geo proxying](../secondary_proxy/index.md) was [enabled by default for different URLs](https://gitlab.com/gitlab-org/gitlab/-/issues/346112) in 15.1. This may be a breaking change. If needed, you may [disable Geo proxying](../secondary_proxy/index.md#disable-geo-proxying).
 
-If you are using SAML with different URLs, there is a [known issue which requires proxying to be disabled](https://gitlab.com/gitlab-org/gitlab/-/issues/377372).
+If you are using SAML with different URLs, you must modify your SAML configuration and your Identity Provider configuration. For more information, see the [Geo with Single Sign-On (SSO) documentation](single_sign_on.md).
 
 ## Upgrading to 14.9