El acceso de escritura a TODOS funciona, IUSR, IIS_IUSRS, DefaultAppPool no funciona. ¿por qué?

Okay. Aquí estamos tratando de configurar un sitio web ASP clásico en IIS 7.5 en Windows Server 2008 R2. Hay una carpeta llamada dbc debajo de la raíz del sitio web y tiene un archivo que se usa para leer y escribir cierta información mientras se procesa cada página.

El problema es que si otorgo permisos de escritura IUSR y permisos de escritura IIS_IUSRS, o permisos de escritura DefaultAppPool, obtengo el "Acceso a la ruta 'E: .. \ websiteroot \ dbc \ filename.txt' está denegado"

Pero si concedo acceso de escritura a TODOS en esa carpeta dbc, entonces no obtengo ningún error, todo parece perfecto.

Más información: El sitio web se ejecuta en modo de canalización clásico, la autenticación anónima está habilitada (quizás es la única autenticación habilitada). Y probé la autenticación anónima usando la cuenta IUSR y la identidad del grupo de aplicaciones. En mi caso, ApplicationPoolIdentity es la identidad para la autenticación del sitio web. Utilizamos un COM + para E / S de archivo. Y Classic ASP Server.CreateObject para instanciar un objeto fuera de él. El COM + se ejecuta como un servicio de red.

Pensamientos? No quiero otorgar permiso de escritura a TODOS. ¿Me estoy perdiendo de algo?

RESUELTO: Esto es lo que hice.

Mi sitio web llamado CipherDemo se ejecutaba bajo una AppPoolIdentity en IIS 7.5, que podría ubicarse en Identity IIS AppPool \ CipherDemo. Usé ICACLS para otorgar permisos RW en esa carpeta.

y el COM + que realmente estaba haciendo el archivo de E / S se ejecutaba bajo la Identidad del servicio de red. Cuando estaba usando Process Monitor para rastrear el error de acceso denegado, resultó que el servicio de red solo tenía un permiso de lectura en esa carpeta.

Utilicé ICACLS "nombre de carpeta" / grant: r "NT AUTHORITY \ NETWORKSERVICE" :( OI) (CI) RXW / T para otorgar acceso de escritura en esa carpeta.

Y lo resolvió.

Tenía la intención de que, dado que el sitio web se ejecuta como CipherDemo Identity, esta será la cuenta que se utilizará para acceder al archivo a través de COM +. Pero es vergonzoso descubrir que el COM + aún funcionaría en sus propios límites de identidad.

Bajo IIS 7.5 (y opcionalmente en IIS 7) todos los trabajadores se ejecutan con la identidad del grupo de aplicaciones: usuario "IIS AppPool * PoolName *".

Otorgue acceso a ese usuario en lugar de a Todos (deberá escribir el nombre en los diálogos de selección de identidad; no aparecerá en la función de búsqueda).

Hay una página muy útil en iis.net que cubre las cosas con mucho más detalle.

También tenga en cuenta: bajo IIS7 (Server 2008):

• Establece la identidad del grupo de aplicaciones por grupo de aplicaciones en la configuración avanzada.
• No hay soporte de GUI, por lo que necesitará la línea de comando para establecer permisos ( icacls.exe).

Finalmente, la selección de identidad de SQL Server tampoco conoce la identidad del grupo de aplicaciones: use CREATE LOGINe CREATE USERinicialmente, después de esto, la GUI se puede usar para otorgar roles, etc.

Puede agregar la cuenta a través de la GUI de NTFS escribiéndola directamente. El nombre está en el formato de IIS APPPOOL\<<app pool name>>, por ejemplo IIS APPPOOL\DefaultAppPool. (vea este artículo de soporte de Microsoft )

Una solución alternativa: he estado usando la cuenta "Servicio de red" como usuario del grupo de aplicaciones otorgándole permiso de escritura.

Si solo desea otorgar el permiso de ESCRITURA a la carpeta para el usuario específico, también debe cambiar 'Identidad de usuario anónimo' del sitio a 'Usuario específico', no 'Identidad de grupo de aplicaciones'.