Erreurs et correctifs Multi-SSO (SAML 2.0)

  • Rversion finale: Australia
  • Mis à jour 12 mars 2026
  • 5 minutes de lecture

    • Une liste des erreurs courantes et des correctifs associés pour une installation et une configuration Multi-SSO (SAML 2.0).

    Tableau 1. Erreurs lors de la configuration de l’authentification unique (SAML 2.0)
    Erreur dans les journaux d’instance Message de test de la connexion Propriété SAML Diagnostic Corriger
    NotAfter : <Thu Jun 05 22:57:44 PDT 2014>. Vérifiez que le certificat IDP x509 est présent, valide et actif. N/A Le certificat actuel ou l’assertion SAML a expiré.
    • Synchronisez l’horloge SNC avec l’horloge du serveur SAML IdP.
    • Mettez à jour l’enregistrement du certificat SAML 2.0.
    • Impossible de localiser le certificat SAML 2.0.
    • Impossible de trouver une signature numérique stockée dans l’instance ServiceNow.
    		 Vérifiez que le certificat IDP x509 est présent, valide et actif La chaîne au format PEM doit être saisie dans le champ Certificat PEM. Le certificat SAML n’existe pas. Il est peut-être inactif. Assurez-vous que le certificat au format PEM correct est téléchargé dans l’instance.
    Les certificats ne correspondent pas. Attente : <certStr>, valeur réelle : <inboundCert>. Vérifiez que le certificat IDP x509 est présent, valide et actif. N/A Le certificat disponible dans SNC ne correspond pas au certificat dans l’assertion. Les causes sont les suivantes :
    • Le certificat est mis à jour sur l’IdP, mais pas dans l’instance ServiceNow.
    • Le certificat est au mauvais format.
    		 Vérifiez que la chaîne au format PEM dans l’enregistrement du certificat SAML 2.0 correspond au certificat X509 dans la réponse SAML pour l’IdP de l’utilisateur.
    Défaut de vérification de la validité du certificat. Vérifiez que le certificat IDP x509 est présent, valide et actif N/A Le certificat actuel a peut-être expiré. Mettez à jour l’enregistrement du certificat SAML 2.0.
    Échec de la validation du profil de signature. Vérifiez que le certificat IDP x509 est présent, valide et actif. N/A L’assertion peut être signée avec un certificat différent. Vérifiez si l’IdP dispose du même certificat que l’instance SNC.
    InResponseTo dans l’incohérence SubjectConfirmationData. Attente : <inResponseTo>, valeur réelle : <inResponseTo>. Échec de la validation de la confirmation d’objet. N/A Cette erreur apparaît si l’une des situations suivantes se produit :
    • L’IdP renvoie une SAMLResponse pour une autre SAMLRequest
    • Un utilisateur ajoute un signet à l’URL avec SAMLRequest et non seulement avec l’URL de l’instance
    • Si une valeur null est attendue, la réponse peut être envoyée à un autre nœud lorsque l’instance possède plusieurs nœuds.
    		 L’administrateur IdP doit confirmer que la SAMLReponse attendue est renvoyée. Il peut s’agir d’un problème d’équilibreur de charge ou d’infrastructure.
    Valeur d’index de session introuvable : <message>... Index de session non valide. N/A Le SessionIndex est requis dans l’instance SNC. L’IdP la renvoie dans la réponse SAML pour s’authentifier avec succès.

    L’administrateur de l’IdP doit confirmer que le SessionIndex est défini dans SAMLResponse.
    Aucune confirmation d’objet valide trouvée. Échec de la validation de la confirmation d’objet. N/A Des conditions pourraient manquer en raison d’une erreur sur l’IdP.

    Le StatusCode dans la réponse contiendrait Répondeur au lieu de la réussite attendue.

    Examinez la SAMLResponse pour déterminer si les conditions sont incluses dans la SAMLResponse.

    Les données de confirmation d’objet valides peuvent avoir expiré ou ne pas être pour la bonne audience.

    Incohérence de l’audience d’assertion. attente : <propAudience>, valeur réelle : <audienceUri>.

    ou

    Échec de la validation de AudienceRestriction. Aucune audience correspondante trouvée.

    		 Vérifiez que le champ « URI de l’audience » est défini correctement L’URI de l’audience qui accepte le jeton SAML2. (Il s’agit normalement de votre URI d’instance. Par exemple : https://demo.service-now.com.) L’URI de l’audience configurée par l’instance SNC doit correspondre à la valeur de l’IdP. Recherchez <saml2 :Audience> dans SAMLResponse dans les journaux et vérifiez que la valeur correspond à celle de l’instance.
    L’émetteur de l’assertion n’est pas valide. Attente : <valeur sur l’instance>, valeur réelle : <valeur renvoyée par l’IdP> L’émetteur de l’assertion n’est pas valide. URL du fournisseur d’identité qui émet le jeton de sécurité SAML2 avec les informations de l’utilisateur. L’ID de l’entité IdP (émetteur) ne correspond pas à la valeur définie dans l’instance SNC.
    • Vérifiez si l’IdP ou le SP n’est pas configuré correctement.
    • Vérifiez que la propriété SAML (l’URL du fournisseur d’identité qui émet le jeton de sécurité SAML2 avec les informations utilisateur) est correctement définie.

    L’objet est valide dans le futur. Maintenant : <maintenant>, NotBefore : <notBefore>

    ou

    L’objet a expiré. Maintenant : <maintenant>, NotOnOrAfter : <notOnOrAfter>

    		 La confirmation de la validation de l’objet a échoué. Nombre de secondes avant la contrainte notBefore, ou après la contrainte notOnOrAfter, à considérer toujours valide. L’horloge IdP n’est pas synchronisée avec l’horloge SP. Mettez à jour la propriété SAML glide.authenticate.sso.saml2.clockskew sur une valeur plus élevée. La valeur par défaut est de 180 secondes. Certains tickets nécessitent un paramètre de 300 ou plus. Vous devrez peut-être également vérifier l’heure sur votre serveur IdP.

    L’assertion est valide dans le futur, maintenant : <now>, notBefore : <notBefore>

    ou

    L’assertion a expiré, maintenant : <now>, notOnOrAfter : <notOnOrAfter>

    		 L’assertion n’est pas valide. Nombre de secondes avant la contrainte notBefore, ou après la contrainte notOnOrAfter, à considérer toujours valide. L’horloge IdP n’est pas synchronisée avec l’horloge SP

    Augmentez la valeur de la propriété SAML. La valeur par défaut est de 60 secondes. Certains tickets nécessitent un paramètre de 300 ou plus. Vous devrez peut-être également vérifier l’heure sur votre serveur IdP.
    Tableau 2. Erreurs courantes de connexion et d’IdP
    Erreur ou symptôme Diagnostic Corriger
    Les demandes de connexion génèrent une boucle infinie entre le système et l’IdP lorsque la haute sécurité est active.
    • En règle générale, le point de terminaison d’URL est une page d’erreur ou une page de déconnexion.
    • Le logout_redirect.do peut créer cette boucle lorsque vous définissez glide.security.url.whitelist sans ajouter le nom d’hôte IdP à la valeur de propriété.
      Remarque :
      Pour en savoir plus sur cette propriété, consultez Appliquer la vérification de la liste d’autorisations d’URL Paramètres de renforcement de la sécurité de l’instance.
    		 Définissez (ou créez) la propriété système glide.authenticate.failed_redirect pour rediriger les demandes d’authentification ayant échoué vers cette URL.
    Le jeton utilisé pour authentifier l’utilisateur ou la demande est signé avec l’algorithme de signature http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 qui n’est pas l’algorithme de signature attendu http://www.w3.org/2000/09/xmldsig#rsa-sha1. Consultez l’onglet Contexte de l’alerte pour plus de détails sur l’événement. Accédez à l’onglet Avancé de la boîte de dialogue Configuration de l’approbation de la partie de confiance et vérifiez que l’algorithme est défini sur SHA-1 et non sur SHA-256.
    Le message d’erreur urn :oasis :names :tc :SAML :2.0 :status :Requester apparaît dans votre table de journal système (syslog). Lorsque votre fournisseur d’identités (par exemple, ADFS) répond avec l’état oasis :names :tc :SAML :2.0 :status :Requester, cela signifie qu’il a rejeté la connexion en raison d’un problème avec la demande qui lui a été envoyée. Malheureusement, dans la plupart des cas, la réponse SAML reçue de l’IdP ne fournit pas plus de détails sur l’erreur. Examinez la demande SAML envoyée à l’IDP et collaborez avec votre administrateur IdP pour mettre à jour les paramètres SAML de votre instance afin d’éviter l’erreur. Vous devrez peut-être contacter votre fournisseur IDP pour comprendre la raison de l’échec de la connexion.