Páginas de diagnóstico para solução de problemas de Autenticação Integrada do Windows

A solução de problemas de cenários de falha da Autenticação Integrada do Windows pode ser desafiadora, especialmente quando você lida com a delegação de credenciais Kerberos. Embora haja uma lista de verificação detalhada sobre como garantir que você tenha a configuração correta para que o IIS (Serviços de Informações da Internet) funcione com a Autenticação Integrada do Windows e, opcionalmente, use a delegação de credenciais, este artigo visa especificamente os seguintes cenários:

• Você pode entrar no site de destino do computador cliente, mas não tem certeza se está usando NTLM ou Kerberos como mecanismo de autenticação.
• Você pode fazer login no site de destino, mas será solicitado a entrar somente depois de inserir uma combinação de nome de usuário e senha.
• Você pode acessar seu site de destino no servidor front-end, mas ele falha quando você inicia uma ação que exige que o servidor front-end chame um ponto de extremidade HTTP de back-end usando as credenciais do usuário autenticado.

Para os fins deste artigo, considere o seguinte layout:

• O Cliente 1 é a estação de trabalho ou laptop ingressado no domínio a partir do qual o usuário hipotético iniciará todas as tentativas de conexão.

• Web-serv1 é o servidor IIS front-end que hospeda um site ASP.NET (no .NET Framework) que usa a Autenticação Integrada do Windows e é executado usando a identidade de uma conta de serviço: domain\serviceaccount.

• Web-serv2 é o servidor Web de back-end que também hospeda um site ASP.NET (no .NET Framework) que exporá pontos de extremidade de API para o aplicativo front-end. Ele também é configurado para permitir solicitações que usam a Autenticação Integrada do Windows e são executadas em um pool de aplicativos que usa domain\serviceapiaccount como uma identidade do pool de aplicativos.

Para facilitar a coleta de dados para esses cenários e não depender de ferramentas externas de coleta de dados, como Fiddler ou WireShark (já que as conexões entre os três computadores podem usar HTTPS e, portanto, todas as trocas entre eles serão criptografadas), use as duas páginas de diagnóstico independentes em ASP.NET Páginas Independentes para solucionar problemas de Autenticação Integrada do Windows no IIS.

Páginas de solução de problemas

As duas páginas são codificadas em ASP.NET Web Forms. Eles se destinam a agrupar o código e a marcação da página em um arquivo que pode ser copiado para a raiz do aplicativo Web que você está tentando solucionar, sem a necessidade de compilação ou implantação. As páginas são:

• WhoAmI.aspx - Esta página permite o despejo de informações relacionadas à autenticação, como:

  • O método de autenticação usado para acessar o site de destino. Se o método for baseado no provedor Negotiate para Autenticação Integrada do Windows, a página mostrará se Kerberos ou NTLM é usado para autenticar o usuário.

  • A identidade da conta que executa o pool de aplicativos que hospeda o site.

  • O nível de representação do usuário autenticado. Se o Kerberos for usado para autenticação e a delegação de credenciais irrestritas for permitida, o nível de representação será marcado como delegado. Caso contrário, ele será marcado como representar no caso de delegação restrita ou representação simples.

  • A identidade do usuário autenticado e dos grupos aos quais o usuário pertence.

  • A identidade da conta que executa o código da página (pode ser um usuário autenticado ou um usuário do pool de aplicativos, dependendo das configurações de representação ).

  • Todos os valores dos cabeçalhos de solicitação para solicitações que entram na página WhoAmI.aspx são recuperados das variáveis do servidor IIS.

    

• ScrapperTest.aspx - Esta página é feita para funcionar com a página WhoAmI.aspx, permitindo que as solicitações do servidor front-end sejam direcionadas para qualquer URL no servidor back-end. A página apresenta uma interface de interface do usuário que permite ao usuário:

  • Insira a URL desejada do recurso de servidor back-end que a página deve tentar carregar.

  • Determine se eles estão autenticados ao carregar a página ScrapperTest.aspx e, se autenticados, como usuários eles estão autenticados.

  • No cenário em que o usuário está realmente autenticado, uma caixa de seleção permite a tentativa de reutilizar as credenciais do usuário ao tentar carregar o recurso de back-end indicado na caixa de texto URL.

    

Como implantar

Como ambas as páginas são independentes, a única coisa necessária é:

1. Baixe as páginas do repositório GitHub.
2. Copie a página WhoAmI.aspx ou ambas as páginas para a raiz dos aplicativos Web de destino que estão sendo executados dentro do IIS.
3. Faça uma solicitação para a URL do seu site anexando /WhoAmI.aspx ou /ScrapperTest.aspx, dependendo da página que você deseja acessar.

Uso

O primeiro cenário de uso é tentar determinar qual método de autenticação é usado para acessar um determinado site ou aplicativo Web hospedado no IIS. Para este, você pode fazer solicitações para a página WhoAmI.aspx que você implantou anteriormente no site.

• Na primeira solicitação, a página exibirá as informações de autenticação. Se o provedor de negociação para Autenticação Integrada do Windows for usado, ele também listará o protocolo de autenticação usado: Kerberos ou NTLM.

• As solicitações subsequentes em um cenário em que Negotiate é usado como o provedor da Autenticação Integrada do Windows exibirão apenas o rótulo Baseado em Sessão ao lado do tipo de autenticação. Para obter mais informações, consulte Autenticação Kerberos baseada em solicitação versus autenticação Kerberos baseada em sessão (ou o parâmetro AuthPersistNonNTLM).

• Todas as outras informações de autenticação, como o usuário do pool de aplicativos, o usuário autenticado, os detalhes do usuário de execução e os cabeçalhos da solicitação de entrada, serão exibidas em cada solicitação.

A página WhoAmI.aspx também exibe um pequeno formulário na parte inferior. Este formulário permite que você emita POST solicitações ao servidor para testar como o navegador se comporta ao emitir esses tipos de solicitações. Se a página ficar ociosa por mais de 60 segundos, a conexão TCP usada para baixar a página para o navegador e autenticada pelo servidor será interrompida devido à inatividade. Portanto, quando você faz uma POST solicitação, uma nova conexão TCP é aberta e você deve se autenticar novamente. Há uma sutileza com POST os pedidos:

1. O navegador primeiro envia os cabeçalhos de solicitação HTTP POST .
2. Em seguida, ele emite o corpo da POST solicitação, que contém as informações capturadas dos vários campos de entrada no formulário HTTP exibido na página.

Se o navegador não aguardar depois de enviar os POST cabeçalhos da solicitação, mas enviar o corpo diretamente em uma conexão não autenticada, os seguintes problemas poderão ocorrer:

• O servidor recebe os cabeçalhos de POST solicitação e, como a conexão não é autenticada (supondo que a Autenticação Integrada do Windows ou outra autenticação baseada em desafio seja usada), ele emite uma resposta 401 com o cabeçalho HTTP de resposta de autenticação apropriado (WWW-Authenticate).
• Durante esse tempo, o navegador já enviou o corpo da POST solicitação antes de receber a resposta 401 do servidor.
• Em seguida, o servidor recebe um corpo de solicitação não autenticado POST em uma conexão que indicou anteriormente ao cliente que a autenticação é necessária.
• Isso resulta no corte da conexão TCP subjacente pelo servidor e o navegador potencialmente exibindo uma mensagem "Página da Web não está disponível".

A página ScrapperTest.aspx é usada para testar a delegação de cenários de credenciais do servidor front-end para o ponto de extremidade do servidor back-end. Depois que a página for solicitada do navegador do cliente, ela oferecerá uma interface do usuário que permite:

• Inserir a URL do ponto de extremidade de back-end à qual o servidor front-end deve se conectar.
• Verificar se o usuário está autenticado no front-end e qual nome de usuário é usado para se conectar ao servidor front-end.
• Decidir (caso a autenticação seja usada para acessar a página ScrapperTest.aspx ) se as credenciais do usuário autenticado devem ser passadas com a solicitação para o servidor back-end (se a representação e a delegação forem possíveis).

Depois que o botão Página de recortes for selecionado, o código da página ScrapperTest.aspx emitirá uma GET solicitação para o URL de destino indicado. Se a caixa de seleção Usar credenciais estiver marcada e a autenticação for necessária para acessar o ponto de extremidade de back-end especificado, as credenciais do usuário autenticado também serão usadas para fazer a solicitação. Se uma solicitação for bem-sucedida, o resultado será exibido no controle da área de texto da página como a saída HTTP bruta da resposta recebida.

Um cenário de uso que prevemos é colocar a página ScrapperTest.aspx e a página WhoAmI.aspx dentro do aplicativo ASP.NET que seria contatado no servidor back-end. Assim, a resposta HTTP recuperada pela página ScrapperTest.aspx será a saída HTML da página WhoAmI.aspx quando executada no back-end. Essa saída pode ser avaliada para entender como a solicitação foi autenticada no back-end e quais contas foram usadas.

Mais informações

Para entender melhor a configuração da Autenticação Integrada do Windows usando Kerberos, consulte:

• Solucionar problemas de falhas do Kerberos no Internet Explorer
• Autenticação de salto duplo irrestrito Kerberos com o Microsoft Edge (Chromium)
• Autenticação Kerberos baseada em solicitação versus autenticação Kerberos baseada em sessão (ou o parâmetro AuthPersistNonNTLM)