Multi-SSO (SAML 2,0) – Fehler und Korrekturen

  • Freigeben Version: Zurich
  • Aktualisiert 31. Juli 2025
  • 4 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
    NotNachher: <Do Jun 05 22:57:44 PDT 2014>. Stellen Sie sicher, dass das IDP x509-Zertifikat vorhanden, gültig und aktiv ist. N/V 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 sie 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. N/V Das in SNC verfügbare Zertifikat stimmt nicht mit dem Zertifikat in der Assertion überein. Ursachen sind:
    • Das Zertifikat wird im 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 SAMLResponse für den Anwender-IdP übereinstimmt.
    Fehler beim Überprüfen der Gültigkeit des Zertifikats. Stellen Sie sicher, dass das IDP x509-Zertifikat vorhanden, gültig und aktiv ist N/V 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. N/V Die Assertion kann mit einem anderen Zertifikat signiert werden. Überprüfen Sie, ob der 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. N/V Dieser Fehler wird angezeigt, wenn eine der folgenden Situationen auftritt:
    • Der IdP gibt eine SAMLResponse für eine andere SAMLRequest zurück
    • Ein Anwender markiert die URL mit der SAMLRequest anstelle nur der Instanz-URL mit einem Lesezeichen
    • Wenn ein Nullwert 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 die erwartete SAMLReponse zurückgegeben wird. Diese Situation kann ein Lastenausgleichsmodul- oder Infrastrukturproblem sein.
    SessionIndex-Wert nicht gefunden: <message>... SessionIndex ungültig. N/V Der SessionIndex ist in der SNC-Instanz erforderlich. Der IdP gibt ihn 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. N/V 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 SAMLResponse, um festzustellen, ob Bedingungen in der SAMLResponse enthalten sind.

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

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

    oder

    Validierung von AudienceRestriction fehlgeschlagen. Keine übereinstimmende Zielgruppe gefunden.

    Stellen Sie sicher, dass das Feld „Zielgruppen-URI“ richtig festgelegt ist Der Zielgruppen-URI, der das SAML2-Token akzeptiert. (Normalerweise ist dies Ihr 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 SAMLResponse 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 IdP-Entitäts-ID (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 vorstehend: <notBefore>

    oder

    Betreff ist abgelaufen. Now: <now>, nicht OnOrNachher: <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 wird 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. In einigen Fällen ist eine Einstellung von 300 oder höher erforderlich. Möglicherweise müssen Sie auch die Zeit auf Ihrem IdP-Server überprüfen.

    Assertion ist in der Zukunft gültig, jetzt: <now>, nicht vor: <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. In einigen Fällen ist eine Einstellung von 300 oder höher erforderlich. 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 zur Authentifizierung des Anwenders oder der Anforderung verwendete Token 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. Auf der Registerkarte Warnungskontext finden Sie Ereignisdetails. Navigieren Sie zur Registerkarte Erweitert des Konfigurationsdialogfelds „Vertrauenswürdige Partei“, und überprüfen Sie, ob 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 zum Fehler. Überprüfen Sie die an den IDP gesendete SAML-Anforderung, und arbeiten Sie mit Ihrem IDP-Administrator zusammen, um Ihre SAML-Einstellungen für die Instanz 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.