Fehlerbehebung bei der Identitätsföderation von Arbeitslasten

Auf dieser Seite wird beschrieben, wie Sie häufige Probleme mit der Workforce Identity-Föderation beheben.

IdP-Antwort prüfen

In diesem Abschnitt wird beschrieben, wie Sie die Antwort Ihres Identitätsanbieters (IdP) prüfen, um die in diesem Dokument aufgeführten Probleme zu beheben.

Browserbasierte Anmeldung

Wenn Sie die von Ihrem IdP zurückgegebene Antwort prüfen möchten, generieren Sie mit einem Tool Ihrer Wahl eine HAR-Datei. Sie können beispielsweise das HAR-Analysetool in der Google Admin Toolbox verwenden. Dort finden Sie eine Anleitung zum Erstellen einer HAR-Datei sowie Tools zum Hochladen und Analysieren der Datei.

Wichtig: Wenn Sie die HAR-Datei von Ihren Nutzern anfordern, bitten Sie sie, vor dem Senden alle personenidentifizierbaren Daten (PII) und Cookies aus der HAR-Datei zu bereinigen.

SAML

So prüfen Sie die SAML-IdP-Antwort:

1. Suchen Sie in der HAR-Datei nach dem Wert des Anfrageparameters SAMLResponse, der für die URL mit dem Pfad /signin-callback protokolliert wird.
2. Decodieren Sie das Tool mit einem Tool Ihrer Wahl, z. B. Google Admin Toolbox Encode/Decode.

OIDC

So prüfen Sie die OIDC-IdP-Antwort: Dieser Ansatz funktioniert nicht mit dem Code-Ablauf.

1. Suchen Sie in der HAR-Datei nach dem Anfrageparameter id_token, der für eine URL mit dem Pfad /signin-callback protokolliert wird.
2. Decodiere es mit einem JWT-Debugging-Tool deiner Wahl.

gcloud-CLI

Wenn Sie die Antwort Ihres IdP bei Verwendung der gcloud CLI prüfen möchten, kopieren Sie den Inhalt der Datei, die Sie beim Ausführen des Befehls gcloud iam workforce-pools create-cred-config im Flag --credential-source-file übergeben haben, und führen Sie dann die folgenden Schritte aus:

SAML

Decodieren Sie die Antwort des SAML-IdP mit einem Tool Ihrer Wahl. Sie können beispielsweise Google Admin Toolbox Encode/Decode verwenden.

OIDC

Decodieren Sie die OIDC-IdP-Antwort mit einem JWT-Debugging-Tool Ihrer Wahl.

Logs prüfen

Um festzustellen, ob Google Cloud mit Ihrem IdP kommuniziert, und um Transaktionsinformationen zu prüfen, können Sie die Cloud-Audit-Logs einsehen.

Beispiel-Audit-Logs

Fehler bei der Personalpool- und Anbieterverwaltung

Dieser Abschnitt enthält Vorschläge zur Behebung häufiger Fehler bei der Verwaltung von Pools und Anbietern.

Allgemeine Fehler bei der Attributzuordnung

So beheben Sie Probleme mit der Attributzuordnung von Workforce Identity-Poolanbietern:

• Sehen Sie sich die Attribute (auch als Anforderungen bezeichnet) in Ihrer IdP-Konfiguration an. Prüfen Sie, wie Ihre Attributzuordnungen IdP-Attribute in Google Cloud-Attribute umwandeln und wie Ihre Bedingungen diese Attribute auswerten, um den Zugriff in der Google Cloud -Konsole zuzulassen oder zu verweigern.

  1. Sie benötigen die Rolle IAM Workforce Pool Editor (roles/iam.workforcePoolEditor).
  2. Wenn Sie den browserbasierten Anmeldevorgang für die Workforce Identity-Föderation aktivieren möchten, fügen Sie https://auth.cloud.google/signin-callback/locations/global/workforcePools/POOL_ID/providers/PROVIDER_ID der Liste der zulässigen Weiterleitungs-URIs Ihres Identitätsanbieters hinzu.

  3. Rufen Sie in der Google Cloud Console Workforce Identity-Pools auf.

     Zu Workforce Identity-Pools
  4. Klicken Sie in der Liste der Pools auf den Namen des Pools, den Sie prüfen möchten.
  5. Klicken Sie auf der Seite Workforce-Pool-Details auf den Namen des IdP, den Sie bestätigen möchten.
  6. Klicken Sie auf der Seite Provider Details (Details zum Anbieter) auf Debug IdP token (IdP-Token debuggen).
  7. Melden Sie sich im Dialogfeld Sign in (Anmelden) als Testnutzer bei Ihrem IdP an.

  Auf der Seite Anbieterattribute validieren werden die zugeordneten Attribute und das Ergebnis Ihrer Attributbedingung angezeigt.

  Im Bereich Zugeordnete Attribute aus Ihrem IdP-Token sehen Sie, wie Google-Attribute wie google.subject basierend auf Ihrer Zuordnungskonfiguration aus dem Token Ihres Identitätsanbieters (IdP) übernommen werden. Wenn eine Zuordnung falsch ist, wird ein Fehlersymbol angezeigt.

  Im Bereich Attributbedingung wird das boolesche Ergebnis Ihrer Bedingung angezeigt. Wenn die Bedingung false ergibt, wird die Anmeldung blockiert.

  Wenn Sie das vollständige Assertion-Token ansehen möchten, klicken Sie auf Vollständiges Token ansehen. Hier wird das Roh-JSON-Objekt von Ihrem IdP angezeigt. Verweisen Sie in Ihren Zuordnungen mit dem Format assertion.PROPERTY_NAME auf ein Attribut der obersten Ebene.

  So beheben Sie Fehler:

  1. Klicken Sie auf der Seite Anbieterattribute bestätigen auf  Bearbeiten.
  2. Nehmen Sie die erforderlichen Änderungen vor.
  3. Wenn Sie einen neuen Test starten und die aktualisierten Ergebnisse sehen möchten, klicken Sie auf Token speichern und neu abrufen.

• Prüfen Sie die von Ihrem IdP generierten Tokens. Informationen zum Generieren eines Tokens von Ihrem IdP finden Sie in der Dokumentation des IdP.

• Detaillierte Audit-Logs zur Workforce Identity-Föderation in Cloud-Audit-Logs ansehen.

Bei der detaillierten Audit-Protokollierung werden Authentifizierungs- und Autorisierungsfehler sowie Claims protokolliert, die von der Workforce Identity-Föderation empfangen wurden.

Sie können das detaillierte Audit-Logging aktivieren, wenn Sie Ihren Workforce Identity-Pool-Anbieter erstellen. Wenn Sie detaillierte Audit-Logs aktivieren möchten, fügen Sie beim Erstellen des Workforce Identity-Poolanbieters das Flag --detailed-audit-logging hinzu.

Berechtigung verweigert

Dieser Fehler tritt auf, wenn der Nutzer, der versucht, eine Workforce Identity-Föderation zu konfigurieren, nicht die Rolle „IAM Workforce Pool Admin“ (roles/iam.workforcePoolAdmin) hat.

INVALID_ARGUMENT: Fehlende OIDC-Webkonfiguration für Einmalanmeldung (SSO)

Der folgende Fehler tritt auf, wenn die Felder web-sso-response-type und web-sso-assertion-claims-behavior beim Erstellen eines OIDC-Workforce Identity-Poolanbieters nicht festgelegt werden:

ERROR: (gcloud.iam.workforce-pools.providers.create-oidc) INVALID_ARGUMENT: Missing OIDC web single sign-on config.

Um diesen Fehler zu beheben, folgen Sie der Anleitung im Abschnitt Anbieter erstellen und legen Sie dabei die Felder beim Erstellen des OIDC-Workforce Identity-Poolanbieters korrekt fest.

Ratenbegrenzung überschritten. Versuchen Sie es später noch einmal.

Dieser Fehler tritt auf, wenn Sie Ihr Kontingentlimit für Workforce-Ressourcenpools erreicht haben. Wenden Sie sich an Ihren Google Cloud Kundenbetreuer, um eine Kontingenterhöhung anzufordern.

Anmeldefehler

Dieser Abschnitt enthält Vorschläge zur Behebung häufiger Fehler, die bei der Anmeldung durch einen Nutzer einer Mitarbeiteridentitätsföderation auftreten können.

Häufige Anmeldefehler

Die angegebenen Anmeldedaten werden von der Attributbedingung abgelehnt

Dieser Fehler tritt auf, wenn die Attributbedingung, die für den Anbieter des Mitarbeiteridentitäts-Pools festgelegt ist, nicht erfüllt wurde.

Betrachten Sie beispielsweise die folgende Attributbedingung:

SAML

'gcp-users' in assertion.attributes.groups

OIDC

'gcp-users' in assertion.groups

In diesem Fall wird der Fehler angezeigt, wenn die Liste der Gruppen, die von Ihrem IdP im Attribut groups gesendet wurden, nicht gcp-users enthält.

Führen Sie folgende Schritte aus, um diesen Fehler zu beheben:

1. Beschreiben Sie den Anbieter, mit dem Sie sich angemeldet haben, und prüfen Sie, ob attributeCondition korrekt ist. Informationen zu Vorgängen, die in Bedingungen unterstützt werden, finden Sie in der Sprachdefinition.

2. Führen Sie die Schritte unter IdP-Antwort prüfen aus, um die vom IdP zurückgegebenen Attribute zu sehen und zu bestätigen, ob die Attributbedingung korrekt formatiert und genau ist.

3. Melden Sie sich in der Admin-Konsole Ihres IdP an und prüfen Sie, ob die in der Attributbedingung referenzierten IdP-Attribute richtig eingerichtet sind. Sehen Sie bei Bedarf in der Dokumentation Ihres IdP nach.

Das zugeordnete Attribut muss vom Typ STRING sein.

Dieser Fehler tritt bei einem Anbieter von SAML-Workforce Identity-Pools auf, wenn das in der Fehlermeldung angegebene Attribut ein einwertiger STRING ist, aber einer Liste in der Attributzuordnung zugeordnet ist:

Betrachten Sie beispielsweise einen Anbieter von SAML-Workforce Identity-Pools, der die Attributzuordnung attribute.role=assertion.attributes.userRole hat. In einer SAML-Assertion kann ein Attribute mehrere AttributeValue-Tags haben, wie im folgenden Beispiel gezeigt. Daher werden alle SAML-Attribute als Listen betrachtet, sodass assertion.attributes.userRole eine Liste ist.

<saml:Attribute Name="userRole">
    <saml:AttributeValue>
      security-admin
    </saml:AttributeValue>
    <saml:AttributeValue>
      user
    </saml:AttributeValue>
</saml:Attribute>

In diesem Beispiel wird möglicherweise der folgende Fehler angezeigt:

The mapped attribute 'attribute.role' must be of type STRING

So beheben Sie das Problem:

1. Beschreiben Sie den Anbieter, mit dem Sie sich angemeldet haben, und ermitteln Sie das IdP-Attribut, das in attributeMapping festgelegt ist. Vergleichen Sie das Attribut mit dem Attribut in der Fehlermeldung. Im vorherigen Beispiel wird ein IdP-Attribut mit dem Namen userRole dem Attribut role zugeordnet. Das Attribut role ist im obigen Fehlerbeispiel enthalten.

2. Beachten Sie beim Aktualisieren der Attributzuordnung Folgendes:

   Hinweis :Nur google.groups akzeptiert eine Liste.

   • Wenn das Attribut, das den Fehler verursacht, eine Liste von Werten enthält, suchen Sie nach einem alternativen, stabilen Attribut mit String-Werten. Aktualisieren Sie dann die Attributzuordnung, um sie zu verwenden, indem Sie auf das erste Element verweisen. Wenn im vorherigen Beispiel myRole als alternatives Attribut mit einem einzelnen Wert des IdP identifiziert wurde, sieht die Attributzuordnung so aus:

     attribute.role=assertion.attributes.myRole[0]
     

   • Wenn das Attribut bekanntermaßen nur einen Wert hat, können Sie die Attributzuordnung so aktualisieren, dass das erste Element aus der Liste verwendet wird. Wenn userRole im vorherigen Beispiel nur eine Rolle enthält, können Sie die folgende Zuordnung verwenden:

     attribute.role=assertion.attributes.userRole[0]
     

   • Informationen zum Ableiten eines einwertigen stabilen Bezeichners aus der Liste finden Sie unter Sprachdefinition. Aktualisieren Sie die Attributzuordnung entsprechend.

Im Abschnitt IdP-Antwort prüfen finden Sie die vom IdP zurückgegebene Antwort.

Aus den angegebenen Anmeldedaten konnte kein Wert für google.subject abgerufen werden.

Dieser Fehler tritt auf, wenn die erforderliche Anforderung google.subject nicht mithilfe der Attributzuordnung zugeordnet werden konnte, die Sie in der Konfiguration des Anbieters des Workforce Identity-Pools festgelegt haben.

Führen Sie folgende Schritte aus, um diesen Fehler zu beheben:

1. Beschreiben Sie den Anbieter und prüfen Sie attributeMapping. Ermitteln Sie die Zuordnung, die für google.subject konfiguriert ist. Wenn die Zuordnung nicht korrekt ist, aktualisieren Sie den Anbieter des Workforce Identity-Pools.

2. Im Abschnitt IdP-Antwort prüfen finden Sie die vom IdP zurückgegebene Antwort. Prüfen Sie den Wert des Attributs aus der IdP-Antwort, das in Ihren Attributzuordnungen google.subject zugeordnet ist.

   Wenn der Wert leer oder falsch ist, melden Sie sich in der Admin-Konsole Ihres IdP an und prüfen Sie die konfigurierten Attribute. Prüfen Sie, ob für die Attribute entsprechende Daten in Ihrem IdP vorhanden sind. Aktualisieren Sie die IdP-Konfiguration, um die Attribute oder Nutzerinformationen entsprechend zu korrigieren.

3. Versuchen Sie noch einmal, sich anzumelden.

Die Größe der zugeordneten Attribute überschreitet das Limit

Der folgende Fehler tritt auf, wenn ein Verbundnutzer versucht, sich anzumelden:

The size of the entire mapped attributes exceeds the 16 KB limit.

Bitten Sie Ihren IdP-Administrator, die Anzahl der Attribute zu reduzieren, die Ihr IdP ausgibt, um dieses Problem zu beheben. Ihr IdP muss nur Attribute ausgeben, die zum Föderieren von Nutzern mit Google Clouderforderlich sind. Weitere Informationen zu den Einschränkungen für die Attributzuordnung finden Sie unter Attributzuordnungen.

Wenn Ihr Identitätsanbieter beispielsweise eine große Anzahl von google.groups ausgibt, die zugeordnete Attribute in Ihrem Anbieter des Workforce Identity-Pools sind, kann ein Anmeldeversuch fehlschlagen. Bitten Sie Ihren Administrator, die Anzahl der Gruppen einzuschränken, die von Ihrem IdP ausgegeben werden.

Die Anzahl der Gruppen überschreitet das Limit.

Der folgende Fehler tritt auf, wenn ein Verbundnutzer versucht, sich anzumelden:

The current count of GROUPS_COUNT mapped attribute google.groups exceeds the GROUPS_COUNT_LIMIT count limit. Either modify your attribute mapping or the incoming assertion to produce a mapped attribute that has fewer than GROUPS_COUNT_LIMIT groups.

Dieser Fehler enthält die folgenden Werte:

• GROUPS_COUNT: Die Anzahl der Gruppen, die vom IdP ausgegeben werden.

• GROUPS_COUNT_LIMIT:das Kontingent für Gruppen von Google Cloud

Dieser Fehler tritt auf, wenn die Anzahl der vom IdP ausgegebenen Gruppen das Limit vonGoogle Cloudüberschreitet. Gruppen werden Google Cloud mit dem Attribut google.groupszugeordnet.

Bitten Sie Ihren Administrator, die Anzahl der Gruppen zu reduzieren, die von Ihrem IdP ausgegeben werden, um dieses Problem zu beheben. Ihr IdP muss nur Gruppen ausgeben, die zum Föderieren von Nutzern für Google Cloudverwendet werden. Weitere Informationen zu gruppenbezogenen Einschränkungen in Attributzuordnungen

SCIM-Mandant wurde nicht gefunden

Dieser Fehler tritt auf, wenn ein Nutzer versucht, sich mit einem Anbieter von Mitarbeiteridentitäts-Pools anzumelden, der für die Verwendung von SCIM konfiguriert ist, aber kein SCIM-Mandant für diesen Anbieter konfiguriert ist.

In diesem Fall erhalten Nutzer bei der Anmeldung die folgende Fehlermeldung:

There was an issue signing in with your identity provider.

So beheben Sie diesen Fehler:

1. SCIM-Mandant und ‑Token auf Google Cloud konfigurieren
2. Verknüpfen Sie den Anbieter mit einem SCIM-Mandanten.

400. Dies ist ein Fehler

Dieser Fehler tritt auf, wenn die Anfrage nicht wie erwartet empfangen wurde oder fehlerhaft ist.

Führen Sie folgende Schritte aus, um diesen Fehler zu beheben:

1. Folgen Sie der Anleitung im Abschnitt Ihre Nutzer über die Vorgehensweise bei der Anmeldung informieren, um zu prüfen, ob Sie die richtigen Schritte zur Anmeldung ausführen.

2. Vergleichen Sie die Konfiguration Ihres Anbieters für Workforce Identity-Pools mit Ihrer IdP-Konfiguration.

Anmeldefehler bei zusätzlichen Attributen

Dieser Abschnitt enthält Vorschläge zur Behebung von Fehlern bei der Verwendung von zusätzlichen Attributen.

Anmeldung schlägt fehl, wenn zusätzliche Attribute konfiguriert sind

Wenn Sie zusätzliche Attribute konfiguriert haben, führt jedes Konfigurationsproblem, z. B. eine falsche Client-ID, ein falscher Clientschlüssel oder eine falsche Aussteller-URI, dazu, dass der Anmeldeversuch fehlschlägt.

Führen Sie folgende Schritte aus, um diesen Fehler zu beheben:

1. Beschreiben Sie den Anbieter und prüfen Sie, ob die Client-ID und der Aussteller-URI korrekt sind.
2. Prüfen Sie, ob der Clientschlüssel gültig und nicht abgelaufen ist.
3. Prüfen Sie in Ihrem IdP, ob die Anwendung die erforderlichen Berechtigungen hat.

Gruppen aus SAML- oder OIDC-Assertion werden ignoriert

Wenn zusätzliche Attribute konfiguriert sind, werden alle Gruppeninformationen, die direkt in den SAML- oder OIDC-Ansprüchen angegeben sind, von der Workforce Identity-Föderation ignoriert. Stattdessen werden nur die Gruppen verwendet, die über den Backchannel abgerufen wurden (z. B. mit der Microsoft Graph API).

Wenn Ihre Nutzer die erwarteten Gruppen nicht sehen, prüfen Sie, ob die Gruppen korrekt über den Backchannel abgerufen werden und ob alle Attributfilter richtig konfiguriert sind.

OIDC-Anmeldefehler

Dieser Abschnitt enthält Vorschläge zur Behebung OIDC-spezifischer Fehler, die bei der Anmeldung durch einen Nutzer einer Mitarbeiteridentitätsföderation auftreten können.

Fehler beim Herstellen einer Verbindung zum Aussteller der angegebenen Anmeldedaten

Dieser Fehler tritt auf, wenn ein OIDC-Anbieter von Workforce Identity-Pools das OIDC-Discovery-Dokument oder den JWKS-URI nicht erreichen kann.

Führen Sie folgende Schritte aus, um diesen Fehler zu beheben:

1. Beschreiben Sie den Anbieter und prüfen Sie den konfigurierten issuerUri. Erstellen Sie die Discovery-Dokument-URL, indem Sie /.well-known/openid-configuration an den Aussteller-URI anhängen. Wenn Ihr issuerUri beispielsweise https://example.com ist, lautet die URL des Discovery-Dokuments https://example.com/.well-known/openid-configuration.

2. Öffnen Sie die URL des Discovery-Dokuments in einem Inkognitofenster.

   1. Wenn die URL nicht geöffnet wird oder der Browser einen 404-Fehler anzeigt, sehen Sie in der Dokumentation Ihres IdP nach, um den richtigen Aussteller-URI zu ermitteln. Aktualisieren Sie bei Bedarf den issuerUri in Ihrem Mitarbeiteridentitätspool.

      Wenn Ihr IdP lokal ausgeführt wird, lesen Sie in der Dokumentation Ihres IdP nach, wie Sie ihn für den Zugriff über das Internet bereitstellen.

   2. Wenn die URL geöffnet wird, prüfen Sie, ob die folgenden Bedingungen erfüllt sind:

      1. Prüfen Sie, ob die URL zu oft weiterleitet, bevor das Discovery-Dokument bereitgestellt wird. Wenn dies der Fall ist, wenden Sie sich an den Administrator Ihres Identitätsanbieters, um das Problem zu beheben.
      2. Prüfen Sie die IdP-Antwortzeit. Wenden Sie sich an Ihren IdP-Administrator, um die Antwortlatenz zu verringern.
      3. Das geöffnete Discovery-Dokument sollte im JSON-Format vorliegen.

      4. Suchen Sie im JSON nach dem Feld jwks_uri.

         1. Prüfen Sie, ob sich auch der zugehörige URL-Wert öffnet.
         2. Prüfen Sie, ob die URL die oben in dieser Anleitung beschriebenen Bedingungen erfüllt.

   3. Versuchen Sie noch einmal, sich anzumelden.

Fehler bei der SAML-Anmeldung

Dieser Abschnitt enthält Vorschläge zur Behebung SAML-spezifischer Fehler, die bei der Anmeldung durch einen Nutzer einer Mitarbeiteridentitätsföderation auftreten können.

Die Signatur in SAMLResponse konnte nicht überprüft werden.

Dieser Fehler tritt bei einem Anbieter von SAML-Workforce Identity-Pools auf, wenn die Signatur in der Antwort des IdP nicht mit einem der X.509-Zertifikate verifiziert werden kann, die Sie in der XML-Datei der IdP-Metadaten angeben, welche Sie bei Ihrem Anbieter von Workforce Identity-Pools konfiguriert haben. Eine häufige Ursache für diesen Fehler ist, dass das Verifizierungszertifikat bei Ihrem IdP rotiert wurde, Sie aber die Konfiguration des Anbieters von Workforce Identity-Pools nicht mit der neuesten XML-Datei der IdP-Metadaten aktualisiert haben.

Führen Sie folgende Schritte aus, um diesen Fehler zu beheben:

1. Optional: Führen Sie die Schritte unter IdP-Antwort prüfen aus, um die vom IdP zurückgegebene Antwort zu sehen und das Feld X509Certificate darin zu finden. Beschreiben Sie den Anbieter, mit dem Sie sich angemeldet haben, und prüfen Sie das Feld X509Certificate im Wert idpMetadataXml, der für den Anbieter von Workforce Identity-Pools festgelegt ist. Vergleichen Sie das Zertifikat mit dem Zertifikat in der Antwort Ihres IdP. Die Zertifikate müssen übereinstimmen.

2. Melden Sie sich in der Admin-Konsole Ihres IdP an und laden Sie die aktuelle XML-Datei mit Metadaten herunter.

3. Aktualisieren Sie den Anbieter von Workforce Identity-Pools für Workloads mit der heruntergeladenen IdP-Metadaten-XML.

4. Versuchen Sie noch einmal, sich anzumelden.

Der Empfänger in der SAML-Assertion ist nicht auf die richtige ACS-URL festgelegt.

Dieser Fehler tritt bei einem Anbieter von SAML-Workforce Identity-Pools auf, wenn die IdP-Antwort einen falschen Wert für das Feld Recipient im Tag SubjectConfirmationData enthält.

Um diesen Fehler zu beheben, aktualisieren Sie das Recipient URL / Redirect URL oder das entsprechende Feld in der Konfiguration Ihres IdP, um die Weiterleitungs-URL zu verwenden, die unter Weiterleitungs-URLs in Ihrem IdP einrichten beschrieben wird, und versuchen Sie es noch einmal.

Führen Sie die Schritte unter IdP-Antwort prüfen aus, um die vom IdP zurückgegebene Antwort zu sehen und zu bestätigen, dass das Feld Recipient korrekt ist.

Für den Anbieter von SAML-Workforce Identity-Pools locations/global/workforcePools/example-pool/providers/example-provider wird beispielsweise der Recipient, der die Weiterleitungs-URL enthält, in der SAML-Antwort des IdP angezeigt, wie unten gezeigt:

<SubjectConfirmationData Recipient="https://auth.cloud.google/signin-callback/locations/global/workforcePools/example-pool/providers/example-provider"

Das Ziel der SAMLResponse stimmt nicht mit der RP-Rückruf-URL überein.

Dieser Fehler tritt bei einem Anbieter von SAML-Workforce Identity-Pools auf, wenn die IdP-Antwort einen falschen Wert für das Feld Destination im Tag Response enthält.

Aktualisieren Sie zur Behebung dieses Problems Destination URL / Redirect URL oder das äquivalent Feld in der Konfiguration Ihres IdP zur Verwendung der hier beschriebenen Weiterleitungs-URL in Weiterleitungs-URLs bei Ihrem IdP einrichten.

Führen Sie die Schritte unter IdP-Antwort prüfen aus, um die vom IdP zurückgegebene Antwort zu sehen und zu bestätigen, dass das Feld Destination korrekt ist.

Bei einem Anbieter von Workforce Identity-Pools locations/global/workforcePools/example-pool/providers/example-provider würde der Destination, der die Weiterleitungs-URL enthält, beispielsweise in der SAML-Antwort des IdP so angezeigt werden:

<Response Destination="https://auth.cloud.google/signin-callback/locations/global/workforcePools/example-pool/providers/example-provider"

Ungültige Assertion: NameID fehlt oder ist leer

Dieser Fehler tritt auf, wenn die von Ihrem IdP empfangene SAML-Antwort das Feld NameId nicht enthält oder einen leeren Wert hat.

Um diesen Fehler zu beheben, konfigurieren Sie Ihre IdP-Dokumentation so, dass sie NameID sendet, was das Thema einer SAML-Assertion ist, in der Regel der authentifizierte Nutzer.

Hinweis :NameID ist erforderlich, auch wenn Sie in der Attributzuordnung ein anderes Attribut google.subject zuordnen.

Führen Sie die Schritte unter IdP-Antwort prüfen aus, um die vom IdP zurückgegebene Antwort und die darin festgelegte NameID zu sehen.

Alle <AudienceRestriction>-Objekte sollten die SAML-RP-Entitäts-ID enthalten.

Dieser Fehler tritt auf, wenn die AudienceRestriction-Tags in der SAML-Antwort von Ihrem IdP kein Audience-Tag mit einem Wert festlegen, der die Entitäts-ID des Anbieters von Workforce Identity-Pools darstellt.

Führen Sie folgende Schritte aus, um diesen Fehler zu beheben:

1. In der Dokumentation Ihres IdP finden Sie Informationen dazu, wie Sie die Zielgruppe in den AudienceRestriction-Tags konfigurieren, die in der SAML-Antwort gesendet werden. Normalerweise wird die Zielgruppe konfiguriert, indem das Feld Entity ID oder Audience in Ihrer IdP-Konfiguration eingerichtet wird. Weitere Informationen zu dem festzulegenden Wert SP Entity ID finden Sie im SAML-Abschnitt zum Erstellen eines Anbieters von Mitarbeiteridentitätsföderations-Pools.

2. Versuchen Sie noch einmal, sich anzumelden, nachdem Sie die IdP-Konfiguration aktualisiert haben.

Führen Sie die Schritte unter IdP-Antwort prüfen aus, um die vom IdP zurückgegebene Antwort und die darin festgelegten AudienceRestrictions zu sehen.

SCIM-Bereitstellungs- und Synchronisierungsfehler

In diesem Abschnitt wird beschrieben, wie Sie Probleme mit der SCIM-Bereitstellung und ‑Synchronisierung in der Mitarbeiteridentitätsföderation beheben.

Fehler bei der SCIM-Token-Authentifizierung (HTTP 401 oder 403)

Dieser Fehler tritt auf, wenn in den Protokollen des Identitätsanbieters (IdP) Authentifizierungsfehler (HTTP 401 Unauthorized oder HTTP 403 Forbidden) gemeldet werden. Häufige Ursachen sind:

• Das SCIM-Token fehlt, ist ungültig oder abgelaufen.
• Das SCIM-Token enthält zusätzliche Leerzeichen.
• In der Anfrage fehlt der Header Authorization: Bearer <TOKEN>.
• Das SCIM-Token hat nicht die erforderlichen Berechtigungen.

So beheben Sie das Problem:

1. Prüfen Sie in der Bereitstellungskonfiguration Ihres IdP, ob das SCIM-Token mit dem in Google Cloud generierten geheimen Token übereinstimmt und keine zusätzlichen Leerzeichen enthält.

2. Wenn das Token verloren gegangen oder ungültig ist, generieren Sie ein neues SCIM-Token:

   Hinweis :Jeder SCIM-Mandant unterstützt maximal zwei SCIM-Tokens. Wenn Sie bereits zwei Tokens haben, müssen Sie ein vorhandenes Token löschen, bevor Sie ein neues erstellen können. Weitere Informationen finden Sie unter Fehler beim Erstellen von SCIM-Tokens.

   gcloud iam workforce-pools providers scim-tenants tokens create SCIM_TOKEN_ID \
       --workforce-pool="WORKFORCE_POOL_ID" \
       --provider="PROVIDER_ID" \
       --scim-tenant="SCIM_TENANT_ID" \
       --location="global"
   

   Ersetzen Sie Folgendes:

   • SCIM_TOKEN_ID: eine ID für das neue SCIM-Token.
   • WORKFORCE_POOL_ID: die ID des Workforce Identity-Pools.
   • PROVIDER_ID: die ID des Bereitstellers des Workforce-Pools.
   • SCIM_TENANT_ID: die ID des SCIM-Mandanten.

3. Aktualisieren Sie das geheime Token in Ihrer IdP-Konfiguration.

Ratenbegrenzung überschritten (HTTP 429 Too Many Requests)

Dieser Fehler tritt auf, wenn die IdP-Anfrageraten das SCIM-Mandantenkontingent überschreiten. Schreib- und Leseanfragen sind standardmäßig auf 3.000 Anfragen pro SCIM-Mandant pro Organisation pro Minute begrenzt, was 50 Anfragen pro Sekunde entspricht. Weitere Informationen finden Sie unter Kontingente und Limits.

So beheben Sie das Problem:

1. Prüfen Sie, ob die Anforderungsrate für die IdP-Synchronisierung innerhalb der Kontingentlimits liegt.
2. Rufen Sie in der Google Cloud Console die Seite IAM & Verwaltung > Kontingente auf und filtern Sie nach iamscim.googleapis.com, um die Kontingentnutzung zu überwachen.
3. Wenn Sie einen höheren Durchsatz benötigen, fordern Sie in der Google Cloud Console eine Kontingenterhöhung an.

SCIM-Mandant kann nicht erstellt werden

Dieser Fehler tritt auf, wenn der Befehl gcloud iam workforce-pools providers scim-tenants create fehlschlägt.

Häufige Ursachen sind:

• Im Mitarbeiterpool ist bereits ein SCIM-Mandant vorhanden. Jeder Workforce-Pool unterstützt nur einen SCIM-Mandanten.
• Ein kürzlich gelöschter SCIM-Mandant befindet sich noch in der 30-tägigen Phase der vorläufigen Löschung.
• Sie haben nicht die Rolle „IAM Workforce Pool Admin“ (roles/iam.workforcePoolAdmin).
• Das Flag --claim-mapping enthält nicht unterstützte CEL-Ausdrücke (Common Expression Language).

So beheben Sie das Problem:

1. Prüfen Sie, ob Sie die Rolle „IAM Workforce Pool Admin“ (roles/iam.workforcePoolAdmin) haben.

2. Vorhandene SCIM-Mandanten auflisten, um zu prüfen, ob bereits ein Mandant vorhanden ist:

   gcloud iam workforce-pools providers scim-tenants list \
       --workforce-pool="WORKFORCE_POOL_ID" \
       --provider="PROVIDER_ID" \
       --location="global"
   

   Ersetzen Sie Folgendes:

   • WORKFORCE_POOL_ID: die ID des Mitarbeiteridentitätspools.
   • PROVIDER_ID: die ID des Bereitstellers des Workforce-Pools.

3. Wenn ein zuvor gelöschter Mandant vorläufig gelöscht wird, löschen Sie ihn mit dem Flag --hard-delete endgültig:

   gcloud iam workforce-pools providers scim-tenants delete SCIM_TENANT_ID \
       --workforce-pool="WORKFORCE_POOL_ID" \
       --provider="PROVIDER_ID" \
       --location="global" \
       --hard-delete
   

   Ersetzen Sie SCIM_TENANT_ID durch die ID des SCIM-Tenants.

4. Achten Sie darauf, dass in --claim-mapping nur unterstützte CEL-Ausdrücke verwendet werden. Weitere Informationen finden Sie unter Kartentoken und SCIM-Attribute.

Erstellen von SCIM-Tokens schlägt fehl

Dieser Fehler tritt auf, wenn der Befehl gcloud iam workforce-pools providers scim-tenants tokens create fehlschlägt.

Häufige Ursachen sind:

• Für den SCIM-Mandanten sind bereits die maximal zulässigen zwei SCIM-Tokens vorhanden.
• Sie haben nicht die Rolle „IAM Workforce Pool Admin“ (roles/iam.workforcePoolAdmin).

So beheben Sie das Problem:

1. Prüfen Sie, ob Sie die Rolle „IAM Workforce Pool Admin“ (roles/iam.workforcePoolAdmin) haben.

2. So listen Sie vorhandene SCIM-Tokens auf, um zu prüfen, ob das Limit von zwei Tokens erreicht wurde:

   gcloud iam workforce-pools providers scim-tenants tokens list \
       --workforce-pool="WORKFORCE_POOL_ID" \
       --provider="PROVIDER_ID" \
       --scim-tenant="SCIM_TENANT_ID" \
       --location="global"
   

   Ersetzen Sie Folgendes:

   • WORKFORCE_POOL_ID: die ID des Mitarbeiteridentitätspools.
   • PROVIDER_ID: die ID des Bereitstellers des Workforce-Pools.
   • SCIM_TENANT_ID: die ID des SCIM-Mandanten.

3. Wenn der SCIM-Mandant bereits zwei Tokens hat, löschen Sie ein ungenutztes oder ungültiges Token:

   gcloud iam workforce-pools providers scim-tenants tokens delete SCIM_TOKEN_ID \
       --workforce-pool="WORKFORCE_POOL_ID" \
       --provider="PROVIDER_ID" \
       --scim-tenant="SCIM_TENANT_ID" \
       --location="global"
   

   Ersetzen Sie SCIM_TOKEN_ID durch die ID des zu löschenden SCIM-Tokens.

4. Versuchen Sie nach dem Löschen des Tokens noch einmal, das neue SCIM-Token zu erstellen.

Konflikt durch doppelte Attributzuordnung (HTTP 409 Conflict)

Dieser Fehler tritt auf, wenn in den Protokollen des Identitätsanbieters (IdP) während der Synchronisierung ein HTTP 409 Conflict gemeldet wird, weil der IdP doppelte Werte für google.subject oder google.group oder nicht eindeutige Werte für userName oder displayName sendet.

So beheben Sie das Problem:

1. Prüfen Sie in der Administratorkonsole Ihres IdP, ob die Attribute, die google.subject und google.group zugeordnet sind, sich nicht überschneidende Werte erzeugen.
2. Jeder Nutzer muss eine eindeutige userName und jede Gruppe eine eindeutige displayName haben.

PATCH-Anfragen für Microsoft Entra ID schlagen fehl

Dieser Fehler tritt auf, wenn Nutzeraktualisierungen oder PATCH-Anfragen von Microsoft Entra ID fehlschlagen, weil in der Mandanten-URL der Abfrageparameter ?aadOptscim062020 fehlt, der für RFC-konforme PATCH-Anfragen erforderlich ist.

So beheben Sie das Problem:

1. Rufen Sie in Microsoft Entra ID Ihre Unternehmensanwendung auf und wählen Sie Bereitstellung > Bereitstellung verwalten > Administratoranmeldedaten aus.

2. Hängen Sie im Feld Tenant URL (Tenant-URL) ?aadOptscim062020 an den Basis-URI an:

   https://iamscim.googleapis.com/v1alpha1/tenants/SCIM_TENANT_UID?aadOptscim062020
   

   Ersetzen Sie SCIM_TENANT_UID durch die eindeutige ID Ihres SCIM-Mandanten.

3. Klicken Sie auf Verbindung testen und speichern Sie dann die Konfiguration.

Nutzer- oder gruppenbasierter Zugriff oder Freigabe funktioniert nicht

Dieses Problem tritt auf, wenn synchronisierte Nutzer nicht auf Google Cloud-Ressourcen zugreifen können oder wenn das Teilen von Notebooks in Gemini Notebook Enterprise oder von Agents in der Gemini Enterprise-App fehlschlägt.

Häufige Ursachen sind:

• Stille Synchronisierungsfehler oder Verzögerungen vom IdP.
• Inkonsistente Anspruchszuordnungen zwischen dem Anbieter (--attribute-mapping) und dem SCIM-Mandanten (--claim-mapping).
• Änderungen im IdP an Attributen, die google.subject oder google.group zugeordnet sind: Bei Google Cloud wird davon ausgegangen, dass Werte, die diesen Attributen zugeordnet sind, unveränderlich sind.
• Die SCIM-Nutzung ist für Gruppen beim Anbieter nicht aktiviert.

So beheben Sie das Problem:

1. Synchronisierung und Mitgliedschaft überprüfen: Prüfen Sie, ob Nutzer, Gruppen und Gruppenmitgliedschaften erfolgreich mit Google Cloudsynchronisiert wurden:

   • Nutzersynchronisierung überprüfen:

     curl -G -H "Authorization: Bearer SCIM_TOKEN" \
       "https://iamscim.googleapis.com/v1alpha1/tenants/SCIM_TENANT_UID/Users" \
       --data-urlencode 'filter=userName eq "USER_NAME"'
     

   • Gruppensynchronisierung überprüfen:

     curl -G -H "Authorization: Bearer SCIM_TOKEN" \
       "https://iamscim.googleapis.com/v1alpha1/tenants/SCIM_TENANT_UID/Groups" \
       --data-urlencode 'filter=displayName eq "GROUP_NAME"'
     

   • Gruppenmitgliedschaft überprüfen: So prüfen Sie, ob ein Nutzer Mitglied einer Gruppe ist:

     curl -G -H "Authorization: Bearer SCIM_TOKEN" \
       "https://iamscim.googleapis.com/v1alpha1/tenants/SCIM_TENANT_UID/Groups" \
       --data-urlencode 'filter=id eq "GROUP_ID" and members eq "USER_ID"'
     

     Wenn der Nutzer Mitglied der Gruppe ist, wird in der Antwort totalResults: 1 zurückgegeben. Wenn der Nutzer kein Mitglied ist, wird in der Antwort totalResults: 0 zurückgegeben.

   Ersetzen Sie Folgendes:

   • SCIM_TOKEN: Ihr SCIM-Secret-Token.
   • SCIM_TENANT_UID: die eindeutige ID Ihres SCIM-Tenants.
   • USER_NAME: Der Nutzername des synchronisierten Nutzers.
   • GROUP_NAME: Der Anzeigename der synchronisierten Gruppe.
   • GROUP_ID: Die SCIM-ID der synchronisierten Gruppe, die im Feld id der Antwort auf die Gruppenabfrage zurückgegeben wird.
   • USER_ID: die SCIM-ID des synchronisierten Nutzers, die im Feld id der Antwort auf die Nutzerabfrage zurückgegeben wird.

2. Anspruchszuordnungen prüfen: Achten Sie darauf, dass das Attribut, das im Anbieter google.subject zugeordnet ist (z. B. google.subject=assertion.email.lowerAscii()), mit der Identität übereinstimmt, die im SCIM-Mandanten zugeordnet ist (z. B. google.subject=user.emails[0].value.lowerAscii()). Da Anspruchszuordnungen unveränderlich sind, müssen Sie den SCIM-Mandanten endgültig löschen und mit der richtigen Zuordnung neu erstellen, wenn die Zuordnungen nicht übereinstimmen.

3. Unveränderlichkeit der Kennzeichnungen sicherstellen: Prüfen Sie, ob sich die IdP-Attribute, die google.subject und google.group zugeordnet sind, geändert haben. Google Cloudbehandelt Werte, die diesen Attributen zugeordnet sind, als unveränderliche Kennzeichnungen. Wenn sich ein Attributwert in Ihrem IdP geändert hat, machen Sie die Änderung in Ihrem IdP rückgängig oder löschen Sie den betroffenen Nutzer oder die betroffene Gruppe dauerhaft aus Ihrem IdP und erstellen Sie ihn bzw. sie mit dem neuen Wert neu, damit die Kennung mit den Erwartungen von Google Cloudübereinstimmt.

4. SCIM-Gruppennutzung aktivieren: Aktualisieren Sie Ihren Anbieter, um SCIM für Gruppen zu aktivieren:

   gcloud iam workforce-pools providers update-oidc PROVIDER_ID \
       --workforce-pool="WORKFORCE_POOL_ID" \
       --location="global" \
       --scim-usage="enabled-for-groups"
   

   Ersetzen Sie Folgendes:

   • PROVIDER_ID: die ID des Bereitstellers des Workforce-Pools.
   • WORKFORCE_POOL_ID: die ID des Mitarbeiteridentitätspools.

Änderungen im IdP werden verzögert oder gar nicht übernommen

Dieses Problem tritt auf, wenn IdP-Aktualisierungen für Nutzer, Gruppenmitgliedschaften oder Löschungen nicht sofort in Google Cloudangezeigt werden.

Da SCIM pushbasiert ist, hängen Aktualisierungen vom Synchronisierungszeitplan Ihres IdP ab. Microsoft Entra ID wird beispielsweise etwa alle 40 Minuten synchronisiert.

So beheben Sie das Problem:

1. Warten Sie auf den nächsten geplanten Synchronisierungszyklus von Ihrem IdP.
2. Wenn Sie Änderungen sofort anwenden möchten, lösen Sie eine On-Demand-Synchronisierung in der Administratorkonsole Ihres IdP aus.

Nutzerbereitstellung schlägt aufgrund des E-Mail-Formats fehl

Dieser Fehler tritt auf, wenn bestimmte Nutzer nicht mit Google Cloudsynchronisiert werden können und in den Protokollen Ihres Identitätsanbieters (IdP) ein HTTP-400 Bad Request mit einem invalidValue-SCIM-Fehler gemeldet wird.

Google Cloud Für SCIM ist genau eine Arbeits-E-Mail-Adresse pro Nutzer erforderlich. Die Bereitstellung schlägt fehl, wenn der IdP mehrere E-Mails sendet oder die E-Mail nicht vom Typ work ist.

Um dieses Problem zu beheben, konfigurieren Sie die Zuordnung der IdP-Attribute so, dass nur die primäre Arbeits-E-Mail-Adresse gesendet wird.

Gruppenaktualisierungen schlagen fehl (HTTP PUT wird nicht unterstützt)

Dieser Fehler tritt auf, wenn Gruppenaktualisierungen fehlschlagen, weil der Client HTTP PUT verwendet, was nicht unterstützt wird. Die Google Cloud SCIM API unterstützt nur HTTP PATCH für Gruppenaktualisierungen.

Um dieses Problem zu beheben, konfigurieren Sie Ihren IdP oder benutzerdefinierten Client so, dass HTTP PATCH für Gruppenaktualisierungen verwendet wird.