Erreurs et correctifs de l’authentification unique (SAML 2.0)

  • Rversion finale: Xanadu
  • Mis à jour 1 août 2024
  • 5 minutes de lecture

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

    Tableau 1. Erreurs lors de la configuration de l’authentification unique (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 x509 IDP 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 x509 IDP est présent, valide et actif La chaîne formatée 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>, réelle : <inboundCert>. Vérifiez que le certificat x509 IDP 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 n’est pas dans le bon format.
    		 Vérifiez que la chaîne formatée PEM dans l’enregistrement de certificat SAML 2.0 correspond au certificat X509 dans SAMLResponse pour l’IdP de l’utilisateur.
    Échec de la vérification de la validité du certificat. Vérifiez que le certificat x509 IDP 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 x509 IDP 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. Attendre : <inResponseTo>, réel : <inResponseTo>. Échec de la validation de la confirmation d’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 met en signet 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 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 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 Les conditions peuvent être manquantes en raison d’une erreur dans l’IdP.

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

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

    Les données valides de confirmation de l’objet peuvent être expirées ou non pour 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. (Normalement, il s’agit de votre URI d’instance. Par exemple : https://demo.service-now.com.) L’URI d’audience configuré pour l’instance SNC doit correspondre à la valeur dans 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> réelle : <valeur renvoyée par l’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 définie correctement.

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

    ou

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

    		 Échec de la confirmation de validation de l’objet. 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 du fournisseur de services. 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 cas nécessitent un réglage 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 du fournisseur de services

    Mettez à jour la propriété SAML sur une valeur plus grande. La valeur par défaut est de 60 secondes. Certains cas nécessitent un réglage 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 propriété.
      Remarque :
      Pour en savoir plus sur cette propriété, reportez-vous Liste d’autorisation d’URL pour les redirections de déconnexion à la section Paramètres de sécurisation renforcée de la sécurité de l’instance.
    		 Définissez (ou créez) le glide.authenticate.failed_redirect de propriété système pour rediriger les demandes ayant échoué à l’authentification 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 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 la table journal système (syslog). Lorsque votre IdP (par exemple, ADFS) répond avec un é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, 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 connaître la raison de l’échec de la connexion.