Descripción de identidades en IIS

Artículo
03/28/2022
Tiempo de lectura: 10 minutos

En este artículo se proporciona información básica sobre las identidades en Internet Information Services (IIS).

Versión del producto original: Internet Information Services
Número KB original: 4466942

Identidades del grupo de aplicaciones

Para comprender las identidades del grupo de aplicaciones, debe comprender qué es una identidad. En términos simples, una identidad es una Windows cuenta. Todos los procesos que se Windows se ejecuten con una identidad. El proceso de trabajo ejecuta las aplicaciones mediante una Windows identidad. La Windows que se usa depende de la identidad del grupo de aplicaciones, que puede ser cualquiera de las siguientes cuentas:

Windows de identidad.

Sistema local: Cuenta de confianza que tiene privilegios altos y también tiene acceso a recursos de red.
Servicio de red: Cuenta de servicio restringida o limitada que se usa para ejecutar servicios estándar con privilegios mínimos. Esta cuenta tiene menos privilegios que una cuenta del sistema local. Esta cuenta tiene acceso a recursos de red.
Servicio local: Cuenta de servicio restringida o limitada que es similar al Servicio de red y está diseñada para ejecutar servicios estándar con privilegios mínimos. Esta cuenta no tiene acceso a recursos de red.
ApplicationPoolIdentity: Cuando se crea un nuevo grupo de aplicaciones, IIS crea una cuenta virtual que tiene el nombre del nuevo grupo de aplicaciones y que ejecuta el proceso de trabajo del grupo de aplicaciones en esta cuenta. También es una cuenta con privilegios mínimos.
Cuenta personalizada: Además de estas cuentas integradas, también puede usar una cuenta personalizada especificando el nombre de usuario y la contraseña.

Diferencias entre identidades de grupo de aplicaciones

Escenario 1: Acceso al registro de eventos

En este escenario, tiene una aplicación web que crea un registro de eventos personalizado (MyWebAppZone) y un origen de registro de eventos (MyWebAppZone.com) en tiempo de ejecución. Las aplicaciones que se ejecutan mediante cualquiera de las identidades pueden escribir en el registro de eventos mediante orígenes de eventos existentes. Sin embargo, si se ejecutan con una identidad que no sea Sistema local, no pueden crear nuevos orígenes de eventos debido a que los permisos del Registro son insuficientes.

Por ejemplo, si ejecuta la aplicación en Servicio de red, recibirá la siguiente excepción de seguridad:

Al ejecutar el seguimiento de ProcMon simultáneamente, suele encontrar que NT AUTHORITY\NETWORK SERVICE no tiene los privilegios de acceso de lectura y escritura necesarios en la siguiente subclave del Registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\

Esta es la ubicación en el Registro donde se almacenan todas las opciones de un registro de eventos.

Escenario 2: Acceso al Registro

Además del sistema local, ninguna otra identidad del grupo de aplicaciones tiene acceso de escritura al Registro. En este escenario, ha desarrollado una aplicación web sencilla que puede cambiar y mostrar el nombre del servidor de hora de Internet con el que Windows se sincroniza automáticamente. Si ejecuta esta aplicación en Servicio local, se obtiene una excepción. Si comprueba el seguimiento de ProcMon, encontrará que la identidad del grupo de aplicaciones "NT AUTHORITY\LOCAL SERVICE" no tiene acceso de lectura y escritura en la siguiente subclave del Registro:

HKEY_LOCAL_MACHINE** **\SOFTWARE\Microsoft\Windows\CurrentVersion\DateTime\Servers

Captura de pantalla del Monitor de procesos 2.

Si comprueba el registro de eventos MyWebAppZone (desde el escenario 1), encontrará el siguiente evento de error registrado. Contiene un mensaje Requested registry access is not allowed de error.

Exception Type: SecurityException  
Message: Requested registry access is not allowed.  
Stack Trace  
at Microsoft.Win32.RegistryKey.OpenSubKey(String name, Boolean writable)  
at Identities.ChangeTimeServer.Page_Load(Object sender, EventArgs e)  
at System.Web.UI.Control.LoadRecursive()  
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)  
at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)  
at System.Web.UI.Page.ProcessRequest()  
at System.Web.UI.Page.ProcessRequest(HttpContext context)  
at ASP.changetimeserver_aspx.ProcessRequest(HttpContext context) in c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\fd06117a\f8c94323\App_Web_ysqbhk00.2.cs:line 0  
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()  
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Escenario 3: Cuenta personalizada en el entorno de autenticación Kerberos y equilibrio de carga

Ya ha visto en los escenarios 1 y 2 algunas de las diferencias entre las cuentas integradas. Ahora, vamos a analizar lo que es una cuenta personalizada y cómo tiene ventajas sobre las cuentas integradas cuando se trabaja con la autenticación Kerberos en un entorno de carga equilibrada.

Con este enfoque, se ejecuta la aplicación en un grupo de aplicaciones que está configurado para ejecutarse mediante una identidad Windows aplicación específica. Tenga en cuenta el siguiente diagrama, en el que una aplicación se hospeda en un entorno con equilibrio de carga que incluye dos servidores y usa la autenticación Kerberos para identificar el cliente.

Para que la autenticación Kerberos funcione, debe configurar SPN para ambos servidores mediante su cuenta de equipo. Si el grupo de aplicaciones se ejecuta en una cuenta integrada, presenta las credenciales del equipo en la red. Por ejemplo, si el nombre del equipo es Server1, se presenta como "Server1$". Esta cuenta de equipo se crea automáticamente cuando un equipo se une a un dominio. Por lo tanto, si hay servidores N, debe establecer N número de SPN que correspondan a su cuenta de equipo correspondiente.

Registrar un SPN en una cuenta de equipo:
```
setspn -a HTTP/HOSTNAME MachineAccount$
```
Ejemplo:
```
setspn -a HTTP/MyWebAppZone.com Server1$
```
Para superar esta desventaja, puede ejecutar la aplicación con una identidad de Windows (dominio) personalizada y, a continuación, establecer el SPN en solo esa cuenta de dominio específica en el controlador de dominio.

Registrar un SPN en una cuenta de dominio:
```
setspn -a HTTP/HOSTNAME domain\account
```
Ejemplo:
```
setspn -a HTTP/MyWebAppZone.com contoso.com\account_alias
```

Permisos predeterminados y derechos de usuario en wwwroot

IIS 7.0 y versiones posteriores también facilitan la configuración de una identidad de grupo de aplicaciones y realizar todos los cambios necesarios. Cuando IIS inicia un proceso de trabajo, debe crear un token que usará el proceso. Cuando se crea este token, IIS agrega automáticamente IIS_IUSRS la pertenencia al token de procesos de trabajo en tiempo de ejecución. Las cuentas que se ejecutan como identidades del grupo de aplicaciones ya no tienen que ser una parte explícita del IIS_IUSRS grupo. Si crea un sitio web y, a continuación, C:\inetpub\wwwrootapunta la ubicación física a , los siguientes usuarios y grupos se agregan automáticamente a las listas de control de acceso del sitio.

Usuarios/grupos	Permisos permitidos
CREADOR PROPIETARIO	Permisos especiales
SISTEMA	Control total
Administradores	Control total
Users	Leer & ejecutar, Enumerar el contenido de la carpeta, Leer
IIS_USRS	Leer & ejecutar
TrustedInstaller	Control total

Si desea deshabilitar esta característica IIS_IUSRS y agregar manualmente cuentas al grupo, establezca el valor manualGroupMembership en true en el archivoApplicationHost.config usuario. En el siguiente ejemplo se muestra cómo se puede hacer esto en el grupo de aplicaciones predeterminado:

<applicationPools> 
    <add name="DefaultAppPool"> 
        <processModel manualGroupMembership="true" />
    </add>
</applicationPools>

Descripción del aislamiento de configuración

Los procesos de trabajo de IIS no tienen acceso de lectura alApplicationHost.config archivo. Por lo tanto, es posible que se pregunte cómo pueden leer cualquiera de los conjuntos de configuraciones de este archivo.

La respuesta es mediante el uso de la característica de aislamiento de configuración en IIS 7.0 y versiones posteriores. En lugar de permitir que los procesos de trabajo de IIS lean ApplicationHost.config directamente al leer la jerarquía de archivos de configuración, el servicio de activación de procesos (WAS) de Windows genera copias filtradas de este archivo. Cada proceso de trabajo de IIS usa estas copias como reemplazo de ApplicationHost.config cuando se lee la configuración dentro del proceso de trabajo de IIS. Estos archivos se generan de forma predeterminada en el %SystemDrive%\inetpub\Temp\appPools directorio y se denominan {AppPoolName}.config. Estos archivos están configurados para permitir el acceso solo a los procesos de trabajo de IIS en el grupo de aplicaciones correspondiente mediante IIS APPPOOL\AppPoolName el identificador de seguridad (SID) del grupo de aplicaciones.

Nota

Para obtener más información sobre SID, vea el tema Identificadores de seguridad en el sitio web de Microsoft Docs.

Captura de pantalla del uso del grupo de aplicaciones para el aislamiento de configuración.

Esto se hace para evitar que los procesos de trabajo de IIS del grupo de aplicaciones A puedan leer información de configuración en el archivo ApplicationHost.config que está diseñado para el grupo de aplicaciones B.

ApplicationHost.config puede contener información personal confidencial, como el nombre de usuario y la contraseña de las identidades de grupo de aplicaciones personalizadas, o el nombre de usuario y la contraseña de los directorios virtuales. Por lo tanto, permitir que todos los grupos de aplicaciones accedan ApplicationHost.configinterrumpiría el aislamiento del grupo de aplicaciones. Si cada grupo de aplicaciones tiene acceso directo al archivo ApplicationHost.config , estos grupos podrían piratear fácilmente información confidencial de otros grupos de aplicaciones ejecutando el siguiente comando:

appcmd list APPPOOL "DefaultAppPool" /text:*

Captura de pantalla del uso del comando appcmd.

IUSR: autenticación anónima

La autenticación anónima permite a los usuarios acceder a las áreas públicas del sitio web sin que se le pida un nombre de usuario o una contraseña. En IIS 7.0 y versiones posteriores, se usa una cuenta integrada, IUSR, para proporcionar acceso anónimo. Esta cuenta integrada no requiere una contraseña. Será la identidad predeterminada que se usa cuando se habilita la autenticación anónima. En el ApplicationHost.config , puede ver la siguiente definición:

<authentication>
     <anonymousAuthentication enabled="true" userName="IUSR" />
 </authentication>

Esto indica a IIS que use la nueva cuenta integrada para todas las solicitudes de autenticación anónima. Las ventajas más importantes para hacerlo son las siguientes:

Ya no tiene que preocuparse de que las contraseñas expiren para esta cuenta.
Puede usar xcopy /o para copiar archivos junto con su propiedad e información de ACL en diferentes equipos sin problemas.

También puede proporcionar autenticación anónima a su sitio web mediante una cuenta Windows o identidad del grupo de aplicaciones en lugar de una IUSR cuenta.

IUSR frente Conectar como

Conectar como es una opción en IIS que le permite decidir qué credenciales desea usar para tener acceso al sitio web. Puede usar las credenciales de usuario autenticadas o las credenciales de usuario específicas. Para comprender la diferencia, considere el siguiente escenario:

Tiene un sitio web predeterminado que está configurado para usar la autenticación anónima. Sin embargo, el contenido del sitio web está en otro servidor y usa la Conectar como sección para obtener acceso a ese recurso a través de un usuario Test de dominio. Cuando el usuario inicia sesión, se autentica mediante una cuenta IUSR. Sin embargo, se tiene acceso al contenido del sitio web a través de las credenciales de usuario que se mencionan en Conectar como sección.

En pocas palabras, la autenticación anónima es el mecanismo que usa el sitio web para identificar a un usuario. Pero al usar esta característica, el usuario no tiene que proporcionar ninguna credencial. Sin embargo, puede haber un escenario similar en el que el contenido se encuentra en un recurso compartido de red. En tales casos, no puede usar cuentas integradas para acceder al recurso compartido de red. En su lugar, debe usar una cuenta específica (dominio) para hacerlo.

ASP.NET suplantación

Literalmente, la suplantación significa el acto de pretender ser otra persona. En términos técnicos, es una característica ASP.NET seguridad que proporciona la capacidad de controlar la identidad bajo la que se ejecuta el código de aplicación. La suplantación se produce cuando ASP.NET código en el contexto de un cliente autenticado y autorizado. IIS proporciona acceso anónimo a los recursos mediante una IUSR cuenta. Después de pasar la solicitud a ASP.NET, el código de aplicación se ejecuta mediante la identidad del grupo de aplicaciones.

La suplantación se puede habilitar a través de IIS y ASP.NET código si la aplicación usa autenticación anónima y si se cumple una de las siguientes condiciones:

Si IMPERSONATION está deshabilitada, se usa la identidad del grupo de aplicaciones para ejecutar el código de aplicación.
Si IMPERSONATION está habilitado, NT AUTHORITY\IUSR se usa para ejecutar el código de la aplicación.

Cuando impersonation se habilita a través de IIS, agrega la siguiente etiqueta en el archivo Web.config de la aplicación para suplantar la cuenta autenticada o el usuario de IIS: <identity impersonate="true" />

Para suplantar un usuario específico para todas las solicitudes de todas las páginas de una aplicación de ASP.NET, <identity> puede especificar los atributos de nombre de usuario y contraseña en la etiqueta del archivo Web.config para esa aplicación.

<identity impersonate="true" userName="accountname" password="password" />

Para implementar la suplantación ASP.NET código, vea Implementar la suplantación en una ASP.NET aplicación

Abra el proceso de trabajo de IIS de un sitio web de prueba que suplanta a Test un usuario local y compruebe si puede encontrar la cuenta de suplantación en la que se ejecuta el código de la aplicación.

La identidad del grupo de aplicaciones de la aplicación se establece en ApplicationPoolIdentity y la autenticación anónima se proporciona mediante cuenta IUSR . Puede rastrear fácilmente la identidad de suplantación mediante ProcMon. Por ejemplo, si examina uno de los eventos CreateFile que corresponden al proceso de w3wp.exe que está examinando, puede encontrar la cuenta de suplantación, como se muestra en la siguiente captura de pantalla.

Detalles de la suplantación en propiedades de evento.