¿Qué papel desempeña la "Identidad del grupo de aplicaciones" para un grupo de aplicaciones?

Cuando hablamos de la seguridad de IIS 7.5, AFAIK:

App Pool Identity decide con quién se ejecuta mi aplicación web.

El método de autenticación decide con quién se autentica a los clientes.

Tengo una carpeta virtual configurada así:

• Utilizo la autenticación anónima con la expectativa de que todos los clientes deben autenticarse como IUSR .
• Le doy a IUSR el control total de la carpeta.
• My App Pool Identity se configura como la cuenta XXX, que no tiene ningún permiso para la carpeta. (Lo configuré intencionalmente)

Pero resulta que no puedo examinar los archivos en esa carpeta. Una vez que le doy permiso a la cuenta XXX para acceder a esa carpeta, todo va bien.

Entonces, ¿qué papel juega la identidad del grupo de aplicaciones en la autenticación anónima? Es totalmente inesperado que tenga que dar permiso a la cuenta de App Pool Identity para acceder a la carpeta. ¿Pensé que la autenticación anónima sería suficiente?

Gracias.

Aquí hay muchos términos sobrecargados y un cambio entre IIS 7 y 7.5.

App Pool Identity vs App Pool Account

Comencemos con la identidad del grupo de aplicaciones (minúscula I, también conocida como cuenta del grupo de aplicaciones ):

La forma en que lo digo es que la cuenta del grupo de aplicaciones es la cuenta utilizada para iniciar un grupo de aplicaciones y la identidad que el grupo de aplicaciones asume cuando no se hace pasar por otra persona.

Por lo tanto, sea cual sea la identidad que le dé al grupo de aplicaciones, tendrá que poder leer los archivos en la carpeta de contenido : particularmente {pero no limitado a} cualquier archivo web.config (que forma parte de la configuración de IIS y controlar qué App Pool va a estar haciendo).

Si no puede acceder a una carpeta, asumirá que puede haber un archivo web.config importante (que cambia el juego) allí, y mostrará un error. Por lo tanto, la cuenta del grupo de aplicaciones necesita acceso de lectura a todas las carpetas de contenido.

ApplicationPoolIdentity

¿Por qué diferenciar la cuenta del grupo de aplicaciones (la identidad del grupo de aplicaciones) de la identidad del grupo de aplicaciones? Debido a que ApplicationPoolIdentity es un nuevo tipo de cuenta , una cuenta de servicio administrado, introducida y predeterminada en IIS 7.5 / Windows 2008 R2, y también disponible en Windows 2008 SP2 (pero no la predeterminada).

Consulte Identidades de grupo de aplicaciones en IIS.Net

Cuando crea un sitio web en R2 con la GUI:

• se creará un grupo de aplicaciones para alojar ese sitio web y
• el tipo de cuenta será ApplicationPoolIdentity, en lugar de Servicio de red (el valor predeterminado de 2008), Servicio local o Sistema local.

Con 2008 RTM, la cuenta predeterminada grupo de aplicaciones de servicio de red era más una identidad única piscina del app / uniquifier; la nueva R2 / SP2 AppPoolIdentity tipo de cuenta es una Red-Service- como cuenta (es decir, es el equipo cuando se conecta fuera de la caja), pero impide la suplantación de otro grupo de aplicaciones dentro de la misma caja.

De vuelta a la pregunta original:

• App cuenta del grupo define que su aplicación se ejecuta como cuando no es hacerse pasar por cualquier otra persona

• Método de autenticación describe cómo se va a autenticar a los clientes (con el fin de hacerse pasar por ellos)

• Los anónimos cuenta de usuario define quién vas a correr como cuando suplantación de un usuario de una petición que no está autenticada - IUSR es tal un usuario.

Por cierto, con IIS 7.5, puede configurar la cuenta de usuario anónimo a ser la identidad del grupo de aplicaciones (propiedades del método de autenticación anónima), lo que podría hacer que sea más fácil de aislar y proteger el contenido de un sitio web determinado.

Establecer permisos de IIS utilizando AppPool \ YourSiteName para el formato de nombre. (véase también este post )

Estás viendo dos cosas, que comúnmente se confunden en ASP.NET:

1. "identidad de usuario": la autenticación de una cuenta de usuario no tiene nada que ver con la cuenta o identidad que realmente se ejecuta tanto en IIs como en ASP.NET. La autenticación anónima permite a cualquier usuario acceder a cualquier contenido público sin proporcionar un desafío de nombre de usuario y contraseña al navegador del cliente. La cuenta anónima IUSR que se autentica por defecto en IIS solo aplica el acceso al contenido público del sitio web. No afecta los procesos o recursos utilizados por los IIs subyacentes o los servicios ASP.NET.
2. "identidad de la aplicación": esta es la cuenta real de "WindowsIdentity" en el servidor que realmente se ejecuta detrás de IIS y ASP.NET, que es la cuenta de Identidad del grupo de aplicaciones asignada al grupo por IIs y dada a ASP.NET. Su proceso ASP.NET se ejecuta bajo esta cuenta de Identidad de grupo de aplicaciones (llamada una cuenta virtual en IIs versión 7.5+) de forma predeterminada.

Explicación: Primero, la "autenticación" en ASP.NET es solo un evento generalmente configurado en web.config que inicia sesión en una cuenta de usuario determinada que se pasa como un token de usuario por IIs a ASP.NET como un objeto HttpContext simple ... es decir, la sesión actual o el contexto del usuario actual. En realidad, no cambia la identidad de Windows que ejecuta el proceso ASP.NET, solo le pasa un token de identificación de usuario. Usando HttpContext, su código puede usar esa identificación o nombre para almacenar los derechos de la base de datos en varias secciones de su sitio web. Pero no afectará el acceso a los archivos por ASP.NET porque no afecta ni cambia la identidad de la cuenta real de "proceso" de la aplicación que ejecuta ASP.NET bajo IIs.

Eso no sucede hasta que haces "Suplantación", que le dice a ASP.NET que se haga pasar por cualquier token que le pasen los IIs y que luego se ejecute con esa identificación de cuenta. Puede configurar la suplantación en su web.config. Cuando activa la suplantación en ASP.NET, WindowsIdentity cambia en el proceso de trabajo a cualquier cuenta autenticada que se pase a ASP.NET desde IIS, y luego puede acceder a los archivos, en función de los derechos que asigne a esa cuenta de usuario. Es importante tener en cuenta que cuando esto ocurre es temporal y ASP.NET puede volver a su identidad de proceso predeterminada, que está en las versiones actuales de II nuevamente, la cuenta de Identidad de grupo de aplicaciones asignada a un Grupo de aplicaciones dado.

Cuando IIs solo usa la cuenta de usuario anónima simple sin autenticación explícita establecida en ASP.NET, IIs inicia de manera predeterminada la cuenta de Identidad de grupo de aplicaciones asignada del grupo de aplicaciones del sitio web y la pasa a ASP.NET y el proceso de trabajo que la ejecuta. Esa cuenta de identidad del grupo de aplicaciones procesa todas las solicitudes de IIS y ejecuta ASP.NET para ese sitio.

Cuando IIs comienza bajo esta configuración y un usuario accede a él, en realidad se autentica detrás de escena de forma predeterminada la cuenta anónima IUSR que determina el acceso a las páginas web y otros recursos básicos. Pero esa cuenta NO se pasa a ASP.NET. Y no afecta la identidad del grupo de aplicaciones que ejecuta IIS y en qué ASP.NET se ejecuta.

Si establece Impersonate en "true" en say your web.config, Y está utilizando la cuenta IUSR anónima predeterminada en IIs para acceso público, Y establece en true explícitamente la propiedad anonymousAuthentication en web.config (en lugar de usar un Windows u otra cuenta de inicio de sesión), IIs eliminará la identidad del grupo de aplicaciones y IIs y ASP.NET ahora ejecutarán sus procesos de aplicación como la cuenta anónima autenticada y suplantada de IUSR.

Cuando haga eso, ASP.NET y sus procesos ahora se ejecutarán con la cuenta IUSR ... es decir, el proceso de aplicaciones de ASP.NET ejecutará su cuenta WindowsIdentity como la cuenta IUSR. Ahora puede aplicar el acceso de lectura / escritura a esa cuenta anónima IUSR y a las carpetas a las que desea que acceda esa cuenta. (Nota: asegúrese de agregar la cuenta de proceso predeterminada, la cuenta del grupo de aplicaciones para el grupo, los derechos también a esas carpetas. De acuerdo con la recomendación de Microsoft)

¡Buena suerte!

Hay dos contextos de autenticación en juego. El proceso del servidor web (que maneja sus solicitudes web) se ejecuta como el usuario de App Pool Identity. Cuando llega una solicitud para su host virtual, el grupo de aplicaciones se hace pasar por el usuario que figura en las "Credenciales de autenticación anónima" del sitio específico, por defecto IUSR.

Cualquier secuencia de comandos que se ejecute desde su sitio web se ejecutará como IUSR, pero el registro y ciertas otras funciones se ejecutarán como el Usuario del grupo de aplicaciones (por defecto, Servicio de red, aunque esto se ha cambiado recientemente para usar un usuario especial del grupo de aplicaciones virtuales). La identidad del grupo de aplicaciones (servicio de red) debe poder enumerar los archivos en su directorio, ya que se realizan ciertas comprobaciones en la pila de solicitudes antes de que el control se transfiera a su script.

Es una buena práctica ejecutar un sitio por grupo y configurar la identidad del grupo de aplicaciones para que se ejecute como el mismo usuario que el usuario anónimo de su sitio web. Es posible salir del contexto de usuario anónimo (IUSR) y elevar los privilegios a los de la propia identidad del grupo de aplicaciones.