Fehler und Korrekturen für Multi-SSO (SAML 2,0)

  • Freigeben Version: Yokohama
  • Aktualisiert 30. Januar 2025
  • 5 Minuten Lesedauer

    • Eine Liste allgemeiner Fehler und zugehöriger Korrekturen für ein Multi-SSO-Setup und eine Konfiguration (SAML 2,0).

    Tabelle : 1. Fehler beim Multi-SSO-Setup (SAML 2,0)
    Fehler in Instanzprotokollen Verbindungsnachricht Testen SAML-Eigenschaft Diagnose Beheben
    Nicht nach: <Do Jun 05 22:57:44 PDT 2014>. Stellen Sie sicher, dass das IDP x509-Zertifikat vorhanden, gültig und aktiv ist. k. A. Das aktuelle Zertifikat oder die SAML-Assertion ist abgelaufen.
    • Synchronisieren Sie die SNC-Uhr mit der SAML-IDP-Serveruhr.
    • Aktualisieren Sie den SAML 2,0-Zertifikatdatensatz.
    • SAML 2.0-Zertifikat wurde nicht gefunden.
    • Es wurde keine digitale Signatur gefunden, die in der ServiceNow-Instanz gespeichert ist.
    		 Stellen Sie sicher, dass das IDP x509-Zertifikat vorhanden, gültig und aktiv ist Die PEM-formatierte Zeichenfolge muss in das Feld „PEM-Zertifikat“ eingegeben werden. Das SAML-Zertifikat ist nicht vorhanden. Möglicherweise ist er inaktiv. Stellen Sie sicher, dass das richtige PEM-formatierte Zertifikat in die Instanz hochgeladen wird.
    Zertifikate stimmen nicht überein. Erwartet: <certStr>, ist-Wert: <inboundCert>. Stellen Sie sicher, dass das IDP x509-Zertifikat vorhanden, gültig und aktiv ist. k. A. Das in SNC verfügbare Zertifikat stimmt nicht mit dem Zertifikat in der Assertion überein. Ursachen:
    • Das Zertifikat wird auf dem IDP aktualisiert, aber nicht in der ServiceNow-Instanz.
    • Das Zertifikat hat das falsche Format.
    		 Bestätigen Sie, dass die PEM-formatierte Zeichenfolge im SAML 2,0-Zertifikatdatensatz mit dem X509-Zertifikat in der SAMLAntwort für die Anwender-ID übereinstimmt.
    Fehler beim Überprüfen der Gültigkeit des Zertifikats. Stellen Sie sicher, dass das IDP x509-Zertifikat vorhanden, gültig und aktiv ist k. A. Das aktuelle Zertifikat ist möglicherweise abgelaufen. Aktualisieren Sie den SAML 2,0-Zertifikatdatensatz.
    Fehler beim Validieren des Signaturprofils. Stellen Sie sicher, dass das IDP x509-Zertifikat vorhanden, gültig und aktiv ist. k. A. Die Assertion ist möglicherweise mit einem anderen Zertifikat signiert. Überprüfen Sie, ob die IDP dasselbe Zertifikat wie die SNC-Instanz hat.
    InResponseTo-Attribut in SubjectConfirmationData stimmt nicht überein. Erwartet: <inResponseTo>, ist-Wert: <inResponseTo>. Validierung der Antragstellerbestätigung fehlgeschlagen. k. A. Dieser Fehler wird angezeigt, wenn eine der folgenden Situationen auftritt:
    • Der IDP gibt eine SAMLAntwort für eine andere SAMLAnforderung zurück
    • Ein Anwender markiert die URL mit der SAMLRequest anstelle nur der Instanz-URL mit einem Lesezeichen
    • Wenn ein Null-Wert erwartet wird, wird die Antwort möglicherweise an einen anderen Knoten gesendet, wenn die Instanz mehrere Knoten hat.
    		 Der IDP-Administrator muss bestätigen, dass der erwartete SAMLReponse zurückgegeben wird. Diese Situation kann ein Lastenausgleichsmodul oder Infrastrukturproblem sein.
    SessionIndex-Wert nicht gefunden: <message>... SessionIndex ist ungültig. k. A. Der SessionIndex ist in der SNC-Instanz erforderlich. Der IDP gibt sie in der SAML-Antwort zurück, um sich erfolgreich zu authentifizieren.

    Der IDP-Administrator muss bestätigen, dass der SessionIndex in der SAMLResponse definiert ist.
    Es konnte kein gültiges SubjectConfirmation-Element gefunden werden. Validierung der Antragstellerbestätigung fehlgeschlagen. k. A. Bedingungen könnten aufgrund eines Fehlers im IDP fehlen.

    Der Statuscode in der Antwort enthält den Beantworter anstelle des erwarteten Erfolgs.

    Überprüfen Sie die SAMLResponse, um zu bestimmen, ob Bedingungen in der SAMLResponse enthalten sind.

    Die gültigen Bestätigungsdaten des Antragstellers könnten abgelaufen sein oder nicht für die richtige Zielgruppe.

    Assertionszielgruppe stimmt nicht überein. Erwartet: <propAudience>, ist-Wert: <audienceUri>.

    oder

    Validierung der AudienceRestriction fehlgeschlagen. Keine übereinstimmende Zielgruppe gefunden.

    		 Stellen Sie sicher, dass das Feld „Zielgruppen-URI“ korrekt festgelegt ist Die Zielgruppen-URI, die das SAML2-Token akzeptiert. (Normalerweise ist dies Ihre Instanz-URI. Beispiel: https://demo.service-now.com .) Der konfigurierte Zielgruppen-URI der SNC-Instanz muss mit dem Wert im IDP übereinstimmen. Suchen Sie <saml2:Audience> in der SAMLAntwort in den Protokollen, und stellen Sie sicher, dass der Wert mit dem in der Instanz übereinstimmt.
    Assertionsaussteller ist ungültig. Erwartet: <Wert in Instanz>, ist-Wert: <von IdP zurückgegebener Wert> Assertionsaussteller ist ungültig. Die Identitätsanbieter-URL, die das SAML2-Sicherheitstoken mit Anwenderinformationen ausgibt. Die ID der IdP-Entität (Aussteller) stimmt nicht mit dem in der SNC-Instanz definierten Wert überein.
    • Überprüfen Sie, ob IdP oder SP nicht ordnungsgemäß konfiguriert ist.
    • Bestätigen Sie, dass die SAML-Eigenschaft (die Identitätsanbieter-URL, die das SAML2-Sicherheitstoken mit Anwenderinformationen ausgibt) richtig festgelegt ist.

    Betreff ist in der Zukunft gültig. Now: <now>, nicht vorher: <notBefore>

    oder

    Betreff ist abgelaufen. Now: <now>, nicht OnOrAfter: <notOnOrAfter>

    		 Bestätigung der Antragstellervalidierung fehlgeschlagen. Die Anzahl in Sekunden vor der notBefore-Einschränkung oder nach der notOnOrAfter-Einschränkung, die als noch gültig betrachtet werden soll. Die IdP-Uhr ist nicht mit der SP-Uhr synchronisiert. Aktualisieren Sie die SAML-Eigenschaft glide.authenticate.sso.saml2.clockskew auf einen größeren Wert. Der Standardwert ist 180 Sekunden. Einige Fälle erfordern eine Einstellung von 300 oder höher. Möglicherweise müssen Sie auch die Zeit auf Ihrem IdP-Server überprüfen.

    Assertion ist in der Zukunft gültig, Now: <now>, notBefore: <notBefore>

    oder

    Assertion ist abgelaufen, jetzt: <now>, notOnOrAfter: <notOnOrAfter>

    		 Assertion ist ungültig. Die Anzahl in Sekunden vor der notBefore-Einschränkung oder nach der notOnOrAfter-Einschränkung, die als noch gültig betrachtet werden soll. IdP-Uhr ist nicht mit SP-Uhr synchronisiert

    Aktualisieren Sie die SAML-Eigenschaft auf einen größeren Wert. Standard: 60 Sekunden. Einige Fälle erfordern eine Einstellung von 300 oder höher. Möglicherweise müssen Sie auch die Zeit auf Ihrem IdP-Server überprüfen.
    Tabelle : 2. Allgemeine Anmelde- und IDP-Fehler
    Fehler oder Symptom Diagnose Beheben
    Anmeldeanforderungen erzeugen eine Endlosschleife zwischen dem System und dem IDP, wenn hohe Sicherheit aktiv ist. Legen Sie die Systemeigenschaft glide.authenticate.failed_redirect fest (oder erstellen), um fehlgeschlagene Authentifizierungsanforderungen an diese URL umzuleiten.
    Das Token, das zur Authentifizierung des Anwenders oder der Anforderung verwendet wird, wird mit dem Signaturalgorithmus http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 signiert, der nicht dem erwarteten Signaturalgorithmus http://www.w3.org/2000/09/xmldsig#rsa-sha1 entspricht. Ereignisdetails finden Sie auf der Registerkarte „Warnungskontext“. Navigieren Sie zur Registerkarte „Erweitert“ des Konfigurationsdialogfelds „Vertrauen der vertrauenden Partei“, und stellen Sie sicher, dass der Algorithmus auf SHA-1 und nicht auf SHA-256 festgelegt ist.
    Die Fehlermeldung URN:Oasis:names:tc:SAML:2,0:Status:anfordernde Person Wird in Ihrer Systemprotokolltabelle (syslog) angezeigt. Wenn Ihr IDP (z. B. ADFS) mit dem Status antwortet Oasis:names:tc:SAML:2,0:Status:anfordernde Person , Bedeutet, dass der IDP die Anmeldung aufgrund eines Problems mit der an ihn gesendeten Anforderung abgelehnt hat. Leider enthält die vom IDP empfangene SAML-Antwort in den meisten Fällen keine weiteren Details für den Fehler. Überprüfen Sie die an den IdP gesendete SAML-Anforderung, und arbeiten Sie mit Ihrem IdP-Administrator zusammen, um Ihre Instanz-SAML-Einstellungen zu aktualisieren, um den Fehler zu vermeiden. Möglicherweise müssen Sie sich an Ihren IdP-Anbieter wenden, um den Grund für den Anmeldefehler zu verstehen.