El sitio web no logra obtener el permiso adecuado para escribir en una carpeta en Windows 2012R2 con IIS 8.5 a pesar de que 'IIS APPPOOL\PoolName' está configurado correctamente

El sitio web no logra obtener el permiso adecuado para escribir en una carpeta en Windows 2012R2 con IIS 8.5 a pesar de que 'IIS APPPOOL\PoolName' está configurado correctamente

Tengo problemas específicos con respecto a IIS 8.5, permisos y auditoría. Tengo una aplicación PHP ejecutándose bajo la identidad de KanboardPool y configuré correctamente los permisos en la carpeta 'datos' de la aplicación en 'IIS APPPOOL\KanboardPool' para tener control total.

Además, configuré IIS_IUSRS para leer, ejecutar y enumerar en la misma carpeta, incluida la carpeta principal. A pesar de todo; Sigo recibiendo errores de permiso denegado.

Intenté AUDITAR las fallas de acceso a archivos sin mucha suerte: primero a través de la Política de dominio de GPO -> Configuración de la computadora -> Configuración de Windows -> Configuración de seguridad -> Auditoría avanzada -> Auditar el éxito y el fracaso del acceso a archivos. Que no registró ninguna falla de auditoría. Mismo procedimiento a través de la Política de Controlador de Dominio y por último a través de la Política Local por cualquier motivo. El cambio de política de auditoría se agrega y luego se elimina sucesivamente.

A través de ACL, ejecuté una prueba de acceso efectivo en el principal seleccionado 'IIS APPPOOL\KanboardPool' que pasó con gran éxito. ¿Ahora estoy perplejo?

Respuesta1

Lo que hizo que este problema fuera particularmente difícil de diagnosticar es que no era reproducible en condicionesSitio web predeterminado. Cuando presenté la misma solicitud bajo C:\inetpub\wwwroot\subfoldeer\phpapplicationidentidad DefaultAppPool.

Fue muy fácil para mí simplemente agregarControl totalpara C:\inetpub\wwwroot\subfolder\phpapplication\datay DefaultAppPoolsimplemente funcionó.

Despues de leerhttp://www.iis.net/learn/get-started/planning-for-security/secure-content-in-iis-through-file-system-acls; con fcgi.impersonateencendido php.ini; automáticamente se hará pasar por el usuario autenticado. Viola, al desactivar esta función, el proceso PHP asumió AppPoolIdentity y funcionó como se esperaba.

Lo que explica por qué no recibí fallas de acceso a archivos para KanboardPool. Sin embargo, no explica mientras fcgi.impersonateeso estaba activado enSitio web predeterminadoInicialmente no estaba reproduciendo el mismo comportamiento.

información relacionada