¿Solución de problemas de autenticación de Windows (sin desafío) en IIS 7.5?

Sé que hay miles de informes de personas que tienen problemas para lograr que la autenticación integrada de Windows funcione con IIS, pero todos parecen conducir a páginas web que no se aplican o soluciones que ya he probado. He implementado docenas de sitios como este antes, por lo que hay algo extraño que sucede con el servidor / configuración, o he estado mirando esto demasiado tiempo y no he visto lo obvio.

En pocas palabras, todo funciona perfectamente en mi máquina local, pero se desmorona en el servidor de producción, que, por lo que puedo decir, tiene exactamente la misma configuración .

En la máquina local:

La máquina ejecuta Windows 7 Ultimate, Service Pack 1, IIS 7.5.
El sitio ha sido probado con éxito, utilizando IIS y el servidor de desarrollo web VS.
La configuración del sitio IIS tiene todos los métodos de autenticación deshabilitados, excepto la autenticación de Windows.
La máquina local no está en ningún dominio.
Los proveedores configurados son Negotiate y NTLM (no Negotiate: Kerberos).
La protección extendida está desactivada.
Todos los navegadores probados (IE, Firefox, Chrome) muestran el mensaje de desafío y me permiten iniciar sesión en el dominio localhost con mi cuenta de Windows (local).
Todos los navegadores probados también funcionan con una dirección IP local opaca, por lo que a los navegadores no les importa si el sitio parece "local" o "remoto".
He agregado una línea de visualización a la página web que muestra el usuario que ha iniciado sesión actualmente y muestra exactamente lo que esperaría (con el usuario local con el que he iniciado sesión).

En la máquina remota:

El servidor ejecuta Windows Server 2008 R2, IIS 7.5.
La carga de la página web produce un error inmediato 401.2: no está autorizado para ver esta página debido a encabezados de autenticación no válidos. No aparece ningún mensaje de desafío.
La configuración del sitio IIS tiene todos los métodos de autenticación deshabilitados, excepto la autenticación de Windows.
La máquina remota no está en ningún dominio.
Los proveedores configurados son Negotiate y NTLM (no Negotiate: Kerberos).
La protección extendida está desactivada.
En la máquina remota (sesión de escritorio remoto), aparece el mismo error en Internet Explorer independientemente de si el dominio es localhost o la dirección IP externa.
Si intento ver el sitio web remoto desde mi máquina local , el error sigue siendo 401, pero un 401. ligeramente diferente. Sin subcódigo, con el texto: Acceso denegado debido a credenciales no válidas.
La autenticación de Windows función función de IIS está instalado.
El WindowsAuthentication módulo se añadió (a nivel de servidor).
El mismo error exacto ocurre si apago la autenticación de Windows y habilito la autenticación básica.
El sitio se carga si apago la autenticación de Windows y habilito Anónimo (obviamente).
Ya he seguido todos los pasos de solución de problemas en el soporte de Microsoft: Solución de errores de HTTP 401 en IIS
Ya probé la solución que se muestra en otra página de soporte de Microsoft (supuestamente para forzar NTLM como el único método).

Por último, pero no menos importante, intenté activar FREB para errores 401.2 y los resultados no parecen decirme nada útil, todo lo que veo es la siguiente advertencia:

MODULE_SET_RESPONSE_ERROR_STATUS

ModuleName IIS Web Core
Notification 2
HttpStatus 401
HttpReason No autorizado
HttpSubStatus 2
Código de
error 2147942405 ConfigExceptionInfo
Notificación AUTHENTICATE_REQUEST
ErrorCode Acceso denegado. (0x80070005)

... esto parece solo decirme lo que ya sé (que es simplemente rechazar la solicitud en lugar de negociar las credenciales).

El seguimiento indica que el módulo de Autenticación de Windows está cargado correctamente porque hay una NOTIFY_MODULE_STARTlínea con ModuleName= WindowsAuthentication(y varios otros eventos de seguimiento ASP.NET - [desafortunadamente], no hay errores interesantes o advertencias aquí).

¿Alguien puede decirme lo que podría estar perdiendo aquí?

Actualización rápida:

Estoy un poco incómodo enviando un volcado de Wireshark completo ya que revelaría IP, URL y otras cosas, pero hice una comparación lado a lado de las respuestas HTTP de localhost y el servidor remoto en Fiddler, y parece bastante propio -evidente cuál es el problema:

Localhost:

HTTP / 1.1 401 no autorizado
Control de caché: privado
Tipo de contenido: texto / html; charset = utf-8
Servidor: Microsoft-IIS / 7.5
Autenticación WWW: Negociar
Autenticación WWW: NTLM
Desarrollado por X: ASP.NET
Fecha: sábado 17 de diciembre de 2011 23:42:34 GMT
Longitud del contenido: 6399
Soporte de proxy: autenticación basada en sesión

Remoto:

HTTP / 1.1 401 no autorizado
Tipo de contenido: texto / html
Servidor: Microsoft-IIS / 7.5
Desarrollado por X: ASP.NET
Fecha: sábado 17 de diciembre de 2011 23:43:13 GMT
Longitud del contenido: 1293

Además de algunas diferencias aparentemente intrascendentes como el control de caché, la diferencia principal es que el servidor remoto no está enviando los encabezados WWW-Authenticate al cliente.

Entonces, supongo que eso reduce la pregunta a: ¿Por qué IIS no envía encabezados WWW-Authenticate cuando la autenticación de Windows parece estar instalada, cargada y habilitada exclusivamente?

security iis authentication iis-7.5 http-authentication Aaronaught
fuente

¿Le importaría capturar un fragmento de texto sin formato del intento de autenticación (cambie su contraseña a algo desechable primero, no queremos que su contraseña real tenga hashes en la red)? Hace unos 18 meses, un parche de Windows hizo algunos cambios en la negociación HTTP NTLM (por cierto, ¿los sistemas están parcheados completamente?) Que explotaron la aplicación de un proveedor y me dieron mucha más experiencia de la que me gustaría admitir al analizar conversaciones de negociación.

Shane Madden

@ShaneMadden: Me importa tener en cuenta todos los diversos bits de información que expondría, pero puedo hacer una sesión de Fiddler que debería ser casi la misma, y luego al menos puedo anonimizar las IP, etc. de hecho, ya lo hice, los resultados deberían explicarse por sí mismos (el cliente no muestra la solicitud de credenciales porque el servidor no solicita ninguna).

Aaronaught

Oh, interesante, alguien parece haber informado este problema también en Stack Overflow , lamentablemente no hay respuestas.

Aaronaught

@Aaronaught ¿Cómo obtuviste un nombre de usuario diferente aquí que en Cooking? Cuando vi esta pregunta por primera vez, pensé que era alguien que te estaba engañando.

Ward - Restablece a Monica

@Ward: cualquiera puede editar su nombre de usuario, es parte del perfil. Este fue mi original, solo uso otros en los sitios no tecnológicos.

Aaronaught

Problema resuelto. Finalmente decidí comparar la lista de módulos uno al lado del otro y en realidad faltaba uno. Resulta que hay dos módulos de autenticación de Windows:

Lista de módulos

En el servidor, el WindowsAuthenticationmódulo administrado estaba allí, pero no el nativo WindowsAuthenticationModuleresaltado anteriormente. Nadie sabe por qué se configuró de esa manera, pero aparentemente si el módulo nativo no está cargado, el módulo administrado se cargará alegremente y fallará en silencio.

Entonces, para cualquier lector futuro que encuentre este problema, asegúrese de tener ambos módulos cargados , porque IIS no le avisará si falta uno de ellos.

Aaronaught
fuente

El módulo de autenticación de Windows administrado no es lo que parece. Es compatible con las identidades de Windows en ASP.Net, y siempre está instalado (cuando ASP.Net está instalado). Pero el módulo nativo de autenticación de Windows es lo que se instala cuando marca el componente de autenticación de Windows en el Administrador del servidor, y eso es lo que necesita para que esa opción de autenticación sea visible en la GUI de autenticación.

TristanK

@TristanK: en este caso, ese componente estaba marcado, pero el módulo no estaba instalado. (Sin embargo, la opción era visible en la GUI de autenticación, por lo que estoy bastante seguro de que la pantalla depende del módulo administrado, no del módulo nativo)

Aaronaught

Estoy pensando que puede haber sido así debido a algunas manipulaciones de los archivos de configuración (probablemente ApplicationHost.config). Pero supongo que no importa cómo salió todo mal; lo hizo.

Aaronaught

Pues claro. La autenticación de Windows no funciona a menos que ocurra algo que la rompa; en este caso, mientras la pregunta establece que la configuración es idéntica, eso resulta ser falso; entonces no funcionó igual. QED

TristanK

Este problema de módulo faltante me mordió en Windows Server 2012 R2. Es increíble que no haya indicaciones cuando ocurre esta condición. De todos modos, muchas gracias por esta respuesta; ¡Literalmente me estaba arrancando el pelo!

Rob Davis

¿Solución de problemas de autenticación de Windows (sin desafío) en IIS 7.5?

Respuestas: