Correções e erros de Multi-SSO (SAML 2.0)

  • Versão de lançamento: Xanadu
  • Atualizado 1 de ago. de 2024
  • 5 min. de leitura

    • Uma lista de erros comuns e correções associadas para uma instalação e configuração de Multi-SSO (SAML 2.0).

    Tabela 1. Erros durante a configuração de Multi-SSO (SAML 2.0)
    Erro nos logs de instância Mensagem do Testar conexão Propriedade SAML Diagnóstico Correção
    NotAfter: <Thu Jun 05 22:57:44 PDT 2014>. Certifique-se de que o certificado x509 do IDP esteja presente, válido e ativo. N/D O certificado atual ou a declaração SAML expirou.
    • Sincronize o relógio do SNC com o relógio do servidor IdP do SAML.
    • Atualize o registro do certificado SAML 2.0.
    • Impossível localizar o certificado SAML 2.0.
    • Não foi possível encontrar uma assinatura digital armazenada na instância da ServiceNow.
    		 Certifique-se de que o certificado x509 do IDP esteja presente, válido e ativo A cadeia de caracteres no formato PEM deve ser inserida no campo "Certificado PEM". O certificado SAML não existe. Ele pode estar inativo. Certifique-se de que o certificado no formato PEM correto seja carregado para a instância.
    Os certificados não coincidem. Esperado: <certStr>, vigente: <inboundCert>. Certifique-se de que o certificado x509 do IDP esteja presente, válido e ativo. N/D O certificado disponível no SNC não corresponde ao certificado na declaração. As causas incluem:
    • O certificado é atualizado no IdP, mas não na instância da ServiceNow.
    • O certificado está no formato incorreto.
    		 Confirme se a cadeia de caracteres no formato PEM no registro do certificado SAML 2.0 corresponde ao Certificado X509 no SAMLResponse do IdP do usuário.
    Falha ao verificar a validade do certificado. Certifique-se de que o certificado x509 do IDP esteja presente, válido e ativo N/D O certificado atual pode ter expirado. Atualize o registro do certificado SAML 2.0.
    Falha ao validar o perfil de assinatura. Certifique-se de que o certificado x509 do IDP esteja presente, válido e ativo. N/D A declaração pode ter sido assinada com um certificado diferente. Verifique se o IdP tem o mesmo certificado que a instância do SNC.
    Incompatibilidade do atributo "InResponseTo" no "SubjectConfirmationData". Esperado: <inResponseTo>, vigente: <inResponseTo>. Falha na validação da confirmação do assunto. N/D Este erro aparecerá se ocorrer uma das seguintes situações:
    • O IdP retorna um SAMLResponse para um SAMLRequest diferente
    • Um usuário marca como favorito o URL com o SAMLRequest em vez de apenas o URL da instância
    • Se um valor nulo for esperado, a resposta poderá ser enviada para um nó diferente quando a instância tiver vários nós.
    		 O administrador do IdP deve confirmar que o SAMLReponse esperado está sendo retornado. Esta situação pode ser um balanceador de carga ou problema de infraestrutura.
    Valor da "SessionIndex" não encontrado: <message>... "SessionIndex" não é válido. N/D O "SessionIndex" é necessário na instância SNC. O IdP o retorna na resposta do SAML para fazer uma autenticação bem-sucedida.

    O administrador do IdP deve confirmar se o "SessionIndex" está definido no SAMLResponse.
    Não foram encontrados "SubjectConfirmation" válidos. Falha na validação da confirmação do assunto. N/D As condições podem estar ausentes devido a um erro no IdP.

    O StatusCode na resposta conteria o Respondente em vez do Êxito esperado.

    Analise o SAMLResponse para determinar se as condições estão incluídas no SAMLResponse.

    Os dados de confirmação do assunto válidos podem estar expirados ou não para o público-alvo correto.

    Incompatibilidade de público-alvo de declaração. Esperado: <propAudience>, vigente: <audienceUri>.

    ou

    Falha na validação de AudienceRestriction. Nenhum público-alvo correspondente encontrado.

    		 Certifique-se de que o campo "URI do público-alvo" esteja configurado corretamente. O URI do público-alvo que aceita o token SAML2. (Normalmente, é o URI da sua instância. Por exemplo: https://demo.service-now.com.) O URI do público-alvo configurado da instância do SNC deve corresponder ao valor no IdP. Localizar <saml2:Audience> no SAMLResponse nos logs e verifique se o valor corresponde ao da instância.
    O emissor da declaração é inválido. Esperado: <value on instance>, vigente: <value returned by IdP> O emissor da declaração é inválido. O URL Provedor de identidade que emite o token de segurança SAML2 com a informação do usuário. O ID da entidade IdP (emissor) não corresponde ao valor definido na instância do SNC.
    • Verifique se o IdP ou o SP está configurado corretamente.
    • Confirme se a propriedade SAML (O URL Provedor de identidade que emite o token de segurança SAML2 com a informação do usuário) está configurada corretamente.

    O assunto é válido no futuro. Agora: <now>, NotBefore: <notBefore>

    ou

    Assunto expirado. Agora: <now>, NotOnOrAfter: <notOnOrAfter>

    		 Falha na validação da confirmação do assunto. O número, em segundos, antes da restrição "notBefore" ou após a restrição "notOnOrAfter", para ainda ser considerado válido. O relógio do IdP não está sincronizado com o relógio do SP. Atualize a propriedade SAML "glide.authenticate.sso.saml2.clockskew" para um valor maior. O padrão é de 180 segundos. Alguns casos exigem uma configuração de 300 ou superior. Também pode ser necessário verificar a hora no servidor IdP.

    A estipulação será válida no futuro, agora: <now>, notBefore: <notBefore>

    ou

    A estipulação perdeu a validade, agora: <now>, notOnOrAfter: <notOnOrAfter>

    		 A confirmação é inválida. O número, em segundos, antes da restrição "notBefore" ou após a restrição "notOnOrAfter", para ainda ser considerado válido. O relógio do IdP não está sincronizado com o relógio do SP

    Atualize a propriedade SAML para um valor maior. O padrão é de 60 segundos. Alguns casos exigem uma configuração de 300 ou superior. Também pode ser necessário verificar a hora no servidor IdP.
    Tabela 2. Erros comuns de login e IdP
    Erro ou sintoma Diagnóstico Correção
    As solicitações de login geram um loop infinito entre o sistema e o IdP quando a Alta segurança está ativa.
    • Normalmente, o endpoint do URL é uma página de erro ou de logout.
    • O "logout_redirect.do" pode criar esse loop quando você define glide.security.url.whitelist sem adicionar o nome do host IdP ao valor da propriedade.
      Nota:
      Para aprender mais sobre essa propriedade, consulte Lista de permissões de URL para redirecionamentos de logout nas Configurações de proteção de segurança de instância.
    		 Defina (ou crie) a propriedade do sistema "glide.authenticate.failed_redirect" para redirecionar as solicitações de autenticação com falha para esse URL.
    O token usado para autenticar o usuário ou a solicitação é assinado com o algoritmo de assinatura "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256", que não é o algoritmo de assinatura esperado "http://www.w3.org/2000/09/xmldsig#rsa-sha1". Verifique a guia "Contexto" do alerta para obter detalhes do evento. Navegue até a guia "Avançado" da caixa de diálogo de configuração "Objeto de confiança de terceira parte confiável" e verifique se o algoritmo está definido como SHA-1 e não SHA-256.
    A mensagem de erro urn:oasis:names:tc:SAML:2.0:status:Requester aparece na sua tabela de log do sistema (syslog). Quando seu IdP (por exemplo, ADFS) responde com um status de oasis:names:tc:SAML:2.0:status:Requester, isso significa que o IdP rejeitou o login devido a um problema com a solicitação enviada para ele. Infelizmente, a resposta SAML recebida do IdP não fornece mais detalhes sobre o erro. Analise a solicitação SAML enviada ao IDP e trabalhe com o administrador do IDP para atualizar as configurações SAML da sua instância para evitar o erro. Pode ser necessário entrar em contato com o provedor de IDP para entender o motivo da falha de login.