Compartilhar via

Diagnosticar problemas de configurações de KCD (Delegação Restrita) do 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 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. Ele também aborda o diagnóstico de problemas de implementação mais complexos.

Este artigo faz as seguintes suposições.

  • Implantação do proxy de aplicativo do 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 da Microsoft do Kerberos.
  • 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 documento técnico do KCD .
  • O aplicativo é publicado em um tenant do Microsoft Entra com pré-autenticação habilitada. Espera-se que os usuários se autentiquem usando a autenticação baseada em formulários. Cenários avançados de autenticação de cliente não são abordados por este artigo.

Pré-requisitos

Configurações incorretas simples ou erros gerais causam a maioria dos problemas. Verifique todos os pré-requisitos em Usando a conexão única do KCD com o proxy do aplicativo antes de solucionar problemas.

Os hosts do 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.

Cenários entre domínios dependem de referências para direcionar um host de conector para controladores de domínio que estejam fora do perímetro da rede local. Nesses casos, é igualmente importante também enviar tráfego para controladores de domínio que representam outros domínios. Caso contrário, a delegação falhará.

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

Teste a delegação em cenários simples. Quanto mais variáveis você introduzir, mais poderá ter que lidar com elas. Para economizar tempo, limite o teste para 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 o teste. Por exemplo, ACLs (Listas de Controle de Acesso) de firewall interno configuradas incorretamente são comuns. Se possível, envie todo o tráfego de um conector diretamente para os controladores de domínio e para o aplicativo de back-end.

O melhor lugar para posicionar conectores é o mais próximo possível de seus destinos. Um firewall que fica embutido durante o teste adiciona complexidade desnecessária e pode prolongar as investigações.

O que mostra um problema de 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 mostrando um exemplo de erro de configuração incorreta de KCD, com o erro

exemplo: falha na autorização devido a permissões ausentes

Ambas as imagens mostram o mesmo sintoma: falha de autenticação única. O acesso do usuário ao aplicativo é negado.

Solução de problemas

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

Autenticação prévia do cliente

O usuário externo autenticando por meio 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 aborde essa habilidade se houver algum problema. O estágio de pré-autenticação não está relacionado ao KCD ou ao aplicativo publicado. É fácil corrigir todas as discrepâncias verificando se a conta do assunto existe na ID do Microsoft Entra. Verifique se o aplicativo não está desabilitado 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 do Kerberos para usuários de um Centro de Distribuição de Chaves (KCD) do Kerberos.

As comunicações externas entre o cliente e o front-end do Azure não têm nenhuma influência no KCD. Essas comunicações só garantem que o KCD funcione. O serviço de proxy do aplicativo recebe um ID de usuário válido que é usado para obter um tíquete Kerberos. Sem essa 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 campos activity ID e timestamp na resposta. As informações ajudam a correlacionar o comportamento a eventos reais no log de eventos do proxy de aplicativo.

exemplo: erro de configuração KCD incorreto

As entradas correspondentes vistas no log de eventos são mostradas como eventos 13019 ou 12027. Você pode encontrar os logs de eventos do conector em Logs de Aplicativos e Serviços>Microsoft>Rede privada Microsoft Entra>Conector>Admin.

  1. Use um registro A em seu DNS (Sistema de Nomes de Domínio) interno para o endereço do aplicativo, não um CName.
  2. Reconfirme se o host do conector tem o direito de delegar o nome da entidade de serviço (SPN) da conta de destino designada. Confirme novamente que Usar qualquer protocolo de autenticação está selecionado. Para obter mais informações sobre este tópico, consulte o artigo de configuração de SSO.
  3. Verifique se existe apenas uma instância do SPN no Microsoft Entra ID. Problema setspn -x em um prompt de comando em qualquer host de membro do domínio.
  4. Verifique se uma política de domínio é aplicada que limita o tamanho máximo de tokens Kerberos emitidos. A política impede que o conector receba um token se for excessivo.

Um rastreamento de rede que captura trocas entre o host do conector e um domínio Kerberos Constrained Delegation (KDC) é a próxima melhor etapa para obter mais detalhes de baixo nível sobre os problemas. Para obter mais informações, consulte aprofundamento do papel de solução de problemas.

Se o tíquete parece bom, você verá um evento nos logs, indicando que a autenticação falhou devido ao aplicativo que retorna um 401. Esse evento indica que o aplicativo de destino rejeitou seu tíquete. Vá para o próximo estágio.

Aplicativo de destino

O consumidor do ticket Kerberos fornecido pelo conector. Nessa fase, espera-se que o conector envie um bilhete de serviço Kerberos para o back-end. O ticket é um cabeçalho na primeira solicitação do 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 conectar-se com êxito. Os detalhes podem ser encontrados na página de Solução de problemas do conector.

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

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

    • O próximo blob Kerberos que é retornado na resposta do navegador para o aplicativo começa com YII. Essas letras indicam que o Kerberos está em execução. O Microsoft NT LAN Manager (NTLM), por outro lado, sempre começa com TlRMTVNTUAAB, que lê o Provedor de Suporte de Segurança NTLM (NTLMSSP) quando decodificado da Base64. Se você vir TlRMTVNTUAAB no início do blob, o Kerberos não estará disponível. Se você não vê TIRMTVNTUAAB, é provável que o Kerberos esteja 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, 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. O 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 Kerberos não estiver disponível, verifique as configurações de autenticação do aplicativo no IIS. Certifique-se de que Negotiate está listado na parte superior, com NTLM logo abaixo. Se você vir Sem Negotiate, Kerberos ou Negotiate, ou PKU2U, continue somente se o Kerberos estiver funcionando.

      provedores de autenticação do Windows

    • Com Kerberos e NTLM em vigor, desabilite temporariamente a pré-autenticação para o aplicativo no portal. Tente acessá-lo da Internet usando a URL externa. É solicitado que você se autentique. Você pode fazer isso com a mesma conta usada na etapa anterior. Caso contrário, há um problema com o aplicativo de back-end, não com o KCD.

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

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

      mostra o erro HTTP 401 proibido

    • 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 de aplicativo do IIS

      Depois de saber a identidade, verifique se essa conta está configurada com o SPN em questão. Um exemplo é setspn –q http/spn.wacketywack.com. Insira o texto a seguir 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. Verifique se o mesmo SPN configurado na conta de destino do Microsoft Entra é usado pelo pool de aplicativos do aplicativo.

    • Acesse 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 de UseAppPoolCredentials é True.

      Opção de credencial de pools de aplicativo da configuração do IIS

      Altere o valor para True. Remova todos os tíquetes Kerberos armazenados em cache do servidor de 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 habilitado, ele melhorará o desempenho das operações Kerberos. Mas isso também faz com que o tíquete para o serviço solicitado seja descriptografado usando a conta do computador. Essa conta também é chamada de sistema local. Defina esse valor como True para interromper o KCD quando o aplicativo estiver hospedado em mais de um servidor em um farm.

  • Como outra verificação, desabilite também a proteção Estendida. Em alguns cenários, a proteção Estendida interrompeu o KCD quando ele foi habilitado em configurações específicas. Nesses casos, um aplicativo foi publicado como uma subpasta do site padrão. Este aplicativo é configurado apenas para autenticação anônima. As caixas de diálogo estão esmaecidas, sugerindo que os objetos filho não herdam as configurações ativas. É recomendável que você teste, mas não se esqueça de restaurar esse valor para habilitado, sempre que possível.

    Essa verificação extra coloca você no caminho certo para usar seu aplicativo publicado. Você pode ativar mais conectores que também estão configurados para delegar. Para obter mais informações, leia o passo a passo técnico mais aprofundado, Solução de problemas do proxy de aplicativo do Microsoft Entra.

Se você ainda não conseguir progredir, o suporte da Microsoft poderá ajudá-lo. Crie um tíquete de suporte diretamente dentro do portal.

Outros cenários

O proxy de aplicativo do Microsoft Entra solicita um tíquete do Kerberos antes de enviar a solicitação dele para um aplicativo. Alguns aplicativos não gostam desse método de autenticação. Esses aplicativos esperam que as negociações mais convencionais ocorram. A primeira solicitação é anônima, o que permite que o aplicativo responda com os tipos de autenticação compatíveis por meio de um 401. Esse tipo de negociação Kerberos pode ser habilitado com as etapas descritas neste documento: Delegação Restrita Kerberos para logon único.

A autenticação de múltiplos saltos é comumente usada em cenários onde uma aplicação está estruturada em camadas. As camadas incluem um backend e um frontend. Ambas as camadas exigem autenticação. Por exemplo, SQL Server Reporting Services. Para obter mais informações, consulte Como configurar a delegação restrita do Kerberos para páginas de proxy de registro na Web.

Próximas etapas

Configurar o KCD em um domínio gerenciado.