En Windows Server 2012 R2, IIS se ejecuta como servidor web en condiciones habituales. Sin embargo, el contenido web no proviene de c:\inetpub\wwwroot\otra carpeta, sino de otra. Las aplicaciones web todavía se ejecutan con su propio usuario, que es de defaultAppPool.
De hecho, olvidé otorgar IIS_IUSRSderechos de lectura/ejecución a la carpeta de contenido web. Sin embargo , la carpeta sí dio acceso users. Solo agregué IIS_IUSRSderechos de lectura/ejecución/escritura si es necesario poder escribir en una subcarpeta.
Queriendo reforzar un poco la seguridad, revisé los derechos de acceso de la carpeta de contenido web y descubrí por prueba y error que ahora IIS_IUSRSfaltaba el acceso, es el acceso del usersgrupo que es responsable de que todo siga funcionando. Porque cuando elimino el acceso al usersgrupo, la aplicación deja de funcionar.
Intenté dar acceso a otras cuentas/grupos y descubrí que dar acceso a ambos userse IIS_IUSRSindividualmente hacer que mi aplicación se ejecute. Dar acceso a simplemente IIS APPPOOL\no lo hace. Pero dar acceso a mi usuario específico del grupo de aplicaciones (EG IISAPPPOOL\nl-x-homepage) sí lo hace. Y esto último es lo que quiero, ya que no quiero que una aplicación pueda acceder a archivos de otra aplicación.
Pero me preguntaba... ¿Cómo funcionan exactamente las cuentas similares a IIS? ¿Por qué otorgar acceso userstambién funciona para que mi grupo de aplicaciones acceda a la carpeta de contenido web? No puedo ver el usuario de mi grupo de aplicaciones específico en lusrmgr, pero supongo que mi usuario del grupo de aplicaciones específico está en el usersgrupo, o en algún otro grupo que esté en el usersgrupo. ¿Alguien puede confirmar esto?
Y como última pregunta sobre este asunto: para tener carpetas específicas 'protegidas con contraseña', creé un usuario normal en Windows, eliminé ese usuario del usersgrupo y en el Administrador de IIS fui a esa carpeta e hice Autenticación -> Autenticación básica - > Habilitado, y en Reglas de autenticación he configurado una regla Permitir para mi cuenta de usuario de Windows recién creada. Esto funciona. Pero al analizar el acceso de lectura/escritura me sorprendió saber que, aunque la aplicación se ejecuta bajo el usuario del grupo de aplicaciones, el usuario del grupo de aplicaciones sólo necesita derechos de lectura (sin derechos de escritura), y el usuario de Windows recién creado necesita tener derechos de lectura y escritura. derechos de escritura además de eso para que se pueda escribir en la carpeta. ¿Alguien puede ayudar a explicar por qué esto funciona de esta manera?
Respuesta1
El comportamiento que estás encontrando me parece bastante lógico.
IIS_IUSRS es un grupo, no una cuenta, cuyo único propósito es permitir que sus miembros sean asignados como identidades de grupo de aplicaciones, por lo que agregarlo por sí solo no es suficiente (como descubrió).
El grupo Usuarios contiene la cuenta ASPNET que tiene suficientes permisos para que el sitio web funcione, por lo que agregarla fue suficiente para los permisos predeterminados. Creo que la cuenta ASPNET es la que se usa como DefaultAppPool.
Un archivo o carpeta creado por un usuario siempre tiene permiso de lectura, porque el creador es el propietario y tiene todos los permisos. En el caso de que otro usuario haya creado el archivo o carpeta, otorgar solo permisos de escritura sin lectura nunca funcionó en Windows, ya que se requiere acceso de lectura para verificar los permisos y el espacio disponible y similares antes de poder escribir.
Respuesta2
IIS_IUSRS es el grupo de cuentas de procesos de trabajo de IIS. Este grupo integrado tiene acceso a todos los archivos y recursos del sistema necesarios para que una cuenta, cuando se agrega a este grupo, pueda actuar sin problemas como una identidad del grupo de aplicaciones.
Si hace clic derecho en el dominio y abre Editar permisos, debería ver los grupos y permisos enumerados. En la pestaña Seguridad, verá MACHINE_NAME\IIS_IUSRS y también /Users. IIS automáticamente tiene permiso de solo lectura en el directorio.
Para cada grupo de aplicaciones que cree, la propiedad Identity del nuevo grupo de aplicaciones se establece en ApplicationPoolIdentity de forma predeterminada. El proceso de administración de IIS (WAS) creará una cuenta virtual con el nombre del nuevo grupo de aplicaciones y ejecutará los procesos de trabajo del grupo de aplicaciones en esta cuenta de forma predeterminada. Cada vez que se crea un nuevo grupo de aplicaciones, el proceso de administración de IIS crea un identificador de seguridad (SID) que representa el nombre del propio grupo de aplicaciones. Por ejemplo, si crea un grupo de aplicaciones con el nombre "MyFirstPool", se crea un identificador de seguridad con el nombre "MyFirstPool" en el sistema de seguridad de Windows. A partir de este momento, los recursos se pueden proteger utilizando esta identidad.Sin embargo, la identidad no es una cuenta de usuario real; no aparecerá como usuario en la Consola de administración de usuarios de Windows. Este es el comportamiento normal. Si desea proporcionar acceso a una carpeta determinada, simplemente agréguela a la carpeta editando los permisos. Sin embargo, debe verificar la configuración de autenticación predeterminada (identidad anónima) y ver si está disponible la selección adecuada, o configurarla para evitar errores de acceso.
Más sobre grupos de aplicaciones.
Esta publicaciónaborda el resto de las preguntas. Herencia.
Obviamente, el usuario de Windows que está agregando aquí requiere permisos ya que la cuenta debe heredar los permisos de los grupos necesarios. El permiso de lectura aquí es vital. Sin embargo, está destinado a acceder a los recursos locales.