Partilhar via

Solucionar problemas de configurações de KCD (Delegação Restrita de Kerberos) com o proxy de aplicativo Microsoft Entra

  • Artigo

Os métodos de logon único variam de um aplicativo para outro. O proxy de aplicativo Microsoft Entra fornece Delegação Restrita de Kerberos (KCD) por padrão. Os usuários se autenticam em aplicativos privados usando Kerberos.

Este artigo fornece um único ponto de referência para solucionar os problemas mais comuns. Também abrange o diagnóstico de problemas de implementação mais complexos.

Este artigo faz as seguintes suposições.

  • Implantação de proxy de aplicativo Microsoft Entra e acesso geral a aplicativos não-KCD. Para obter mais informações, consulte Introdução ao proxy de aplicativo.
  • O aplicativo publicado é baseado no IIS (Serviços de Informações da Internet) e na implementação do Kerberos pela Microsoft.
  • Os hosts de servidor e aplicativo residem em um único domínio do Microsoft Entra. Para obter mais informações sobre cenários entre domínios e florestas, consulte o white paper do KCD.
  • O aplicativo é publicado em um locatário do Microsoft Entra com a pré-autenticação habilitada. Espera-se que os usuários se autentiquem usando a autenticação baseada em formulários. Os cenários de autenticação de cliente avançado não são abordados por este artigo.

Pré-requisitos

Erros simples de configuração ou erros gerais causam a maioria dos problemas. Verifique todos os pré-requisitos em Usando o logon único do KCD com o proxy do aplicativo antes de solucionar problemas.

Os hosts de conector não estão restritos à comunicação apenas com um controlador de domínio (DC) de site local específico. Verifique o DC que está sendo usado, pois ele pode mudar.

Os cenários entre domínios dependem de referências que direcionam um host de conector para DCs que podem estar fora do perímetro da rede local. Nesses casos, é igualmente importante enviar o tráfego para DCs que representam outros domínios. Caso contrário, a delegação falha.

Evite dispositivos ativos de Sistema de Prevenção de Intrusão (IPS) ou Sistema de Deteção de Intrusão (IDS) entre hosts de conectores e DCs. Esses dispositivos são muito intrusivos e interferem no tráfego principal de RPC (Chamada de Procedimento Remoto).

Teste a delegação em cenários simples. Quanto mais variáveis você introduzir, mais você terá que lidar. Para economizar tempo, limite o teste a um único conector. Adicione mais conectores depois que o problema for resolvido.

Alguns fatores ambientais também podem contribuir para um problema. Para evitar esses fatores, minimize a arquitetura o máximo possível durante os testes. Por exemplo, ACLs (Listas de Controle de Acesso) de firewall interno mal configuradas são comuns. Se possível, envie todo o tráfego de um conector diretamente para os DCs e o aplicativo back-end.

O melhor lugar para posicionar conectores é o mais próximo possível de seus alvos. Um firewall que fica em linha durante os testes adiciona complexidade desnecessária e pode prolongar suas investigações.

O que mostra um problema KCD? Há várias indicações comuns de que o logon único do KCD está falhando. Os primeiros sinais de um problema aparecem no navegador.

Captura de tela que mostra um exemplo de um erro de configuração K C D incorreta, com o erro

Exemplo: Falha na autorização devido a permissões ausentes

Ambas as imagens mostram o mesmo sintoma: falha de logon único. O acesso do usuário ao aplicativo é negado.

Resolução de Problemas

Separe a solução de problemas nos três estágios.

Pré-autenticação do cliente

O usuário externo autenticando através de um navegador. A capacidade de pré-autenticação no Microsoft Entra ID é necessária para que o logon único (SSO) do KCD funcione. Teste e resolva essa capacidade se houver algum problema. O estágio de pré-autenticação não está relacionado ao KCD ou ao aplicativo publicado. É fácil corrigir quaisquer discrepâncias verificando se a conta de assunto existe no Microsoft Entra ID. Verifique se o aplicativo não foi desativado ou bloqueado. A resposta de erro no navegador é descritiva o suficiente para explicar a causa.

Serviço de delegação

O conector de rede privada que obtém um tíquete de serviço Kerberos para usuários de um Centro de Distribuição de Chaves Kerberos (KCD).

As comunicações externas entre o cliente e o front-end do Azure não têm influência no KCD. Estas comunicações apenas garantem que o KCD funciona. O serviço de proxy de aplicativo é fornecido um ID de usuário válido que é usado para obter um tíquete Kerberos. Sem este ID, o KCD não é possível e falha.

As mensagens de erro do navegador fornecem algumas boas pistas sobre por que as coisas falham. Registre os activity ID campos e timestamp na resposta. As informações ajudam a correlacionar o comportamento com eventos reais no log de eventos do proxy do aplicativo.

Exemplo: Erro de configuração incorreta do KCD

As entradas correspondentes vistas no log de eventos mostram como eventos 13019 ou 12027. Localize os logs de eventos do conector em Logs de Aplicativos>e Serviços Microsoft>Microsoft Entra rede>privada Connector>Admin.

  1. Use um registro A em seu Sistema de Nomes de Domínio (DNS) interno para o endereço do aplicativo, não um CNamearquivo .
  2. Reconfirme se o host do conector tem o direito de delegar ao SPN (Nome da Entidade de Serviço) da conta de destino designada. Confirme novamente se a opção Usar qualquer protocolo de autenticação está selecionada. Para obter mais informações, consulte o artigo de configuração de SSO.
  3. Verifique se existe apenas uma instância do SPN no Microsoft Entra ID. Emissão setspn -x a partir de um prompt de comando em qualquer host membro do domínio.
  4. Verifique se foi imposta uma política de domínio que limite o tamanho máximo dos tokens Kerberos emitidos. A política impede que o conector obtenha um token se ele for excessivo.

Um rastreamento de rede que captura trocas entre o host do conector e uma delegação restrita de Kerberos (KDC) de domínio é a próxima melhor etapa para obter mais detalhes de baixo nível sobre os problemas. Para obter mais informações, consulte o documento Solucionar problemas detalhado.

Se o tíquete parecer bom, você verá um evento nos logs informando que a autenticação falhou porque o aplicativo retornou um 401. Este evento indica que a candidatura de destino rejeitou o seu bilhete. Passe para a próxima fase.

Aplicação de destino

O consumidor do tíquete Kerberos fornecido pelo conector. Nesta etapa, espere que o conector envie um tíquete de serviço Kerberos para o back-end. O ticket é um cabeçalho na primeira solicitação de aplicativo.

  1. Usando a URL interna do aplicativo definida no portal, valide se o aplicativo está acessível diretamente do navegador no host do conector. Em seguida, você pode entrar com êxito. Os detalhes podem ser encontrados na página Solução de problemas do conector.

  2. Confirme se a autenticação entre o navegador e o aplicativo usa Kerberos.

  3. Execute DevTools (F12) no Internet Explorer ou use o Fiddler a partir do host do conector. Vá para o aplicativo usando a URL interna. Para certificar-se de que negociar ou Kerberos está presente, inspecione os cabeçalhos de autorização da Web oferecidos retornados na resposta do aplicativo.

    • O próximo blob Kerberos retornado na resposta do navegador ao aplicativo começa com YII. Essas cartas informam que o Kerberos está em execução. Microsoft NT LAN Manager (NTLM), por outro lado, sempre começa com TlRMTVNTUAAB, que lê NTLM Security Support Provider (NTLMSSP) quando decodificado de Base64. Se você vir TlRMTVNTUAAB no início do blob, Kerberos não está disponível. Se você não vir TlRMTVNTUAAB, Kerberos provavelmente está disponível.

      Nota

      Se você usar o Fiddler, esse método exigirá que você desabilite temporariamente a proteção estendida na configuração do aplicativo no IIS.

      Janela de inspeção de rede do navegador

    • O blob nesta figura não começa com TIRMTVNTUAAB. Portanto, neste exemplo, o Kerberos está disponível e o blob Kerberos não começa com YII.

  4. Remova temporariamente o NTLM da lista de provedores no site do IIS. Acesse o aplicativo diretamente do Internet Explorer no host do conector. NTLM não está mais na lista de provedores. Você pode acessar o aplicativo usando apenas Kerberos. Se o acesso falhar, pode haver um problema com a configuração do aplicativo. A autenticação Kerberos não está funcionando.

    • Se o Kerberos não estiver disponível, verifique as configurações de autenticação do aplicativo no IIS. Verifique se Negociar está listado na parte superior, com NTLM logo abaixo dele. Se você vir Não negociar, Kerberos ou Negociar, ou PKU2U, continue somente se Kerberos estiver funcional.

      Provedores de autenticação do Windows

    • Com Kerberos e NTLM em vigor, desative temporariamente a pré-autenticação para o aplicativo no portal. Tente acessá-lo a partir da Internet usando o URL externo. Você será solicitado a autenticar. Você pode fazer isso com a mesma conta usada na etapa anterior. Se não, há um problema com o aplicativo back-end, não com o KCD.

    • Reative a pré-autenticação no portal. Autentique-se através do Azure tentando conectar-se ao aplicativo por meio de sua URL externa. Se o SSO falhar, você verá uma mensagem de erro proibida no navegador e o evento 13022 no log:

      O conector de rede privada Microsoft Entra não pode autenticar o usuário porque o servidor back-end responde às tentativas de autenticação Kerberos com um erro HTTP 401.

      Mostra o erro proibido HTTTP 401

    • Verifique o aplicativo IIS. Verifique se o pool de aplicativos configurado e o SPN estão configurados para usar a mesma conta na ID do Microsoft Entra. Navegue no IIS conforme mostrado na ilustração a seguir.

      Janela de configuração do aplicativo IIS

      Depois de saber a identidade, certifique-se de que esta conta está configurada com o SPN em questão. Um exemplo é setspn –q http/spn.wacketywack.com. Digite o seguinte texto em um prompt de comando.

      Mostra a janela de comando SetSPN

    • Verifique o SPN definido em relação às configurações do aplicativo no portal. Certifique-se de que o mesmo SPN configurado em relação à conta Microsoft Entra de destino é usado pelo pool de aplicativos do aplicativo.

    • Vá para o IIS e selecione a opção Editor de configuração para o aplicativo. Navegue até system.webServer/security/authentication/windowsAuthentication. Verifique se o valor UseAppPoolCredentials é True.

      Opção de credenciais de pools de aplicativos de configuração do IIS

      Altere o valor para True. Remova todos os tíquetes Kerberos armazenados em cache do servidor back-end executando o comando.

      Get-WmiObject Win32_LogonSession | Where-Object {$_.AuthenticationPackage -ne 'NTLM'} | ForEach-Object {klist.exe purge -li ([Convert]::ToString($_.LogonId, 16))}

Se você deixar o modo Kernel ativado, ele melhorará o desempenho das operações Kerberos. Mas também faz com que o ticket para o serviço solicitado seja descriptografado usando a conta da máquina. Essa conta também é chamada de sistema local. Defina esse valor como True para quebrar o KCD quando o aplicativo estiver hospedado em mais de um servidor em um farm.

  • Como outra verificação, desative a proteção estendida também. Em alguns cenários, a proteção estendida quebrou o KCD quando foi habilitada em configurações específicas. Nesses casos, um aplicativo foi publicado como uma subpasta do site padrão. Esta aplicação está configurada apenas para autenticação anónima. Todas as caixas de diálogo estão acinzentadas, o que sugere que os objetos filho não herdariam nenhuma configuração ativa. Recomendamos que você teste, mas não se esqueça de restaurar esse valor para ativado, sempre que possível.

    Esta verificação extra coloca-o no caminho certo para utilizar a sua aplicação publicada. Você pode girar mais conectores que também estão configurados para delegar. Para obter mais informações, leia o passo a passo técnico mais detalhado, Solucionando problemas do proxy de aplicativo Microsoft Entra.

Se você ainda não conseguir progredir, o suporte da Microsoft poderá ajudá-lo. Crie um ticket de suporte diretamente no portal.

Outros cenários

O proxy de aplicativo Microsoft Entra solicita um tíquete Kerberos antes de enviar sua solicitação para um aplicativo. Alguns aplicativos não gostam desse método de autenticação. Estas candidaturas esperam que as negociações mais convencionais se realizem. O primeiro pedido é anónimo, o que permite que a aplicação responda com os tipos de autenticação que suporta através de um 401. Esse tipo de negociação Kerberos pode ser habilitado usando as etapas descritas neste documento: Delegação restrita de Kerberos para logon único.

A autenticação multi-hop é comumente usada em cenários em que um aplicativo é hierárquico. As camadas incluem um back-end e um front-end. Ambos os níveis exigem autenticação. Por exemplo, SQL Server Reporting Services. Para obter mais informações, consulte Como configurar a delegação restrita de Kerberos para páginas proxy de registro na Web.

Próximos passos

Configure o KCD em um domínio gerenciado.