Problema de permisos con directorio virtual a ruta UNC

Tengo un directorio virtual en mi sitio (entorno de prueba). Es un recurso compartido de UNC que también se utiliza como un FTP público.

Está configurado para conectarse como una cuenta de administrador de dominio y "Configuración de prueba" dice que todo parece estar funcionando. Sin embargo, cuando trato de conectarme consigo:

500 - "Error al iniciar la supervisión de los cambios en \ INTRANET \ FTP \ test \ web.config porque se denegó el acceso"

Este es un ASP.NET YSOD. No estoy seguro de por qué ASP.NET se está involucrando en absoluto, ya que estoy solicitando un archivo .jpg estático.

Intenté activar el seguimiento de solicitudes fallidas y este es el error específico:

• ModuleName WindowsAuthentication
• Notificación 2
• HttpStatus 500
• Error interno del servidor HttpReason
• HttpSubStatus 0
• Código de error 0
• ConfigExceptionInfo
• Notificación AUTHENTICATE_REQUEST
• Código de error La operación se completó correctamente. (0x0)

Si cambio el "Tipo de inicio de sesión de ruta física" de ClearText a Red. Me sale el siguiente error de IIS:

Error HTTP 500.19 - Servidor interno

Error No se puede acceder a la página solicitada porque los datos de configuración relacionados para la página no son válidos.

Información de error detallada

• Módulo IIS Web Core
• Notificación BeginRequest
• Manejador Aún no determinado
• Código de error 0x80070005
• Error de configuración No se puede leer el archivo de configuración debido a permisos insuficientes
• Archivo de configuración \\?\UNC\INTRANET\FTP\test\web.config

• URL solicitada http://test.mydowmain.com:80/uploads/images/ca49acf6-6174-412e-8abd-59fab983e931.jpg

• Camino fisico \\INTRANET\FTP\test\images\ca49acf6-6174-412e-8abd-59fab983e931.jpg

• Método de inicio de sesión Aún no determinado

• Usuario de inicio de sesión Aún no determinado
• Directorio de registro de seguimiento de solicitud fallido C:\inetpub\logs\FailedReqLogFiles

Esto no genera un registro de solicitud fallido de manera bastante extraña: he configurado el seguimiento de solicitud fallida para rastrear errores con los códigos de error 400-999.

También vale la pena señalar que si abro la función de configuración desde IIS, veo un error de acceso denegado.

Tengo exactamente la misma configuración en mi máquina de desarrollo local para la misma ruta UNC y el mismo usuario con el que funciona. Solo en el servidor de prueba no lo hace.

¿Qué estoy haciendo mal?

El hecho de que sea una aplicación ASP.net es probablemente exactamente el problema aquí. La identidad de su grupo de aplicaciones debe tener derechos (no necesariamente la identidad de IIS; de manera predeterminada, la identidad del grupo de aplicaciones es la cuenta de servicio de red local). Probablemente también necesite ejecutar caspol.exe en su máquina IIS.

http://msdn.microsoft.com/en-us/library/cb6t8dtz%28v=vs.80%29.aspx

http://learn.iis.net/page.aspx/50/aspnet-20-35-shared-hosting-configuration/

%windir%\Microsoft.NET\Framework\v2.0.50727\caspol -m -ag 1.  -url "file://\\remotefileserver\content$\*" FullTrust

Resolví nuestro problema creando cuentas coincidentes tanto en el servidor web como en el servidor unc. Luego modifiqué el grupo de aplicaciones para que se ejecute utilizando esa cuenta coincidente, no el servicio de red. Esto me dio la flexibilidad de sincronizar la contraseña en ambos servidores sin afectar otras funciones dependientes del servicio de red.

Si esta fuente compartida no es una aplicación (por ejemplo, una carpeta de imágenes), intente configurar el directorio virtual para que sea ignorado por la aplicación raíz que incluye el directorio virtual (en mi caso, lo he completado cambiando el tipo de grupo de aplicaciones raíz como Clásico en lugar de modo integrado). Pero si hay una aplicación en el punto compartido, entonces puede seguir el camino indicado por @mfinni.

Puede verificar para asegurarse de que la cuenta con la que se ejecuta IIS tenga los derechos adecuados / necesarios para la problemática UNC.

Tuve el mismo problema en IIS 7.5, encontré que la solución era:

1. Cree un usuario local en el servidor con el recurso compartido
2. Cree el recurso compartido de red, otorgando al usuario creado en el paso 1 los permisos deseados. Windows configurará los permisos para el usuario que haya especificado
3. Vaya al directorio virtual en IIS y abra la "configuración avanzada"
4. Ingrese la URL en la ruta física para el recurso compartido de red como \\<servername>\<sharename>
5. haga clic en Credenciales de ruta física; agregue las credenciales para el usuario creado en el paso 1

Acabo de tener el mismo problema con un servidor web que no es de dominio accediendo a algunos recursos de dominio usando una cuenta de dominio. Estábamos obteniendo un comportamiento extraño (las "credenciales de prueba" fallaban aunque sabíamos que las credenciales eran correctas, podíamos ver carpetas y archivos en la vista de contenido, pero no podíamos "examinarlos"). La solución fue crear un usuario local en la máquina con el mismo nombre que el usuario de dominio.

Estoy pensando que esto es lo que habría sucedido si el servidor web fuera miembro del dominio, y el usuario local fuera necesario para acceder a algunos recursos locales (¿configuración?) Para mapear el virtual.

Espero que ayude a alguien.