Evitar la respuesta 401 para cada solicitud usando NTLM
https://stackoverflow.com/questions/1222506
-
10-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Tenemos aquí una aplicación asp.net 3.5 que utiliza la autenticación de Windows basada en NTLM. El sistema se ejecuta en una red privada que realmente se distribuye en diferentes lugares geográficos (conectados a través de VPN).
Ahora estamos tratando de optimizar el rendimiento del sitio web. Debido a la forma en que funciona NTLM, cada nueva solicitud al IIS se compone de 3 solicitudes diferentes, mientras que las 2 primeras son 401 respuestas. Estamos tratando de minimizar la cantidad de estas solicitudes solo al comienzo de la sesión. Encontramos esta solución. Lamentablemente, no cambió nada y seguimos recibiendo esta respuesta 401 (que consume tiempo).
Para ver el tráfico, utilicé por primera vez la aplicación Fiddler. De alguna manera, cuando uso Fiddler, solo hay un proceso de autenticación al comienzo de la sesión (exactamente como lo deseo), pero cuando cierro Fiddler y verifico el tráfico a través de WireShark puedo ver que todavía tengo esta respuesta 401 para cada solicitud .
Los clientes utilizados son IE6, IIS versión 6.
¿Alguien puede aconsejar?
Solución
NTLM / Negotiate, a diferencia de todos los demás esquemas de autenticación HTTP, son protocolos orientados a la conexión.
En IIS, hay varias configuraciones que controlan si se exigirá autenticación para todas las solicitudes en una conexión previamente autenticada (por ejemplo, AuthPersistSingleRequest). Independientemente de esa configuración, creo que IIS exigirá automáticamente una nueva autenticación al realizar una solicitud POST.
Si su servidor está afectando la reutilización de la conexión (por ejemplo, enviando una conexión: cierre el encabezado en las respuestas) debe corregirlo porque de lo contrario se producirá la reautenticación. Puede verificar fácilmente dichos encabezados frustrados de reutilización de autenticación utilizando Fiddler.
Otros consejos
La única forma es usar NTLM solo en la página de inicio de sesión y usar cookies como aquí
Sobre un tema relacionado; si está utilizando IIS7.0 y autenticación Kerberos, parece que AuthPersistNonNTLM = true puede usarse para evitar 401 viajes de ida y vuelta para cada solicitud.
http://msdn.microsoft.com/ es-es / library / aa347548 (VS.90) .aspx
¿Has probado esto en tu dominio?
setspn -a FQDNServerName applicationPoolServiceAccount
setspn -a biosServerName applicationPoolServiceAccount
Permite que el grupo de aplicaciones atienda solicitudes de autenticación NTLM.
Puede ser su configuración de seguridad en IE6 para el sitio. Intente cambiar a intranett local o sitio de confianza.
¡Tengo exactamente el mismo problema! Estoy usando el mismo entorno que tú. Excepto que veo 2 401 incluso en Fiddler. Había pasado un par de días en ese problema y luego me di por vencido. AuthPersistence tampoco funcionó para mí. Pero aquí están los enlaces que encontré, tal vez funcionen en su caso.
http://msdn.microsoft.com/en-us/library /ms525244.aspx
http://technet.microsoft.com/en-us/library /cc786094.aspx
http://technet.microsoft.com/en-us/library /cc781339(WS.10).aspx
Traté de establecer el indicador tanto en el directorio virtual como en el sitio web, pero no me ayudó. ¿Está utilizando el IIS Metabase Explorer para editar esas propiedades? Es la forma más limpia de editar propiedades y puede ayudar más que editar directamente el archivo XML.
Una forma de evitar el problema es insertar el Encabezado de control de caché en la respuesta HTTP para los recursos que no van a cambiar con frecuencia en ninguna página. En mi caso, almacené en caché los archivos css (use css externos tanto como sea posible para optimizar esto), js e img. Como tengo alrededor de 60 archivos de este tipo que se cargan en nuestra página de inicio, ¡pudimos eliminar unos 120 401 errores de inmediato!
Asegúrese de usar el encabezado Cache-Control y no el almacenamiento en caché basado en etiquetas modificadas o e-if donde se generarán un 401 y un 304 incluso cuando los archivos estén en caché.
Estaba teniendo este problema también, excepto que, para mí, fueron principalmente archivos JS y CSS los que causaron esto. Mi sitio (como la mayoría de los sitios) mantiene archivos JS y CSS en sus propios directorios. Entonces, la solución para mí fue simplemente ir a esos directorios en IIS y habilitar Anon Auth (digo simplemente, pero me llevó más de dos años resolver esto; gracias a esta publicación). Ahora el sitio aún requiere autenticación de Windows, pero los subdirectorios para archivos JS y CSS no. IOW, parece estar funcionando perfectamente.
Tampoco pondría información confidencial en un archivo JS (o un archivo CSS) y sugeriría que usted tampoco. Si lo hace, obviamente querrá mover la información confidencial de estos archivos fuera de estos directorios.
