permissions - Concesión de permisos de escritura a una carpeta UNC en red para ASP.NET bajo IIS 7.5 y Windows Server 2008 R2

iis-7.5 access-denied (3)

Reinicie su ''mywebserver''.
Maravíllate ante el misterioso y funcional ApplicationPoolIdentity.
Instale MS HotFix KB2545850 y conozca los detalles sobre este error en KB2672809 que también muestra los pasos para reproducir y demostrar este problema aparentemente aleatorio. Enlace de descarga directa here .
Especule por qué Microsoft no ha logrado lanzar una actualización normal de Windows para esto en los 3 años posteriores a la publicación de esa revisión. Mientras la gente sigue corriendo y sacándose el pelo debido a este oscuro problema.
Conozca a las otras personas que han compartido y disfrutado este regalo de MS que aún continúa dando:

La máquina de desarrollo de Windows 7 probablemente funcionó bien porque se reinicia con más frecuencia que el servidor. Felicidades por su informe de errores muy bien escrito y completo. Rara vez veo eso aquí.

BLUF

Nuestra aplicación está intentando escribir un archivo en una carpeta UNC utilizando un servicio web ASP.NET que se ejecuta bajo .NET 4.5, IIS 7.5 y Windows Server 2008 R2. Sin embargo, cualquier intento de escribir el archivo en la ubicación deseada da como resultado una excepción de acceso denegado.

La tarea parece simple, pero mi equipo y yo hemos estado solucionando este problema por un tiempo y estamos confundidos en cuanto a lo que puede estar causando el error. A continuación se muestran los detalles de nuestra configuración y lo que hemos probado y encontrado hasta ahora. Los nombres han sido cambiados para proteger al inocente.

Configuración del entorno

El servidor web, mywebserver , tiene un sitio web llamado My.Site.Com con un grupo de aplicaciones correspondiente llamado My.Site.Com . El grupo de aplicaciones se configura como se muestra a continuación.

.NET Framework Version : v4.0 Enable 32-bit Applications : False Managed Pipeline Mode : Integrated Name : My.Site.Com Identity : ApplicationPoolIdentity Load User Profile : False

La ruta de acceso UNC a la que estamos intentando escribir es / myotherserver / mydirectories / output donde mydirectories es el recurso compartido real. En este recurso compartido, un grupo de dominios llamado mygroup-www ha recibido permisos completos para el recurso compartido y todas las subcarpetas. La cuenta de la máquina (es decir, mywebserver) es un miembro de este grupo mygroup-www.

NOTA: Por el momento, esta ruta UNC realmente vive en la misma máquina, mywebserver. Sin embargo, esto eventualmente se trasladará a una máquina distinta de mywebserver en nuestro entorno de prueba y en el entorno de producción cuando esté listo. Actualmente, solo tengo un entorno de prueba para solucionar problemas.

El error se puede replicar ejecutando el siguiente código.

[WebMethod] [ScriptMethod(UseHttpGet = false, ResponseFormat = ResponseFormat.Json)] public string ExportReport(int reportId) { try { string output = ConfigHelper.OutputPath + "test.html"; // UNC path string url = ConfigHelper.VirtualPath + "test.html"; string[] lines = { "Hello", "World!" }; File.WriteAllLines(output, lines); // Access Denied! return url; } catch (System.Exception ex) { Logger.ErrorException("Error exporting report", ex); throw; } }

Solución de problemas

Intentos fallidos

Probamos varias combinaciones de permisos de grupo / usuario en las carpetas (enumeradas a continuación). Al ejecutar estas pruebas, también ejecutamos Process Monitor. Para cada configuración vimos el mismo resultado. El proceso w3wp.exe intentó crear el archivo en la ubicación deseada, pero informó un resultado de ACCESO DENEGADO . El usuario de cada configuración fue IIS APPPOOL / My.Site.Com como se esperaba.

Concesión de permisos completos a mydomain / mymachine $ a / myotherserver / mydirectories
Concesión de permisos completos a mydomain / mymachine $ a / myotherserver / mydirectories / output

NOTA: También he intentado modificar el código para que lea un archivo simple de / myotherserver / mydirectories / output . Al intentar leer el archivo, el proceso falla con un mensaje de ACCESO NEGADO como lo hizo al escribir el archivo.

Intentos exitosos

También probamos varias configuraciones que funcionaron.

Otorgue los permisos locales de IIS APPPOOL / My.Site.Com

La primera configuración que funcionó fue otorgar permisos completos a / myotherserver / mydirectories APPISOL / My.Site.Com de IIS. Sin embargo, el usuario del proceso fue inesperadamente una cuenta de dominio que se configuró para una aplicación web en el mismo. Máquina en otro sitio web. Esto sigue siendo muy confuso pero funcionó ya que la ''otra'' cuenta también tiene permisos de escritura para el recurso compartido.

Esto no funcionará en producción ya que no podemos usar cuentas locales para otorgar acceso a recursos en red, pero es un punto de datos interesante.

Cambiar la identidad de grupo de aplicaciones a usuario de dominio

La segunda configuración que funcionó fue cambiar la identidad del grupo de aplicaciones My.Site.Com a una cuenta de dominio que tenía permisos completos para / myotherserver / mydirectories . Esta fue una cuenta de dominio "vainilla" que fue creada manualmente por nosotros. No capturamos lo que el usuario del proceso fue, pero ese puede ser otro punto de datos útil.

Esta opción puede ser posible, sin embargo, se aleja de las mejores prácticas con IIS 7.5 y puede no estar permitida en nuestro entorno de producción debido a políticas de TI bastante estrictas.

Ejecutar el sitio en mi máquina de desarrollo

La tercera prueba fue ejecutar el sitio localmente en mi máquina de desarrollo, mydevmachine . Mi configuración local de IIS es idéntica a mywebserver con la excepción de que estoy ejecutando Windows 7 en lugar de Windows Server 2008. He otorgado permisos completos para mydomain / mydevmachine a los / myotherserver / mydirectories y ejecuté la aplicación. El archivo fue escrito con éxito. Según Process Monitor, el usuario para el proceso se configuró correctamente en IIS APPPOOL / My.Site.Com .

Conclusión

Nos gustaría habilitar el acceso de escritura según lo diseñado usando la cuenta de la máquina de mywebserver . Hemos leído que el usuario ApplicationPoolIdentity no puede modificar los archivos en la carpeta compartida en Windows Server 2008 y los permisos para la Carpeta compartida para la identidad del grupo de aplicaciones de IIS 7 en las identidades de dominio y grupo de aplicaciones .

De acuerdo con esta información, deberíamos poder usar la cuenta de la máquina para otorgar acceso de lectura y escritura a los recursos en red, como la ruta UNC. De hecho, puedo hacer esto de la manera deseada cuando ejecuto el sitio web desde mi máquina de desarrollo.

Hay un par de pensamientos que vienen a la mente. Quizás haya algún problema con la cuenta de la máquina del servidor web de prueba. O quizás ese ''otro'' software está interfiriendo con el proceso de alguna manera.

¿Alguna idea sobre qué puede estar causando este problema? ¿Qué más debemos hacer para solucionar problemas?

Me enfrenté al mismo problema, lo resolví creando una cuenta de dominio para cada entorno (QA, STAGE, PRODUCTION). En la identidad del grupo de aplicaciones, he configurado una cuenta personalizada y utilicé un usuario de dominio para la cuenta correspondiente. Ahora me da la posibilidad de escribir y leer los archivos de UNC Path.

Tuve un problema similar para acceder a un recurso compartido de red utilizando AppPoolIdentity en una aplicación ASP.NET (acceso denegado). El uso de la cuenta de NetworkService u otra cuenta de dominio funcionó, pero esta no era la mejor solución. Realicé casi todas las pruebas que hiciste, pero finalmente encontré algo que funcionó.

Me di cuenta de que la cuenta del Servicio de red no se usaba cuando accedía a los recursos compartidos, igual que usted (esperaba la cuenta de dominio / máquina $)

Esto nos funcionó: en su sitio web de IIS, vaya a Autenticación y cambie el elemento Autenticación anónima a "Identidad de grupo de aplicaciones". Se establece por defecto en "IUSR". Esto solucionó nuestro problema.

También puede ser útil activar la suplantación de ASP.NET (aún en el menú de autenticación).

Thibault