Erreurs et correctifs Multi-SSO (SAML 2.0)

  • Rversion finale: Yokohama
  • Mis à jour 30 janv. 2025
  • 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 IdP SAML.
    • 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é sur l’instance.
    Les certificats ne correspondent pas. Expect : <certStr>, réel : <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 sur l’instance ServiceNow.
    • Le certificat est au mauvais format.
    		 Confirmez 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.
    Échec de la 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 Incohérence SubjectConfirmationData. Expect : <inResponseTo>, réel : <inResponseTo>. Échec de la validation de la confirmation d’objet. N/A Cette erreur se produit si l’une des situations suivantes se produit :
    • L’IdP renvoie une SAMLResponse pour une autre SAMLRequest
    • Un utilisateur crée un signet pour l’URL avec SAMLRequest au lieu de l’URL de l’instance uniquement
    • Si une valeur nulle 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>... SessionIndex non valide. N/A Le SessionIndex est requis dans l’instance SNC. L’IdP le renvoie dans la réponse SAML pour s’authentifier avec succès.

    L’administrateur IdP doit confirmer que l’index de session 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 peuvent être manquantes en raison d’une erreur sur IdP.

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

    Passez en revue la SAMLResponse pour déterminer si les conditions sont incluses dans la SAMLResponse.

    Les données de confirmation d’objet valides peuvent expiré ou non pour la bonne audience.

    Incohérence de l’audience d’assertion. Expect : <propAudience>, réel : <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 du public 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. Localisez <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. Expect : <valeur sur l’instance>, actual : <valeur retournée par IdP> L’émetteur de l’assertion n’est pas valide. L’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 de l’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>

    		 Échec de la confirmation de la validation de l’objet. Nombre de secondes avant la contrainte notBefore, ou après la contrainte notOnOrAfter, à considérer toujours valable. L’horloge IdP n’est pas synchronisée avec l’horloge SP. Mettez à jour la propriété SAML glide.authenticate.sso.saml2.clockskew vers une valeur plus élevée. La valeur par défaut est de 180 secondes. Certains cas 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 valable. 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 cas 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. Définissez (ou créez) le glide.authenticate.failed_redirect de propriété système 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. Vérifiez 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 de 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 s’affiche dans votre table 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 refusé la connexion en raison d’un problème avec la demande qui lui a été envoyée. Malheureusement, la réponse SAML reçue de l’IdP dans la plupart des cas 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.