asp.net - studio - windows authentication in iis 10

¿Una aplicación web de IIS 7.5 con autenticación de Windows requiere que los usuarios finales tengan permisos de archivos? (3)

Version corta:

Para las aplicaciones web IIS 7.5 con Autenticación de Windows, ¿el usuario final necesita tener acceso a los archivos de lectura?

Versión larga:

Tengo una aplicación web de intranet ASP.NET que usa la autenticación de Windows. Está instalado en docenas de compañías diferentes y normalmente la autenticación funciona bien: los usuarios navegan al sitio, por ejemplo http://appserver/MyApp , la aplicación reconoce con quién están conectados y muestra las páginas en consecuencia. Acabo de instalarlo en un nuevo cliente y encontré un problema:

Al conectar, por ejemplo, a http://appserver/MyApp , se me solicitan las credenciales de Windows, pero después de ingresarlas me preguntan repetidamente. Después de varias credenciales de reingreso, se muestra una página de error 401 que dice "401 - No autorizado: acceso denegado debido a credenciales no válidas". Por lo tanto, no solo no está pasando por mi identidad, sino que incluso al ingresar el nombre de usuario y la contraseña, sigue denegando el acceso.

Dar permisos de lectura y ejecución a los usuarios finales de la aplicación resuelve este problema , pero no creo que esto sea necesario en absoluto.

En el registro de eventos de la aplicación Windows, aparece el mensaje "Error de autorización de archivo para la solicitud" junto con el nombre de la cuenta Thread: NT AUTHORITY / NETWORK SERVICE and User: [la cuenta de dominio correcta de los usuarios de la estación de trabajo] . Esto sugiere que el acceso al archivo se realiza con la identidad del usuario, no con la identidad de AppPool del servicio de red. Efectivamente si otorgo al usuario final permiso de Lectura y Ejecución (no intenté solo Leer) en el directorio de la aplicación, entonces todo funciona correctamente: cuando el usuario navega hacia el sitio, se autentica automáticamente, no se le solicita, y el sitio web reconoce correctamente su identidad! Por lo tanto, mi solución alternativa es otorgar permisos de Lectura y Ejecución a Todos en el directorio de la aplicación ... pero esta no es una solución ideal.

Esto parece muy extraño. Nunca he necesitado hacer esto antes en IIS 7.5, por lo que recuerdo, y definitivamente nunca fue necesario en IIS 6 o IIS 7. ¿Es esto una nueva cosa de IIS7.5? La documentación dice que la suplantación está desactivada por defecto. Agregué un elemento al web.config para estar seguro, eliminé permisos de archivos que no sean el Servicio de Red, pero el problema persistía.

¿Alguna idea? ¿Es normal que Windows Authenticated Sites en IIS 7.5 los usuarios finales necesiten permisos de archivos en los archivos del servidor web?

Algunos detalles relevantes:

El servicio de red tiene permisos de archivo de control total para la carpeta de la aplicación.
Cuando me conecté desde el servidor en sí, me pidieron las credenciales, pero después de ingresarlas estoy autenticado y la aplicación funciona correctamente, lo que incluye mostrar mi inicio de sesión de Windows y conectar y recuperar datos del archivo db. Más tarde determiné que pedía credenciales porque http://localhost estaba en los sitios de confianza y, por lo tanto, no se reconocía como la Zona de Intranet y, por lo tanto, no transmitía la identidad. También determiné que funcionaba como esta identidad de usuario porque es un usuario administrador que tiene permisos de archivos.
El servidor web ejecuta Windows Server 2008 R2 / IIS 7.5. No tenía IIS en él hasta que lo instalé. Instalé las funciones predeterminadas, así como la Autenticación de Windows, ASP.NET y posiblemente un par de otros elementos. Una aplicación WCF separada que instalé y que usa IIS, autenticación anónima y .net 2.0 funciona bien en ese servidor web.
El proceso de instalación de la aplicación es una copia manual de archivos, creación de grupos de aplicaciones IIS y aplicaciones web, actualización de cadenas de conexión, etc.
Revisé la configuración de seguridad de IE. Estaba reconociendo el servidor como en la zona de Intranet y tenía seleccionada la opción ''Inicio de sesión automático solamente en la zona de Intranet''. También en Opciones avanzadas, se marcó la opción ''Habilitar autenticación de Windows integrada''.
Después de instalar IIS, ejecuté aspnet_regiis -i para .net 2.0 y aspnet_regiis -iru para .net 4.0.
La autenticación anónima está deshabilitada para mi aplicación y la Autenticación de Windows está habilitada.
La aplicación se ejecuta en ASP.NET v4 pero hay otra aplicación que instalé experimentando el mismo problema al ejecutar ASP.NET v2.
La aplicación se está ejecutando con Identity = Network Service y en modo de 32 bits.
La cadena de conexión de la base de datos incluye Trusted Connection=True y los permisos de la base de datos se otorgan a la cuenta del servidor web [domain]/[server]$ eg DGM/MyServer$ .
En IIS> Autenticación> Autenticación de Windows> Proveedores, la lista se negocia primero y luego NTLM. Intenté reordenar para que NTLM sea primero.
En el Registro de sucesos de seguridad de Windows había una serie de eventos de auditoría de seguridad de Microsoft Windows: Inicio de sesión y cierre de sesión. Indicaron que el inicio de sesión fue exitoso y mostraba el ID del usuario de la estación de trabajo. Esto es de cuando me estoy conectando desde otra estación de trabajo y recibo un 401 no autorizado después de varios intentos.

Veo que alguien ha tenido este problema informado aquí, pero sin solución. Originalmente publiqué en la ASP y luego en los foros de IIS sin respuestas hasta el momento.

Actualización: este artículo msdn dice

Cuando la autenticación de Windows está habilitada pero la suplantación está deshabilitada, ASP.NET realiza comprobaciones de acceso al archivo en el módulo de autorización de archivos utilizando las credenciales que se envían desde el navegador (énfasis mío) . No es necesario habilitar la suplantación porque el módulo FileAuthorizationModule garantiza que el usuario solicitante tenga acceso de lectura o de escritura al recurso, dependiendo del verbo de solicitud (por ejemplo, GET o POST) antes de ejecutar la solicitud. Este comportamiento se aplica a todas las solicitudes que ingresan código administrado. En versiones anteriores de ASP.NET, el acceso a los archivos basados en URI como "Default.aspx" desencadenó la comprobación de acceso. En las aplicaciones ASP.NET MVC, donde el acceso a los recursos generalmente se realiza utilizando URLs sin extensión, esta verificación generalmente no se aplica, porque no hay un archivo físico para verificar. En ese caso, la clase FileAuthorizationModule vuelve a consultar listas de control de acceso (ACL) para la carpeta.

Esto sugiere que el usuario final necesita permisos para los archivos (en el caso de .aspx) o la carpeta (para MVC) ... aunque todavía parece algo escondido y no definitivo. Este artículo sobre las Piscinas de la aplicación dice que se usan como la identidad para proteger los recursos, lo que contradice la idea de necesitar otorgar privilegios a los usuarios finales. A menos que las reglas sean diferentes para Grupos de aplicaciones y SERVICIO DE RED, lo que podría ser el caso, pero sería sorprendente.

¿Los usuarios autenticados están permitidos en la carpeta de la aplicación?

La respuesta corta es no. No es necesario otorgar permisos de acceso a archivos cuando usa la Autenticación de Windows en IIS 7.0 e IIS 7.5.

Solo pudimos descubrir esto porque nuestro administrador del servidor olió los problemas de seguridad y administración que surgen al tomar la ruta de otorgar acceso de nivel de archivo a usuarios y grupos.

Para cualquier persona que maneje este problema o si está configurando un nuevo servidor IIS7 / IIS7.5 y / o se está moviendo de IIS 6, aquí hay un artículo que le brinda todas las opciones y configuraciones de Autenticación de Windows que necesitan ser modificadas para evitar otorgando acceso a nivel de archivo a individuos o grupos.

Lea los dos comentarios al final del POST para obtener algunas críticas válidas de los métodos utilizados en este artículo.

http://weblogs.asp.net/owscott/iis-using-windows-authentication-with-minimal-permissions-granted-to-disk

Además de la información en el artículo, tenga en cuenta que IIS 7.5 no está utilizando las etiquetas de configuración web para system.web (al menos, no en mi aplicación MVC 4).

Está buscando en las etiquetas system.webserver para la configuración de la autorización (donde deberá enumerar los grupos de dominio de Windows / para los que un usuario debe acceder para acceder a su aplicación).

- DSB

También estábamos peleando con este problema, y comenzamos a configurar grupos de seguridad para poder otorgarles a nuestros usuarios permisos de nivel de archivo. Luego, uno de los administradores de nuestro servidor tropezó con un par de nuevas propiedades que permiten que la aplicación se autentique en el sistema de archivos con las credenciales establecidas, y resolvió la necesidad de que los usuarios tengan acceso. Esto es lo que se le ocurrió ...

Hay dos configuraciones de IIS que controlan esto:
Credenciales de ruta de acceso física Credenciales de ruta de acceso física Tipo de inicio de sesión
De manera predeterminada, las credenciales de ruta física están configuradas como usuario de la aplicación (autenticación de paso). Esto significa que IIS no hace ninguna suplantación cuando maneja las solicitudes de Autenticación de Windows. Sin embargo, esto se puede establecer en un usuario específico (aunque no, desafortunadamente, la identidad del grupo de aplicaciones, que sería ideal). El tipo de inicio de sesión de credenciales de ruta de acceso físico se establece de forma predeterminada como texto claro. Para mis pruebas configuré esto en Interactivo (aunque este puede no ser el valor correcto). Los valores posibles son Clear-Text, Batch, Interactive y Network.
Para configurar esto, hice lo siguiente:
Creó una cuenta local (IIS-AccessUser)
Concedido, IIS-AccessUser lee y ejecuta el acceso al directorio / home del sitio.
Se agregó IIS-AccessUser al grupo IIS_IUSRS (necesario para acceder a archivos temporales .NET)
Establezca IIS-AccessUser como credenciales de ruta de acceso física
Establecer el tipo de inicio de sesión de Credenciales de ruta de acceso físico a Interactivo
Hacer lo anterior me permitió iniciar sesión en la aplicación directamente, sin tener que permitir Usuarios autenticados, o tener que ser miembro de cualquiera de los grupos en la carpeta / home. También conservaba las funciones de autorización de .NET, por lo que aún no podía acceder a las partes del sitio que no estaba autorizado.