Solucionando problemas de autenticação do Windows (sem desafio) no IIS 7.5?

Sei que existem milhares de relatórios de pessoas com problemas para que a Autenticação Integrada do Windows funcione com o IIS, mas todas parecem levar a páginas da Web que não se aplicam ou soluções que eu já tentei. Eu já implantei dezenas de sites como esse antes, então, ou algo estranho está acontecendo com o servidor / configuração, ou eu estive olhando isso por muito tempo e não vendo o óbvio.

Simplificando, tudo funciona perfeitamente na minha máquina local, mas desmorona no servidor de produção, que, até onde eu sei, tem exatamente a mesma configuração .

Na máquina local:

A máquina está executando o Windows 7 Ultimate, Service Pack 1, IIS 7.5.
O site foi testado com sucesso, usando o IIS e o VS Web Development Server.
A configuração do site do IIS tem todos os métodos de autenticação desativados, exceto a autenticação do Windows.
A máquina local não está em nenhum domínio.
Os provedores configurados são Negociar e NTLM (não Negociar: Kerberos).
A proteção estendida está desativada.
Todos os navegadores testados (IE, Firefox, Chrome) mostram a solicitação de desafio e permitem que eu faça login no domínio localhost com minha conta (local) do Windows.
Todos os navegadores testados também funcionam usando um endereço IP local opaco - portanto, os próprios navegadores parecem não se importar se o site parece "local" ou "remoto".
Adicionei uma linha de exibição à página da web que mostra o usuário conectado no momento e mostra exatamente o que eu esperaria (qualquer usuário local com o qual fiz login).

Na máquina remota:

O servidor está executando o Windows Server 2008 R2, IIS 7.5.
Carregar a página da Web resulta em um erro 401.2 imediato : Você não está autorizado a visualizar esta página devido a cabeçalhos de autenticação inválidos. Nenhum prompt de desafio é exibido.
A configuração do site do IIS tem todos os métodos de autenticação desativados, exceto a autenticação do Windows.
A máquina remota não está em nenhum domínio.
Os provedores configurados são Negociar e NTLM (não Negociar: Kerberos).
A proteção estendida está desativada.
Na máquina remota (sessão da área de trabalho remota), o mesmo erro aparece no Internet Explorer, independentemente de o domínio ser host local ou o endereço IP externo.
Se eu tentar visualizar o site remoto da minha máquina local , o erro ainda será 401, mas um 401 ligeiramente diferente. Nenhum subcódigo, com o texto: Acesso negado devido a credenciais inválidas.
O recurso de função IIS de autenticação do Windows está instalado.
O WindowsAuthentication Module é adicionado (no nível do servidor).
O mesmo erro ocorre se eu desativar a autenticação do Windows e ativar a autenticação básica.
O site faz carga se eu desligar a autenticação do Windows e permitir anônimo (obviamente).
Eu já segui todas as etapas de solução de problemas no Suporte da Microsoft: Solução de problemas de erros HTTP 401 no IIS
Eu já tentei a solução alternativa mostrada em outra página de suporte da Microsoft (supostamente para forçar o NTLM como o único método).

Por último, mas não menos importante, tentei ativar o FREB para erros 401.2 e os resultados não parecem me dizer nada de útil, tudo o que vejo é o seguinte aviso:

MODULE_SET_RESPONSE_ERROR_STATUS

ModuleName IIS Web
Notification 2
HttpStatus 401
HttpReason Não autorizado
HttpSubStatus 2
ErrorCode
2147942405
Notificação ConfigExceptionInfo AUTHENTICATE_REQUEST O
acesso ao ErrorCode foi negado. (0x80070005)

... isso parece estar me dizendo o que eu já sei (que é simplesmente rejeitar a solicitação em vez de negociar as credenciais).

O rastreamento indica que o módulo WindowsAuthentication está carregado corretamente porque há uma NOTIFY_MODULE_STARTlinha com ModuleName= WindowsAuthentication(e vários outros eventos de acompanhamento do ASP.NET - [un] felizmente, sem erros ou avisos interessantes aqui).

Alguém pode me dizer o que posso estar perdendo aqui?

Rápida atualização:

Estou um pouco desconfortável enviando um dump completo do Wireshark, pois revelaria IPs, URLs e outras coisas, mas fiz uma comparação lado a lado das respostas HTTP do localhost e do servidor remoto no Fiddler, e parece bastante auto -evident qual é o problema:

Localhost:

HTTP / 1.1 401 não autorizado
Controle de cache: privado
Tipo de Conteúdo: text / html; charset = utf-8
Servidor: Microsoft-IIS / 7.5
WWW-Authenticate: Negociate
WWW-Authenticate: NTLM
Desenvolvido por X: ASP.NET
Data: sábado, 17 de dezembro de 2011 23:42:34 GMT
Comprimento do conteúdo: 6399
Suporte de proxy: autenticação baseada em sessão

Controlo remoto:

HTTP / 1.1 401 não autorizado
Tipo de Conteúdo: text / html
Servidor: Microsoft-IIS / 7.5
Desenvolvido por X: ASP.NET
Data: sábado, 17 de dezembro de 2011 23:43:13 GMT
Comprimento do conteúdo: 1293

Além de algumas diferenças aparentemente irrelevantes, como controle de cache, a principal diferença é que o servidor remoto não está enviando os cabeçalhos WWW-Authenticate de volta ao cliente.

Portanto, acho que isso restringe a pergunta a: Por que o IIS não está enviando cabeçalhos WWW-Authenticate quando a autenticação do Windows parece estar instalada, carregada e ativada exclusivamente?

— Aaronaught
fonte

Importe-se em capturar um wireshark de texto simples da tentativa de autenticação (altere sua senha para algo descartável primeiro - não queremos que seus hashes de senha reais na rede)? Cerca de 18 meses atrás, um patch do Windows fez algumas alterações na negociação HTTP NTLM (a propósito, os sistemas estão totalmente corrigidos?), Que explodiram o aplicativo de um fornecedor e me deram muito mais experiência do que gostaria de admitir ao analisar conversas de negociação.

— Shane Madden

@ShaneMadden: Eu meio que me importo com todas as várias informações que estarei expondo, mas posso fazer uma sessão do Fiddler que deve ser quase a mesma, e então posso pelo menos anonimizar IPs e assim por diante - e na verdade, como já fiz, os resultados devem ser bastante auto-explicativos (o cliente não está mostrando o prompt de credenciais porque o servidor não está solicitando nenhum).

— Aaronaught

Oh, interessante, alguém parece ter relatado esse problema no Stack Overflow também - infelizmente não há respostas lá.

— Aaronaught

@Aaronaught Como você conseguiu um nome de usuário diferente aqui do que no Cooking? Quando vi essa pergunta pela primeira vez, pensei que era alguém que estava enganando você.

— Ward - Restabelece Monica

@Ward: qualquer um pode editar seu nome de usuário, faz parte do perfil. Este era o meu original, use apenas outros em sites não técnicos.

— Aaronaught

Problema resolvido. Finalmente decidi comparar a lista de módulos lado a lado e realmente faltava uma. Acontece que existem dois módulos de autenticação do Windows:

Lista de módulos

No servidor, o WindowsAuthenticationmódulo gerenciado estava lá, mas não o nativo WindowsAuthenticationModuledestacado acima. Por que foi configurado dessa maneira é uma incógnita, mas, aparentemente, se o módulo nativo não estiver carregado, o módulo gerenciado será carregado alegremente e falhará silenciosamente.

Portanto, para futuros leitores que encontrarem esse problema, verifique se os dois módulos foram carregados , pois o IIS não avisará se um deles estiver faltando.

— Aaronaught
fonte

O módulo de autenticação do Windows gerenciado não é o que parece. É suporte para identidades do Windows no ASP.Net e está sempre instalado (quando o ASP.Net está instalado). Mas o módulo nativo de autenticação do Windows é o que é instalado quando você marca o componente de autenticação do Windows no Gerenciador do Servidor, e é disso que você precisa para que essa opção de autenticação fique visível na GUI de autenticação.

— TristanK

@TristanK: Nesse caso, esse componente foi marcado, mas o módulo não foi instalado. (A opção foi, no entanto, visíveis na GUI de autenticação - então eu tenho certeza que a tela depende do módulo gerenciado, não o nativo.)

— Aaronaught

Estou pensando que pode ter sido assim devido a algumas violações dos arquivos de configuração (provavelmente ApplicationHost.config). Mas acho que não importa como tudo saiu do controle; fez.

— Aaronaught

Bem, claramente. A autenticação do Windows não funciona, a menos que algo aconteça; nesse caso, embora a pergunta afirme que a configuração é idêntica, isso acaba sendo falso; então não funcionou da mesma maneira. QED.

— TristanK

Esse problema de módulo ausente acabou de me afetar no Windows Server 2012 R2. É incrível que não haja indicação de quando essa condição ocorre. De qualquer forma, muito obrigado por esta resposta; Eu estava literalmente arrancando meu cabelo!

— Rob Davis

Descobrimos que isso não corrigia necessariamente o problema para desenvolvedores que trabalham localmente em sites ASP.NET em execução na autenticação do Windows. Encontramos um hack do registro que desabilita a verificação de loopback; isso corrigiu: -

chave de registro - HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Lsa

Crie um DWORD com o valor 1 chamado "DisableLoopbackCheck"

Você precisará reiniciar a máquina para que a configuração entre em vigor

— sh1rts
fonte

Descobri que era possível alternar entre DisableLoopbackCheck como 1 e 0 e a alteração entraria em vigor imediatamente. Além disso, você pode ver a identificação de evento 4625 no log de segurança do log de eventos com a mensagem "A conta falhou ao fazer logon".

— precisa saber é o seguinte

Obrigado! Dois dias de folga com a autenticação do IIS e as versões .Net apenas para descobrir que é porque eu estava usando meu arquivo de hosts para criar uma entrada fictícia de DNS enquanto testava uma migração de site.

— 9789 John