Pregunta

Acabo de crear un sitio web ASP MVC básico para implementarlo en nuestra intranet.Espera que los usuarios estén en el mismo dominio que el cuadro IIS y, si no es un usuario de Windows autenticado, no debería obtener acceso.

Acabo de implementar esto en IIS6 ejecutándose en Server 2003 R2 SP2.La aplicación web está configurada con su propio grupo con su propia cuenta de usuario del grupo.Las opciones de seguridad del directorio IIS para la aplicación web están configuradas únicamente en "Seguridad integrada de Windows" y el archivo web.config tiene:

<authentication mode="Windows" />

Desde una sesión de Escritorio remoto en el servidor IIS6, una ventana del navegador IE7 puede autenticar y navegar con éxito la aplicación web si se accede a través de http://localhost/miaplicación.

Sin embargo, también desde el servidor, si se accede a través del nombre del servidor (es decir, http://miservidor/miaplicación) luego IE7 presenta un cuadro de diálogo de credenciales que, después de tres intentos de ingresar las credenciales correctas, finalmente devuelve "Error HTTP 401.1 - No autorizado:Acceso denegado por credenciales no válidas".

El mismo problema ocurre cuando una estación de trabajo navega a la URL de la aplicación web (naturalmente usando el nombre del servidor y no "localhost").

El servidor IIS6 es miembro del único dominio que tenemos y no tiene ningún firewall habilitado.

¿Hay algo que no pude configurar correctamente para que esto funcione?

Gracias,


He probado las sugerencias de Matt Ryan, Graphain y Mike Dimmick hasta la fecha sin éxito.Acabo de construir un laboratorio de pruebas de máquinas virtuales con un servidor 2003 DC y un servidor 2003 IIS6 independiente y puedo replicar el problema.

Veo una entrada en el registro de eventos del sistema del servidor IIS6 la primera vez que intento acceder al sitio a través de la URL del host no local (es decir, http://iis/miaplicación).Las URL FQDN también fallan.

Fuente:Kerberos, ID de evento:4
El cliente Kerberos recibió un error KRB_AP_ERR_MODIFIED del servidor host/iis.test.local.El nombre de destino utilizado fue HTTP/iis.test.local.Esto indica que la contraseña utilizada para cifrar el ticket del servicio Kerberos es diferente a la del servidor de destino.Normalmente, esto se debe a cuentas de máquina con nombres idénticos en el ámbito de destino (TEST.LOCAL) y en el ámbito del cliente.

¿Fue útil?

Solución

Después de una extensa búsqueda en Google, logré encontrar una solución en el siguiente artículo de MSDN:
Cómo:Cree una cuenta de servicio para una aplicación ASP.NET 2.0

Específicamente, la sección Consideraciones adicionales que describe "Creación de nombres principales de servicio (SPN) para cuentas de dominio" usando la herramienta setspn de las herramientas de soporte de Windows:

setspn -A HTTP/miservidor MIDOMINIO\MiUsuarioPool
setspn -A HTTP/myserver.fqdn.com MIDOMINIO\MyPoolUser

Esto resolvió mi problema tanto en mi laboratorio de pruebas virtual como en mi servidor de problemas original.

También hay una nota importante en el artículo de que el uso de la autenticación de Windows con usuarios de grupos personalizados restringe el uso del nombre DNS asociado únicamente en ese grupo.Es decir, otro grupo con otra identidad tendría que estar asociado con un nombre DNS diferente.

Otros consejos

Suena como la nueva característica de seguridad de verificación de bucle invertido de Windows Server 2003 SP1.Según tengo entendido, está diseñado para prevenir un tipo particular de ataque de interceptación.

De http://support.microsoft.com/kb/896861

SÍNTOMAS

Cuando utiliza el nombre de dominio completo (FQDN) o un encabezado de host personalizado para explorar un sitio web local alojado en una computadora que ejecuta Microsoft Internet Information Services (IIS) 5.1 o IIS 6, puede recibir un mensaje de error que se parece al siguiente:HTTP 401.1 - No autorizado:El inicio de sesión fallido Este problema ocurre cuando el sitio web usa autenticación integrada y tiene un nombre que se asigna a la dirección de bucle de bucle local.

Nota Sólo recibirá este mensaje de error si intenta explorar el sitio web directamente en el servidor.Si navega por el sitio web desde una computadora cliente, el sitio web funciona como se esperaba.

CAUSA

Este problema ocurre si instala Microsoft Windows XP Service Pack 2 (SP2) o Microsoft Windows Server 2003 Service Pack 1 (SP1).Windows XP SP2 y Windows Server 2003 SP1 incluyen una función de seguridad de verificación de bucle invertido diseñada para ayudar a prevenir ataques de reflexión en su computadora.Por lo tanto, la autenticación falla si el FQDN o el encabezado de host personalizado que utiliza no coincide con el nombre de la computadora local.

Solución alterna

  • Método 1:Deshabilitar la verificación de bucle invertido
  • Método 2:Especificar nombres de host

Ver http://support.microsoft.com/kb/896861 para detalles.


Editar: acabo de notar que dijiste que también estabas viendo esto desde las PC cliente...eso es más inusual.Pero aún así intentaría probar una de estas soluciones para ver si corrige el problema (y, de ser así, podría indicar un problema con su configuración de DNS).

Me parece que lo has hecho todo bien.

Estoy seguro de que sí, pero ¿te has asegurado de utilizar 'DOMINIO\usuario' como cuenta de usuario y no solo 'usuario'?

IE7 solo envía credenciales de Windows (NTLM, Kerberos) si identifica que el servidor está en la Intranet.IE7 también agregó una función de bloqueo de zona de Intranet: si no estás en un dominio, de forma predeterminada No Los servidores están en la zona de Intranet.Esto se hizo para evitar ataques de migración de zona.

Para cambiar esto, vaya a Herramientas/Opciones de Internet, pestaña Seguridad y luego haga clic en Intranet local.Luego puede agregar manualmente servidores que deben tratarse como Intranet, haciendo clic en el botón Sitios, luego en Avanzado, o decirle a IE que no detecte automáticamente su Intranet y seleccionando las otras casillas de verificación según corresponda.

Me encontré con el problema opuesto: mi sitio se autentica externamente pero no localmente.

Lo comparé con los sitios que tenemos trabajando y la diferencia fue que el sitio que no pudo autenticarse estaba usando la autenticación de Windows.

Sin embargo, otros sitios con los que trabajo (este es un servidor de desarrollo) tienden a tener autenticación básica.

No estoy seguro de por qué exactamente, pero esto lo solucionó.

Sin embargo, al mismo tiempo noté las configuraciones de "Dominio predeterminado" y "Reino".

Sé que es muy poco probable, pero ¿tal vez esto podría ayudar en algo?

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top