Identidad de proceso y solicitud en ASP.NET

En este artículo se describe los derechos de acceso que se conceden a la cuenta de proceso predeterminada y describe algunas situaciones en que estos derechos pueden ser demasiado restrictivos para determinadas tareas.

En la instalación predeterminada de ASP.NET en Microsoft Windows 2000 y Microsoft Windows XP, ASP.NET ejecuta Web código de la aplicación en un proceso de trabajo. La identidad de este proceso utiliza una cuenta local denominada la cuenta ASPNET (donde el nombre completo es la cuenta aspnet_wp) de forma predeterminada. En las versiones beta de ASP.NET, la identidad del proceso es System, que es una eficaz cuenta administrativa incluye muchos derechos de acceso en el equipo. Para proporcionar una instalación predeterminada con menos privilegios, la versión de ASP.NET utiliza la cuenta ASPNET más débil, que es adecuada para la mayoría de aplicaciones Web.

Nota De forma predeterminada, si está utilizando Microsoft Internet Information Services (IIS) 6.0, las aplicaciones Web ASP.NET ejecutará en el contexto de seguridad de la cuenta NetworkService.

Configurar la identidad de proceso

Puede configurar la identidad del proceso en el <processmodel> sección del archivo Machine.config en el subdirectorio Config del directorio raíz de instalación. El userName y los atributos de contraseña controlan la identidad del proceso. Los valores de predeterminada de estos atributos son como sigue: el equipo y los valores de AutoGenerate indicar a ASP.NET para utilizar la cuenta ASPNET integrada y utilizar una contraseña aleatoria sólidamente que se almacena en la autoridad de seguridad local (LSA) para esa cuenta.

Si desea utilizar un proceso que tiene más derechos de acceso, puede establecer el atributo userName a System , lo que hace que el proceso de trabajo ASP.NET se ejecute con la misma identidad que el proceso Inetinfo.exe. El proceso Inetinfo.exe se ejecuta de forma predeterminada como identidad del sistema. Cuando configura el proceso de trabajo ASP.NET para utilizar la identidad sistema, el proceso de trabajo de ASP.NET puede obtener acceso a casi todos los recursos en el equipo local. En los equipos que ejecutan Windows 2000, Windows XP o Microsoft Windows Server 2003, la cuenta del sistema también tiene las credenciales de red y puede tener acceso a recursos como la cuenta de equipo de red. Para configurar el proceso para ejecutarse como la identidad sistema, cambie el atributo userName en la <processmodel> sección como sigue:

Permisos predeterminados para la cuenta ASPNET

La cuenta ASPNET se crea como una cuenta local cuando se instala ASP.NET. La cuenta ASPNET pertenece sólo al grupo de usuarios en ese equipo. Por lo tanto, la cuenta ASPNET tiene todos los derechos que están asociados con el grupo de usuarios y pueden tener acceso a cualquier recursos que el grupo de usuarios se concede acceso a. La cuenta ASPNET hereda los siguientes derechos de usuario de los usuarios de grupo.Junto con estos derechos, la cuenta ASPNET se concede también los siguientes derechos de forma predeterminada: ASP.NET concede específico, completa - permisos de acceso para el ASPNET cuenta en las carpetas siguientes:

• Archivos temporales de ASP.NET
• %windir%\temp

Además, ASP.NET concede permiso de lectura para el directorio de instalación de Microsoft .NET Framework.

En la lista siguiente se resume la listas de control de acceso (ACL) que son necesarios para la cuenta ASPNET. Las instalaciones predeterminadas de Windows 2000 y Microsoft .NET Framework incluyen estas ACL.

• ubicación : % installroot%\ASP.NET archivos temporales
  Tipo de acceso : lectura y escritura en la carpeta y Listar carpeta contenido en la carpeta raíz de la unidad
  cuenta : cuenta de proceso y configurar cuentas de suplantación
  Descripción : esta es la ubicación de compilación dinámica de ASP.NET. Bajo esta ubicación, se genera el código de la aplicación en un directorio discreto para cada aplicación. Puede utilizar el atributo tempDir de la <compilation> sección para configurar la ubicación raíz.
  
  Nota Si cambia el archivo machine.config para guardar los archivos temporales de ASP.NET en una ubicación diferente, la cuenta ASPNET debe tener el tipo de Contenido de la carpeta lista de acceso en el nivel raíz de la unidad.
• ubicación : % windir%\temp
  tipo de acceso : lectura y escritura
  cuenta : cuenta de proceso
  Descripción : se trata de la ubicación que los utiliza para generar servidores proxy de serialización servicios de lenguaje de marcado extensible (XML) Web.
• ubicación : directorio de aplicación
  tipo de acceso : lectura
  cuenta : cuenta de proceso y configurar cuentas de suplantación
  Descripción : esta es la ubicación de contenido de aplicación (sólo acceso de lectura necesarios).
  Para obtener más información al respecto, visite el siguiente sitio Web de Microsoft:
  http://msdn2.microsoft.com/en-us/library/aa302396.aspx (http://msdn2.microsoft.com/en-us/library/aa302396.aspx)
• ubicación : sitio Web raíz (%systemdrive%\inetpub\wwwroot o la ruta de acceso que señala el sitio Web predeterminado)
  tipo de acceso : lectura
  cuenta : cuenta de proceso y configurar cuentas de suplantación
  Descripción : ASP.NET intenta leer archivos de configuración y supervisar los cambios en la drive: \inetpub\wwwroot\web.config.
• ubicación : jerarquía % installroot %
  tipo de acceso : lectura
  cuenta : cuenta de proceso y configurar cuentas de suplantación
  Descripción : ASP.NET debe poder tener acceso a los ensamblados de .NET Framework en el archivo Machine.config (en el subdirectorio \Config bajo % installroot %).
• ubicación : %windir%\assembly
  tipo de acceso : lectura
  cuenta : cuenta de proceso o configurado cuentas de suplantación
  Descripción : se trata de la caché de ensamblados global que contiene los ensamblados compartidos.

Para obtener más información acerca de predeterminado los equipos basados en ACL de Windows 2000, consulte la referencia "Default Access Control configuración en Windows 2000" en la sección REFERENCES.

Nota De forma predeterminada, la cuenta ASPNET generalmente no tiene derechos de acceso correcta para realizar algunas de las tareas que se describen en este artículo.

Acceso a recursos

Las secciones siguientes describen cómo utilizar diversos recursos. Puede tener acceso a muchos de estos recursos localmente si habilita la suplantación y si concede el acceso de cuenta suplantada al recurso. Sin embargo, la suplantación a menudo no funciona cuando intenta tener acceso a recursos remotos a menos que la aplicación utiliza un mecanismo de autenticación que se puede delegar, como Kerberos o autenticación básica. También puede utilizar los servicios COM + para tener acceso a los recursos, que se describe en la Running code with a fixed identity sección.

Utilizar recursos de archivo

Para habilitar una aplicación que se ejecuta con la cuenta ASPNET para escribir en archivos, puede suplantar a un usuario específico en el código antes de escribiendo a archivos o puede conceder permisos de escritura para la cuenta ASPNET. Puede conceder escribir permisos para un archivo individual o para jerarquías de directorios.

importante Cuando concede permisos de escritura para un archivo individual o para jerarquías de directorio para la cuenta ASPNET, todas las aplicaciones ASP.NET Web que se ejecutan bajo la cuenta ASPNET en el servidor también son capaces de escribir en este archivo o las jerarquías de directorio. Para obtener más información acerca de la suplantación de un usuario específico en el código, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base: Para cambiar el acceso a la lista de control para un archivo, siga estos pasos:

1. Abra el Explorador de Windows.
2. Seleccione el archivo o la carpeta que desee cambiar permisos.
3. En el menú archivo , haga clic en Propiedades .
4. En la ficha seguridad haga clic para seleccionar las casillas de verificación de la ACL permisos.

También puede utilizar secuencias de comandos o la herramienta de línea de comandos de cacls.exe (que se incluye con Windows) para cambiar las ACL para un archivo.

ASP.NET 1.1 utiliza el <DriveName> \Documents and Settings\ <MachineName> carpeta \ASPNET para almacenar los archivos de proceso (donde <DriveName> es la unidad del equipo donde está instalado ASP.NET y <MachineName> es el nombre del equipo).

Habilitar la suplantación

Con la suplantación, se ejecuta en el contexto de seguridad de la entidad de solicitud, como un usuario autenticado o como un usuario anónimo. En ASP.NET, suplantación es opcional y no está habilitada de forma predeterminada. Para habilitar la suplantación en el nivel del equipo o la aplicación, agregue la siguiente directiva de configuración en el <system.web> sección del archivo Machine.config o el archivo Web.config:

Uso de bases de datos

Aplicaciones que utilizan autenticación de SQL para conectarse a una base de datos no se suele afectadas por el modificador a la cuenta ASPNET. También es cierto para aplicaciones que utilizan la autenticación integrada y suplantación. Sin embargo, si una aplicación no está realizando la suplantación y está utilizando Windows autenticación, debe conceder acceso a la base de datos para el ASPNET cuenta.

Cuando intenta autenticar a Microsoft SQL Server mediante autenticación integrada de Windows a través de canalizaciones con nombre no puede utilizar la cuenta ASPNET. Sin embargo, puede utilizar la cuenta ASPNET correctamente con autenticación integrada de Windows a través el protocolo de control de transporte (TCP) transporte.

Si una aplicación debe usar una base de datos de Microsoft Access, la cuenta ASPNET debe poder escribir en el archivo de base de datos. Los administradores deben ajustar en consecuencia los permisos de archivo.

Utilizando el registro de eventos

Las aplicaciones que deben escribir para el registro de sucesos de aplicación pueden hacerlo mientras se ejecutan como la cuenta ASPNET. Si una aplicación debe crear una nueva categoría de registro de sucesos, la aplicación debe crear una clave del Registro bajo el subárbol del Registro HKEY_LOCAL_MACHINE , que no se puede realizar la cuenta ASPNET.

Para crear la categoría en tiempo de ejecución, debe habilitar la suplantación y, a continuación, debe representar una cuenta que tiene más derechos de acceso. Como alternativa, un administrador puede crear la categoría, y la aplicación puede escribir en la categoría en tiempo de ejecución.

Si las aplicaciones deben crear nuevas categorías de registro de sucesos, crear las categorías en la instalación. Después de crea la categoría, la cuenta ASPNET puede escribir en el registro de sucesos de aplicación.

Mediante System.DirectoryServices y Active Directory

Si una aplicación Web debe tener acceso a Active Directory, la aplicación puede utilizar la suplantación en un entorno que admite la delegación. Como alternativa, la aplicación puede proporcionar credenciales explícitas al constructor DirectoryEntry en el espacio de nombres System.DirectoryServices para tener acceso a Active Directory. Si la aplicación utiliza credenciales explícitas, las aplicaciones deben almacenar credenciales correctamente mediante una técnica como cadenas de construcción de COM + o con el Windows interfaces de programación de aplicación de protección de datos (API).

Mediante contadores de rendimiento

La cuenta de ASPNET tiene permisos suficientes para escribir en (pero no a leer) los datos del contador de rendimiento. Si la aplicación debe leer los datos del contador de rendimiento o crear categorías de contador de rendimiento, son necesarios permisos de administrador o Power User.

Si una aplicación debe crear categorías de contadores de rendimiento nuevo, crear las categorías en la instalación. Una vez creadas las categorías, la cuenta ASPNET puede escribir en los contadores.

Puede utilizar la herramienta Monitor de rendimiento (Perfmon.exe) para supervisar el rendimiento de ASP.NET los contadores cuando se utiliza el ASPNET cuenta.

En Windows 2000, siga estos pasos:

1. Ejecute el Editor del registro.
2. Busque la siguiente clave del registro:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ASP.NET_1.1.4322\Names
3. Haga clic en la ficha seguridad.
4. Agregar la identidad del proceso de trabajo con los permisos siguientes:
   • Consultar valor
   • Establecer valor
   • Crear subclave
   • Enumerar subclaves
   • Notificar al control de lectura

En Windows Server 2003, agregue la identidad a IIS_WPG el grupo.

Iniciar servidores COM fuera de proceso

Las aplicaciones que deben iniciar servidores COM fuera de proceso mientras se ejecuta como la cuenta ASPNET puede conceder específicamente iniciar permisos a la cuenta mediante la herramienta DCOMCNFG.exe.

Problemas de depuración

De forma predeterminada, no se puede recorrer una llamada de servicio Web XML desde una aplicación de cliente. Pasar a los servicios Web XML, debe agregar al grupo usuarios del depurador de la cuenta ASPNET el en el equipo donde se ejecuta el servicio Web XML.

Ejecutar código con una identidad fija

En los servicios COM +, puede ejecutar código con una identidad fija. Puede utilizar la clase ServicedComponent del espacio de nombres System.EnterpriseServices para escribir componentes de código administrado que utilizan COM + servicios. Puede ajustar la funcionalidad privilegiada en una clase que se deriva de ServicedComponent y, a continuación, ejecutar esta clase como una aplicación de servidor COM + con una identidad configurada.

Compilar archivos de código subyacente en recursos compartidos UNC

En ASP.NET, puede utilizar varios métodos para desarrollar archivos de aplicación:

• Puede utilizar el lenguaje de marcado de hipertexto (HTML) en un archivo .aspx y, a continuación, puede almacenar el código de la página en un ensamblado precompilado en el directorio bin. Éste es el modelo de Visual Studio.NET.
• Puede empaquetar todo el código y el contenido HTML en un único archivo fuente que se compila a petición.
• Puede colocar la presentación de HTML en un archivo de ASP.NET y, a continuación, dinámicamente puede compilar en cualquier código de origen asociado para ese archivo utilizando un atributo src en el < % @ Assembly % > directiva.

Nota Si se encuentra contenido de la aplicación en un recurso compartido de red, el compilador comienza en la cuenta ASPNET y no tiene credenciales de red para tener acceso al archivo. Si utiliza recursos compartidos de red, no puede utilizar el atributo src para señalar a un archivo. Debe utilizar uno de los otros métodos en su lugar.

El uso de ASP.NET en un principal o un controlador de dominio de reserva

De forma predeterminada, si está utilizando ASP.NET 1.1 en un controlador de dominio, las aplicaciones Web ASP.NET se ejecutarán en el contexto de seguridad de IWAM_ <ComputerName> cuenta (donde <ComputerName> es el nombre del equipo).

Para obtener más información, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base: back to the top

Leer la metabase de IIS

La cuenta ASPNET no puede leer Microsoft Internet Information metabase Services (IIS). Si una aplicación debe tener acceso a la configuración de la metabase, selectivamente puede conceder acceso de lectura a los nodos de la metabase utilizando el Metaacl.exe utilidad.

Si una aplicación debe utilizar archivos .disco, que se basan en la capacidad para leer la metabase de IIS para proporcionar servicios de descubrimiento, debe conceder acceso de lectura a la metabase para la cuenta ASPNET.

Utilizar System.Management y WMI

(WMI) es una funcionalidad eficaces y administrativa que puede utilizar para administrar y supervisar equipos basados en Windows. Sin embargo, cuando las aplicaciones ASP.NET se ejecutan bajo la cuenta ASPNET, esta cuenta sólo tiene el mismo permisos de acceso predeterminado como todos. Estos permisos incluyen leer datos WMI, escribir proveedor de datos y ejecutar métodos para proveedores en el equipo local. Obtener más información acerca de los mecanismos de seguridad WMI puede encontrarse en el SDK de WMI documentación o en MSDN.

Nota En Windows 2000 sin service pack 3 (SP3) o posterior, o en Windows XP sin service pack 1 (SP1) o posterior, las aplicaciones Web ASP.NET que ejecutan bajo la cuenta ASPNET no funcionen y que reciba un "acceso denegado (0x80041003)" mensaje de error. Esto ocurre porque la cuenta no tiene suficientes privilegios para tener acceso a determinados espacios de nombres WMI. Para resolver el problema, instale Windows XP SP1 o posterior, o Windows 2000 SP3 o posterior. Para evitar el problema, siga estos pasos:

1. Abrir el administración de equipos Microsoft Management Console (MMC).
2. Expanda servicios y aplicaciones y, a continuación, seleccione Control de WMI .
3. Haga clic con el botón secundario en Control WMI y, a continuación, haga clic en Propiedades .
4. En el cuadro de diálogo Propiedades de control de WMI , haga clic en la ficha seguridad .
5. Expanda raíz , seleccione CIMV2 y, a continuación, haga clic en seguridad .
6. En el cuadro de diálogo seguridad , haga clic en Avanzadas .
7. En el cuadro de diálogo Configuración de control de acceso , haga clic en Agregar . Seleccione localMachineName \ASPNET y, a continuación, haga clic en Aceptar .
8. En el cuadro de diálogo Entrada de permiso , asegúrese de que Aplicar en está establecido en este espacio de nombres y subespacios de nombres .
9. Asegúrese de que la casillas de verificación Permitir Habilitar cuenta y Permitir ' Habilitar remoto ' están seleccionadas.
10. Haga clic en Aceptar en cada cuadro de diálogo hasta que regrese al cuadro de diálogo Propiedades de control de WMI .
11. Repita los pasos 5 a 10 para otros espacios de nombres WMI que tendrán acceso la aplicación.
12. Reiniciar IIS. Para ello, ejecute IISRESET desde la línea de comandos.

De forma predeterminada, ASP.NET genera una contraseña segura criptográficamente para la cuenta ASPNET. Por lo tanto, esta solución es segura, siempre que la contraseña de cuenta ASPNET no es compartida entre equipos o restablecer en un valor distinto del predeterminado.

Interactuar con el escritorio

Cuando Servicios de IIS están configurados para permitir la interacción con el escritorio, la cuenta ASPNET no tiene los derechos adecuados para tener acceso al escritorio debido del acceso control listas discrecional (DACL) en la estación de ventana predeterminado y el escritorio. Los administradores pueden cambiar estas DACL o puede ejecutar el proceso con una cuenta que tiene permiso de acceso a estos objetos.

Quitar ASP.NET

Quitar ASP.NET, la cuenta ASPNET está deshabilitada y permanece en el sistema. Puede eliminar la cuenta ASPNET si no piensa reinstalar ASP.NET.

Si reinstala ASP.NET después de eliminar explícitamente la cuenta ASPNET, se crea una nueva cuenta ASPNET que tiene un nuevo identificador de seguridad (SID). Como resultado, cualquier ACL que hace referencia a la cuenta ASPNET anterior ya no se aplican a la nueva cuenta ASPNET.

Con Windows Server 2003

ASP.NET 1.1 se utiliza el <DriveName> \Documents and Settings\ <MachineName> carpeta \ASPNET para almacenar los archivos de proceso. Sin embargo, en IIS 6.0 y ASP.NET SP1, puede ver estos archivos en el <DriveName>: \Documents and Settings\Default User\Local Local\datos carpeta. Parece que la ruta de acceso es un cambio.

Nota <DriveName> es la unidad del equipo donde se instala ASP.NET. <MachineName> es el nombre del equipo.

El perfil de usuario predeterminado se utiliza en Windows Server 2003. En este caso, la identidad predeterminada es NetworkService. Puede configurar NetworkService en el nivel de grupo de aplicación. NetworkService tiene permisos que son similares a la ASPNET cuenta. Windows Server sólo utiliza el ASPNET cuenta para IIS 5.0 el modo de aislamiento. Si utiliza modo de aislamiento de procesos de trabajo, ASP.NET de todas las aplicaciones se ejecutan en un proceso de trabajo W3wp.exe de IIS.

Para obtener más información acerca de las listas de control de acceso predeterminada en Windows 2000, consulte el siguiente documento técnico de Microsoft: Para obtener más información, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base: