iis - services - solucion 401 unauthorized access is denied due to invalid credentials
Evitar la respuesta 401 para cada solicitud utilizando NTLM (7)
Aquí tenemos 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 con 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 this solución. Lamentablemente, no cambió nada y seguimos recibiendo esta respuesta 401 (que consume tiempo).
Para ver el tráfico, primero utilicé la aplicación Fiddler. De alguna manera, cuando uso Fiddler, solo hay 1 proceso de autenticación al comienzo de la sesión (exactamente como deseo), pero cuando cierro Fiddler y reviso 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?
¡Tengo exactamente el mismo problema! Estoy usando el mismo entorno que tú. Excepto que veo 2 401 incluso en Fiddler. Pasé un par de días con ese problema y luego me rendí. AuthPersistence tampoco funcionó para mí. Pero aquí están los enlaces que encontré, quizás funcionen en su caso.
http://msdn.microsoft.com/en-us/library/ms525244.aspx
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/cc786094.aspx
Traté de establecer el indicador tanto en el directorio virtual como en el nivel del sitio web, pero no ayudó. ¿Estás usando el Explorador de metabase de IIS para editar esas propiedades? Es la manera más limpia de editar propiedades y puede ayudar más que editando directamente el archivo XML.
Una forma de eludir 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, guarde en caché el css (use css externos tanto como sea posible para optimizar esto), js e img. Como tengo aproximadamente 60 archivos de este tipo que se cargan en nuestra página de inicio, ¡pudimos eliminar aproximadamente 120 401 errores de inmediato!
Asegúrese de utilizar el encabezado Cache-Control y no el caché basado en if-modified o e-tag donde aún se generarán un 401 y un 304, incluso cuando los archivos estén en caché.
¿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.
En un tema relacionado; si está utilizando IIS7.0 y la autenticación de Kerberos, parece que AuthPersistNonNTLM = true se puede usar para evitar 401 viajes de ida y vuelta para cada solicitud.
http://msdn.microsoft.com/en-us/library/aa347548(VS.90).aspx
Estaba teniendo este problema también, excepto que, para mí, fue sobre todo archivos JS y CSS lo que causó esto. Mi sitio (como la mayoría de los sitios) mantiene los archivos JS y CSS en sus propios directorios. Así que 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 la autenticación de Windows, pero los subdirectorios de los archivos JS y CSS no lo requieren. IOW, parece estar funcionando perfectamente.
También nunca pondría información confidencial en un archivo JS (o un archivo CSS para ese asunto) y sugeriría que tampoco lo haga. Si lo hace, obviamente querrá mover la información confidencial en estos archivos fuera de estos directorios.
La única forma es usar NTLM solo en la página de inicio de sesión y usar cookies como here
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á perjudicando la reutilización de la conexión (por ejemplo, al enviar una conexión: cerrar el encabezado en las respuestas) debe corregirlo porque de lo contrario se producirá la reauthentication. Puede verificar fácilmente dichos encabezados frustrados de reutilización de autenticación utilizando Fiddler.
Puede ser su configuración de seguridad en IE6 para el sitio. Intente cambiar a intranet local o sitio de confianza.