Solucionar problemas de configurações de Delegação Restrita Kerberos (KCD) com proxy de aplicativo Microsoft Entra
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.
Esse 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.
Esse artigo faz as seguintes suposições.
- Implantação do proxy de aplicativo Microsoft Entra e acesso geral a aplicativos não KCD. Para obter mais informações, veja Introdução ao proxy de aplicativo.
- O aplicativo publicado é baseado no Internet Information Services (IIS) e na implementação do Kerberos pela Microsoft.
- Os hosts de servidores e aplicativos residem em um único domínio Microsoft Entra. Para obter mais informações sobre cenários entre domínios e florestas, veja white paper KCD.
- O aplicativo é publicado em um locatário Microsoft Entra ID com pré-autenticação habilitada. Espera-se que os usuários se autentiquem usando autenticação baseada em formulários. Cenários de autenticação de cliente avançados não são cobertos por este artigo.
Pré-requisitos
Pequenos erros de configuração ou erros gerais são o que causam a maior parte 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 falha.
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 principal de Chamada de Procedimento Remoto (RPC).
Teste a delegação em cenários simples. Quanto mais variáveis você introduzir, com mais você pode ter que lidar. Para economizar tempo, limite o teste a um único conector. Adicione mais conectores depois que o problema for resolvido.
Alguns fatores relacionados ao ambiente também podem estar contribuindo para um problema. Para evitar esses fatores, minimize a arquitetura o máximo possível durante o teste. Por exemplo, listas de controle de acesso (ACLs) de firewall interno mal configuradas 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 local para posicionar os 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 do 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.
Ambas as imagens mostram o mesmo sintoma: falha de logon único. O acesso do usuário ao aplicativo foi negado.
Solução de problemas
Separe a solução de problemas em três estágios.
Pré-autenticação do cliente
O usuário externo autenticado 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 corrija esse recurso 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 do assunto existe no Microsoft Entra ID. Verifique se o aplicativo não está desativado ou bloqueado. A resposta de erro no navegador é normalmente 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 tem nenhuma influência sobre o KCD. Essas comunicações apenas garantem que o KCD funciona. 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 com eventos reais no log de eventos do proxy do aplicativo.
As entradas correspondentes visualizadas no log de eventos seriam os 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.
- Use um registro A em seu Sistema de Nomes de Domínio (DNS) interno para o endereço do aplicativo, não um
CName. - 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.
- Verifique se há apenas uma instância do SPN existente no Microsoft Entra ID. Problema
setspn -xem um prompt de comando em qualquer host de membro do domínio. - 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 o tíquete. Ir para o estágio seguinte.
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.
Usando a URL do aplicativo interno definida no portal, valide que o aplicativo é 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.
Confirme se a autenticação entre o navegador e o aplicativo usa Kerberos.
Execute as ferramentas de desenvolvimento (F12) no Internet Explorer, ou use Fiddler do host de 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.
Observação
Se você usa o Fiddler, esse método requer que você desabilite temporariamente a proteção estendida na configuração do aplicativo no IIS.
O blob nesta figura não começa com TIRMTVNTUAAB. Portanto, neste exemplo, o Kerberos está disponível e o blob de Kerberos não começa com YII.
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 somente o 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. 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.
Com o Kerberos e o NTLM implementados, desabilite temporariamente a pré-autenticação do aplicativo no portal. Tente acessar pela Internet usando a URL externa. Você será solicitado a autenticar. 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 KCD.
Re habilitar 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 de proibido do navegador, além do 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.
Verificar o aplicativo IIS. Certifique-se de que o pool de aplicativos configurado e o SPN estão configurados para usar a mesma conta no Microsoft Entra ID. Navegue no IIS conforme mostrado na ilustração a seguir.
Depois que você sabe a identidade, verifique se essa conta é configurada com o SPN em questão. Um exemplo é
setspn –q http/spn.wacketywack.com. Digite o seguinte texto em um prompt de comando.
Verifique o SPN definido nas configurações do aplicativo no portal. Certifique-se de que o mesmo SPN configurado em relação à conta de destino do Microsoft Entra seja 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 de UseAppPoolCredentials é True.
Altere o valor para Verdadeiro. Remova todos os tickets Kerberos armazenados em cache do servidor backend executando o comando.
Get-WmiObject Win32_LogonSession | Where-Object {$_.AuthenticationPackage -ne 'NTLM'} | ForEach-Object {klist.exe purge -li ([Convert]::ToString($_.LogonId, 16))}
Se você sair do modo de Kernel habilitado, ele melhora o desempenho de operações do 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 é 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 está configurado somente 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 detalhado mais técnico, Solução de problemas do proxy de aplicativo do Azure AD.
Se você ainda não conseguir progredir, o suporte da Microsoft pode 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, e permite que o aplicativo responda com os tipos de autenticação que ele oferece suporte através 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 multi-hop é comumente usada em cenários em que um aplicativo está em camadas. As camadas incluem um back-end e um front-end. Ambas as camadas requerem autenticação. Por exemplo, SQL Server Reporting Services. Para obter mais informações, veja Como configurar a delegação restrita Kerberos para páginas proxy de inscrição na Web.