Erreurs et correctifs de Multi-SSO (SAML 2.0)

  • Rversion finale: Washingtondc
  • Mis à jour 1 févr. 2024
  • 5 minutes de lecture

    • Une liste des erreurs courantes et des correctifs associés pour une installation et une configuration de l’authentification unique (SAML 2.0).

    Tableau 1. Erreurs lors de la configuration de SSO à fournisseurs multiples (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é dans l’instance.
    Les certificats ne correspondent pas. Attendu : <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 dans l’instance ServiceNow.
    • Le format du certificat n’est pas correct.
    		 Vérifiez que la chaîne au format PEM dans l’enregistrement de certificat SAML 2.0 correspond au certificat X509 dans SAMLResponse pour l’IdP d’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 possède le même certificat que l’instance SNC.
    InResponseTo dans l’incompatibilité de SubjectConfirmationData. Attendu : <inResponseTo>, réel : <inResponseTo>. Échec de la validation de la confirmation de l’objet. N. A. Cette erreur s’affiche si l’une des situations suivantes se produit :
    • L’IdP renvoie une réponse SAML pour une autre requête SAMLRequest
    • Un utilisateur place un signet sur l’URL avec SAMLRequest au lieu de l’URL d’instance uniquement
    • Si une valeur null est attendue, la réponse peut être envoyée à un autre nœud lorsque l’instance dispose de plusieurs nœuds.
    		 L’administrateur IdP doit confirmer que la réponse SAML attendue est renvoyée. Il peut s’agir d’un problème d’équilibreur de charge ou d’infrastructure.
    Valeur SessionIndex 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 de l’objet. N. A. Des conditions peuvent être manquantes en raison d’une erreur sur l’IdP.

    Le StatusCode de la réponse contient Répondeur au lieu de la valeur Succès attendu.

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

    Les données de confirmation d’objet valides peuvent être expirées ou non destinées à la bonne audience.

    Incohérence de l’audience d’assertion. Attendu : <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 d’audience configurée pour 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. Attendu : <valeur sur l’instance>, réel : <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 d’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 (URL du fournisseur d’identité qui émet le jeton de sécurité SAML2 avec les informations de l’utilisateur) est définie correctement.

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

    ou

    L’objet a expiré. Maintenant : <now>, 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 du SP. Mettez à jour la propriété SAML glide.authenticate.sso.saml2.clockskew vers une valeur plus grande. La valeur par défaut est 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 du SP

    Mettez à jour la propriété SAML vers une valeur plus grande. 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 de connexion et d’IdP courantes
    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 de l’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 la propriété.
      Remarque :
      Pour en savoir plus sur cette propriété, consultez Liste d’autorisation d’URL pour les redirections de déconnexion 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 lequel 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 connaître les détails de 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 de journal système (syslog). Lorsque votre IdP (par exemple, ADFS) répond avec l’état oasis :names :tc :SAML :2.0 :status :Requester, cela signifie que l’IdP a rejeté 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 ne fournit pas plus de détails sur l’erreur. Examinez la demande SAML envoyée à l’IDP et collaborez avec l’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 connaître la raison de l’échec de la connexion.