Solucionar problemas de delegação restrita de Kerberos

Os métodos de SSO (logon único) variam entre aplicativos. O proxy de aplicativo Microsoft Entra fornece delegação restrita Kerberos (KCD) por padrão. No proxy de aplicativo, um usuário se autentica em um aplicativo privado usando Kerberos.

Este artigo descreve como solucionar os problemas mais comuns na configuração do KCD. Ele inclui etapas de diagnóstico que você pode executar para implementações mais complexas.

Este artigo pressupõe o seguinte:

• O proxy de aplicativo do Microsoft Entra é implantado e tem acesso amplo a aplicativos não baseados em KCD.

  Para obter mais informações, consulte Introdução ao proxy de aplicativo.

• Um aplicativo publicado é baseado no IIS (Serviços de Informações da Internet) e na implementação da Microsoft do Kerberos.

• Os hosts de servidor e aplicativo estão 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 Noções básicas sobre a delegação restrita Kerberos com o proxy de aplicativo.

• O aplicativo é publicado em uma instância 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 de autenticação de cliente avançado não são abordados neste artigo.

Considerações

A lista a seguir descreve considerações fundamentais para configuração de KCD e uso com o proxy de aplicativo do Microsoft Entra:

• Configurações incorretas básicas ou erros gerais causam a maioria dos problemas. Antes de começar a solucionar problemas, verifique todos os pré-requisitos no Uso do SSO do KCD com o proxy de aplicativo.

• Os hosts do conector não são limitados a se comunicarem apenas com um controlador de domínio local específico (DC). Verifique o DC que você usa porque 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 enviar tráfego para controladores de domínio que representam outros domínios. Se você não fizer isso, a delegação falhará.

• Evite utilizar dispositivos ativos de IPS (Sistema de Prevenção de Intrusão) ou IDS (Sistema de Detecção de Intrusão) entre hosts conectores e controladores de domínio (DCs), devido à interferência no tráfego principal de Chamada de Procedimento Remoto (RPC).

• Teste a delegação em um cenário simples. Quanto mais variáveis você introduzir em um cenário, mais complexa será a configuração e a solução de problemas. Para economizar tempo, limite o teste para um único conector. Adicione mais conectores depois que o problema for resolvido.

• Fatores ambientais podem contribuir para a causa de 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) internas configuradas incorretamente são comuns. Se possível, envie diretamente todo o tráfego de um conector para os DCs 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 quando você testa o conector adiciona complexidade desnecessária e pode prolongar suas investigações.

• O que indica um problema de KCD? Vários erros comuns indicam que o SSO do KCD está falhando. Os primeiros sinais de um problema aparecem no navegador.

  Ambas as capturas de tela a seguir mostram o mesmo sintoma de falha de SSO: o acesso do usuário ao aplicativo é negado.

  

  

Solucionar problemas

Você pode solucionar problemas de KCD em três estágios. Verifique estas partes do processo KCD na seguinte ordem:

• Pré-autenticação do cliente
• O serviço de delegação
• O aplicativo de destino

Pré-autenticação do cliente

A pré-autenticação do cliente refere-se a um usuário externo autenticando em um aplicativo por meio de um navegador. A capacidade de pré-autenticar a ID do Microsoft Entra é necessária para que o SSO do KCD funcione.

Teste a pré-autenticação do cliente primeiro e resolva os problemas. O estágio de pré-autenticação não está relacionado ao KCD nem 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á indisponível ou bloqueado. A resposta de erro no navegador normalmente é descritiva o suficiente para explicar a causa.

O serviço de delegação

O serviço de delegação Kerberos é o conector de rede privado que obtém um tíquete de serviço Kerberos de um KDC (Centro de Distribuição de Chaves Kerberos). O usuário do aplicativo se autentica no sistema por meio do tíquete.

As comunicações externas entre o cliente e o front-end do Azure não têm efeito sobre a delegação restrita. Essas comunicações garantem apenas que o KCD funcione. O serviço de proxy de aplicativo recebe uma ID de usuário válida que obtém um tíquete Kerberos. Sem essa ID, o KCD não pode ocorrer e o SSO falha.

As mensagens de erro do navegador fornecem informações úteis sobre por que a entrada falha. Registre os valores para TransactionID e Timestamp na resposta ao login do aplicativo. As informações ajudam a correlacionar o comportamento a eventos que aparecem no log de eventos do proxy de aplicativo.

As entradas correspondentes no log de eventos são IDs de evento 13019 ou 12027. Para exibir os logs de eventos do conector, acesse Logs de Aplicativos e Serviços>Microsoft>rede privada do Microsoft Entra>Conector>Administrador.

Como solucionar um problema de delegação restrita:

1. Em seu DNS (Sistema de Nomes de Domínio) interno para o endereço do aplicativo, use um registro A, não um registro CNAME.
2. Verifique se o host do conector está configurado com permissões para delegar ao SPN (nome da entidade de serviço) da conta de destino. Verifique se Usar qualquer protocolo de autenticação está selecionado. Para obter mais informações, consulte a configuração do SSO.
3. Verifique se existe apenas uma instância do SPN na ID do Microsoft Entra. Para verificar um único SPN, em um prompt de comando em qualquer host de membro de domínio, execute setspn -x.
4. Verifique se uma política de domínio que limita o tamanho máximo dos tokens Kerberos emitidos é imposta. A política impede que o conector tenha um token se o tamanho do token exceder um máximo definido.
5. Executar um rastreamento de rede que captura trocas entre o host do conector e um KCD de domínio é a próxima melhor etapa para obter mais detalhes sobre o problema. Para obter mais informações, você pode examinar o white paper detalhado Solucionando problemas do proxy de aplicativo do Microsoft Entra.

Se o sistema de bilhetagem estiver funcionando corretamente, os registros de log provavelmente mostrarão um evento que indica que a autenticação falhou porque o aplicativo retornou um erro 401. Este evento indica que o aplicativo alvo rejeitou o ticket. Vá para o próximo estágio de solução de problemas.

O aplicativo

O aplicativo alvo processa o ticket Kerberos fornecido pelo conector. Neste estágio, o conector inclui um tíquete de serviço Kerberos como um cabeçalho na primeira solicitação de aplicação para o back-end.

Para solucionar problemas de um aplicativo:

1. Verifique se o aplicativo está acessível. Efetue o login diretamente no navegador do host do conector usando a URL interna definida no portal do Azure. Se o login for bem-sucedido, o aplicativo estará acessível.

2. Verifique se o navegador e o aplicativo estão usando Kerberos para autenticação. No host do conector, use do DevTools do Internet Explorer (pressione F12) ou Fiddler para acessar o aplicativo usando a URL interna. Procure "Negotiate" ou "Kerberos" nos cabeçalhos de autorização web na resposta do aplicativo.

   A resposta do navegador ao aplicativo inclui um blob Kerberos que começa com YII, confirmando que Kerberos está em execução. Por outro lado, uma resposta do Microsoft NT LAN Manager (NTLM) sempre começa com TlRMTVNTUAAB. Quando decodificada do Base64, essa resposta é lida como Provedor de Suporte de Segurança NTLM (NTLMSSP). Se os blobs começarem com TlRMTVNTUAAB, Kerberos não estará disponível. Se isso não acontecer, Kerberos provavelmente estará disponível.

   Nota

   Se você usar o Fiddler, deverá desabilitar temporariamente a proteção estendida na configuração do aplicativo no IIS.

   

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

3. No site do IIS, remova temporariamente o NTLM da lista de provedores. Acesse o aplicativo diretamente do Internet Explorer no host do conector. O NTLM não está mais na lista de provedores, portanto, você só pode acessar o aplicativo usando Kerberos. Se o acesso falhar, um problema com a configuração do aplicativo será indicado. O aplicativo não está processando a autenticação Kerberos.

4. Se Kerberos não estiver disponível, verifique as configurações de autenticação do aplicativo no IIS. Verifique se o Negotiate está listado na parte superior e se o NTLM está logo abaixo dele. Se você vir Sem Negotiate, Kerberos ou Negotiate, ou PKU2U, continue somente se o Kerberos estiver funcionando.

   

5. Com o Kerberos e NTLM implementados, no portal, desabilite temporariamente a pré-autenticação para o aplicativo. Tente acessar o aplicativo em um navegador usando a URL externa. É solicitado que você se autentique. Use a mesma conta usada em uma etapa anterior. Se você não conseguir autenticar e entrar, haverá um problema com o aplicativo de back-end, não com o KCD.

6. 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 na ID do evento 13022 no log:

   Microsoft Entra private network connector can't authenticate the user because the backend server responds to Kerberos authentication attempts with an HTTP 401 error.

   

7. 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. No IIS, vá para a pasta, conforme mostrado na seguinte captura de tela:

   

   Verifique a identidade e verifique se essa conta está configurada com o SPN. Em um prompt de comando, por exemplo, execute setspn –q http/spn.contoso.com.

   

8. No portal, verifique o SPN definido nas configurações do aplicativo. Verifique se o pool de aplicativos do aplicativo usa o mesmo SPN definido para a conta de destino do Microsoft Entra.

9. No IIS, selecione a opção Editor de Configuração para o aplicativo. Acesse system.webServer/security/authentication/windowsAuthentication. Verifique se o valor de UseAppPoolCredentials é True.

   

   Altere o valor para True , se necessário. Remova todos os tíquetes Kerberos armazenados em cache do servidor de back-end executando o seguinte comando:

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

10. Se o modo Kernel estiver habilitado, as operações Kerberos apresentam melhorias. Mas o tíquete para o serviço solicitado também deve ser 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.

11. Como outra verificação, desabilite a proteção estendida. Em alguns cenários de teste, a proteção estendida quebrou 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. Todas as caixas de diálogo estão inativas, sem seleção disponível, o que sugere que os objetos secundários não herdariam nenhuma configuração ativa. Recomendamos que você teste, mas não se esqueça de restaurar esse valor para habilitado , se possível.

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

Se você ainda não conseguir resolver o problema de autenticação da aplicação, crie um ticket de suporte diretamente no portal.

Outros cenários

O proxy de aplicativo do Microsoft Entra solicita um tíquete Kerberos antes de enviar uma solicitação a um aplicativo. Alguns aplicativos não dão suporte a esse método de autenticação. Esses aplicativos são configurados para responder a etapas de autenticação mais convencionais. A primeira solicitação é anônima, o que permite que o aplicativo responda com os tipos de autenticação aos quais ele dá suporte por meio de um erro 401. Você pode configurar esse tipo de negociação Kerberos concluindo as etapas descritas na Delegação restrita Kerberos para SSO.

A autenticação em múltiplas etapas geralmente é usada quando um aplicativo possui várias camadas. As camadas incluem um back-end e um front-end. Ambas as camadas exigem autenticação. Por exemplo, você pode criar um aplicativo em camadas usando o 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.

Conteúdo relacionado

• Configurar o KCD em um domínio gerenciado