Identidad de proceso y solicitud en ASP.NET

Resumen

Este artículo describe los derechos de acceso que se conceden a la cuenta de proceso predeterminada de algunas situaciones en las 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 el código de aplicación Web 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) predeterminada. En las versiones beta de ASP.NET, la identidad del proceso es System, que es una cuenta administrativa eficaz que 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, lo que resulta adecuada para la mayoría de las aplicaciones Web.

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

Volver al principio

Más información

Configurar la identidad del proceso

Puede configurar la identidad del proceso en la sección < processModel > del archivo Machine.config del subdirectorio Config del directorio raíz de instalación. El nombre de usuario y los atributos de contraseña controlan la identidad del proceso. Los valores predeterminados para estos atributos son:
<processModel  userName="machine" password="AutoGenerate" />
La máquina y los valores AutoGenerate instruyen 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 de nombre de usuario al sistema, 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 la identidad del sistema. Cuando configure el proceso de trabajo ASP.NET para utilizar la identidad del sistema, el proceso de trabajo ASP.NET puede tener acceso a casi todos los recursos en el equipo local. En equipos que ejecutan Windows 2000, Windows XP o Microsoft Windows Server 2003, la cuenta del sistema también tiene credenciales de red y tener acceso a recursos de red como la cuenta de equipo. Para configurar el proceso para ejecutarse como la identidad sistema, cambie el atributo userName en la sección < processModel > como sigue:
<processModel  userName="SYSTEM" password="AutoGenerate" />
Volver al principio

Permisos predeterminados para la cuenta ASPNET

La cuenta ASPNET se crea como una cuenta local al instalar ASP.NET. La cuenta ASPNET pertenece sólo al grupo de usuarios en el 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 los recursos que el grupo usuarios tiene acceso a. La cuenta ASPNET hereda los siguientes derechos de usuario del grupo usuarios.
Derecho de usuarioExplicación
SeChangeNotifyPrivilegeOmitir comprobación de recorrido.
SeUndockPrivilegeQuitar el equipo de la estación de acoplamiento.
SeInteractiveLogonRightIniciar sesión localmente.
SeNetworkLogonRightTener acceso a este equipo desde la red.
Además de estos derechos, la cuenta ASPNET también predeterminada se concede los siguientes derechos:
Derecho de usuarioExplicación
SeServiceLogonRightInicie sesión como un servicio.
SeBatchLogonRightInicie sesión como un trabajo por lotes.
SeDenyInteractiveLogonRightDenegar inicio de sesión de forma local.
ASP.NET concede permisos específicos, acceso total para la cuenta ASPNET 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.

La lista siguiente describe el Access Control Lists (ACL) que son necesarios para la cuenta ASPNET. Las instalaciones predeterminadas de Windows 2000 y el de Microsoft.NET Framework incluyen estas ACL.
  • Ubicación: archivos temporales de %installroot%\ASP.NET
    Tipo de acceso: lectura y escritura en la carpeta y el Contenido de la carpeta de lista en la carpeta raíz de la unidad
    Cuenta: cuenta de proceso y configurado cuentas de suplantación
    Descripción: se trata de 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 independiente para cada aplicación. Puede utilizar el atributo tempDir de la sección < compilation > 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 de 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: esta es la ubicación en la que los servicios Web de lenguaje de marcado Extensible (XML, Extensible Markup Language) que utiliza para generar servidores proxy de serialización.
  • Ubicación: directorio de la aplicación
    Tipo de acceso: lectura
    Cuenta: cuenta de proceso y configurado cuentas de suplantación
    Descripción: esta es la ubicación para el contenido de la aplicación (acceso de sólo lectura necesaria).
    Para obtener más información, visite el siguiente sitio Web de Microsoft:
  • Ubicación: raíz del sitio Web (%systemdrive%\inetpub\wwwroot o la ruta de acceso que señala el sitio Web predeterminado)
    Tipo de acceso: lectura
    Cuenta: cuenta de proceso y configurado cuentas de suplantación
    Descripción: ASP.NET intenta leer archivos de configuración y supervisar los cambios en
    drive:\inetpub\wwwroot\web.config.
  • Ubicación: jerarquía % installroot %
    Tipo de acceso: lectura
    Cuenta: cuenta de proceso y configurado 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 % 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 equipos de forma predeterminada las ACL de Windows 2000, consulte la referencia de "Default Access Control Settings en Windows 2000" en la sección referencias .

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

Volver al principio

Acceso a los recursos

Las secciones siguientes describen cómo utilizar diversos recursos. Puede tener acceso muchos de estos recursos localmente si habilita la suplantación y conceder acceso a la cuenta suplantada al recurso. Sin embargo, a menudo la suplantación 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 sección de ejecución de código con una identidad fija .

Volver al principio

Uso de los 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 la escritura a los archivos, o puede conceder permisos de escritura para la cuenta ASPNET. Puede conceder permisos de escritura 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 Web de ASP.NET 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:

306158 cómo implementar la representación en una aplicación ASP.NET

Para cambiar la lista de Control de acceso de un archivo, siga estos pasos:
  1. Abra el Explorador de Windows.
  2. Seleccione el archivo o la carpeta que desea cambiar los permisos.
  3. En el menú Archivo, haga clic en Propiedades.
  4. Haga clic en la ficha seguridad , haga clic para seleccionar las casillas de verificación para los permisos de ACL.
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 la ACL de un archivo.

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

Volver al principio

Habilitación de la suplantación

Con la suplantación, ejecute 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 de la aplicación, agregue la siguiente directiva de configuración en la sección < system.web > de Machine.config o el archivo Web.config:
<identity impersonate="true"/>
Volver al principio

Utilizar bases de datos

Generalmente no afecta a las aplicaciones que utilizan la autenticación de SQL para conectarse a una base de datos por el modificador a la cuenta ASPNET. Esto también es cierto para las aplicaciones que utilizan la autenticación integrada y la suplantación. Sin embargo, si una aplicación no utiliza la suplantación y está utilizando la autenticación de Windows, debe conceder acceso a la base de datos para la cuenta ASPNET.

No puede utilizar la cuenta ASPNET cuando intenta autenticar a Microsoft SQL Server mediante la autenticación de Windows integrada sobre canalizaciones con nombre. Sin embargo, se puede utilizar la cuenta ASPNET correctamente con autenticación de Windows integrada sobre el transporte de protocolo de Control de transmisión (TCP).

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

Volver al principio

Mediante el registro de eventos

Aplicaciones que deben escribir en 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 eventos, la aplicación debe crear una clave del registro bajo el subárbol HKEY_LOCAL_MACHINE del registro, que no es la cuenta ASPNET.

Para crear la categoría en tiempo de ejecución, debe habilitar la suplantación y, a continuación, debe suplantar una cuenta que tenga derechos de acceso más. 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 eventos, 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.

Volver al principio

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 mediante las ventanas datos protección aplicación interfaces de programación (API).

Volver al principio

Mediante contadores de rendimiento

La cuenta ASPNET tiene permisos suficientes para escribir en (pero no para leer) los datos de contador de rendimiento. Si la aplicación debe leer los datos de contador de rendimiento o crear categorías de contadores de rendimiento, se requieren permisos de administrador o usuario avanzado.

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.

Todavía puede utilizar la herramienta Monitor de rendimiento (Perfmon.exe) para supervisar los contadores de rendimiento de ASP.NET cuando se utiliza la cuenta ASPNET.

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 de proceso de trabajo con los permisos siguientes:
    • Valor de consulta
    • Valor establecido
    • Crear subclave
    • Enumerar subclaves
    • Notificar a Control de lectura
En Windows Server 2003, agregue la identidad al grupo IIS_WPG.

Volver al principio

A partir de servidores COM fuera de proceso

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

Volver al principio

Depuración de problemas

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

Volver al principio

Ejecución de 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 servicios COM +. Puede ajustar la funcionalidad privilegiada en una clase que se deriva de
ServicedComponent y vuelva a ejecutar esta clase como una aplicación de servidor COM + con una identidad configurada.

Volver al principio

Compila archivos de código subyacente en recursos compartidos UNC

En ASP.NET, puede utilizar varios métodos para desarrollar archivos de la 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 Microsoft 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 HTML en un archivo ASP.NET y, a continuación, puede compilar dinámicamente cualquier código fuente asociado para ese archivo utilizando un atributo src en la directiva < % @ Assembly % > .
Nota: Si el contenido de la aplicación se encuentra en un recurso compartido de red, el compilador se inicia 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 que apunte a un archivo. Debe utilizar uno de los otros métodos en su lugar.

Volver al principio

Uso de ASP.NET en un principal o un controlador de dominio de reserva


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


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

CORREGIR 315158 : ASP.NET no funciona con la cuenta ASPNET predeterminada en un controlador de dominio

Leer la metabase de IIS

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

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

Volver al principio

Uso de System.Management y WMI

Windows Management Instrumentation (WMI) es una funcionalidad poderosa administrativa que puede utilizar para administrar y supervisar equipos basados en Windows. Sin embargo, cuando las aplicaciones de ASP.NET se ejecutan bajo la cuenta ASPNET, esta cuenta sólo tiene los mismos permisos de acceso predeterminados como todo el mundo. Estos permisos incluyen leer datos WMI, escribir datos de los proveedores y ejecutar métodos para proveedores en el equipo local. Para obtener más información acerca de los mecanismos de seguridad WMI se puede encontrar en la documentación de WMI Platform SDK o en MSDN.

Nota: En Windows 2000 sin service pack 3 (SP3) o posterior, o en Windows XP sin el service pack 1 (SP1) o posterior, las aplicaciones Web de ASP.NET que se ejecutan bajo la cuenta ASPNET no funcionen y puede recibir un mensaje de error "Acceso denegado (0x80041003)". Esto ocurre porque la cuenta no tiene privilegios suficientes 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 solucionar el problema, siga estos pasos:
  1. Abra el complemento Microsoft Management Console (MMC) de administración de equipo.
  2. Expanda servicios y aplicacionesy, a continuación, seleccione Control de WMI.
  3. (Ratón) en Control WMIy, a continuación, haga clic en Propiedades.
  4. En el cuadro de diálogo Propiedades de Control WMI , haga clic en la ficha seguridad .
  5. Expanda raíz, seleccione CIMV2y, 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\ASPNETy, 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 están seleccionadas las casillas de verificación permiten a ' Habilitar cuenta ' y ' Habilitar remoto ' .
  10. Haga clic en Aceptar en cada cuadro de diálogo hasta que vuelva al cuadro de diálogo Propiedades de Control WMI .
  11. Repita los pasos del 5 al 10 para otros espacios de nombres WMI que tendrán acceso la aplicación.
  12. Reinicie 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 la cuenta ASPNET no está compartida entre equipos o restablecer en un valor distinto del predeterminado.

Volver al principio

Interactuar con el escritorio

Cuando Servicios 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 a que el 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 tenga permiso para tener acceso a estos objetos.

Volver al principio

Eliminación de ASP.NET

Quitar ASP.NET, la cuenta ASPNET se deshabilita y permanece en el sistema. Puede eliminar la cuenta ASPNET si no piensa volver a instalar ASP.NET.

Si vuelve a instalar ASP.NET después de eliminar la cuenta ASPNET explícitamente, 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 aplica a la nueva cuenta ASPNET.

Volver al principio

Uso de Windows Server 2003

ASP.NET 1.1 utiliza el < DriveName >\Documents y configuración\< nombreEquipo >\ASPNET carpeta 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 carpeta Settings\Default User\Local Settings\Application Data. La ruta de acceso parece ser un cambio.

Nota: < DriveName > es la unidad en el equipo donde está instalado ASP.NET. < nombreEquipo > es el nombre del equipo.

Se utiliza el perfil de usuario predeterminado 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 cuenta ASPNET. Windows Server sólo utiliza la cuenta ASPNET para el modo de aislamiento de IIS 5.0. Si utiliza el modo de aislamiento de procesos de trabajo, todas las aplicaciones ASP.NET se ejecutan en un proceso de trabajo W3wp.exe IIS.

Volver al principio

Referencias

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

329290 cómo emplear la utilidad ASP.NET para cifrar credenciales y cadenas de conexión de estado de sesión

CORREGIR 315158 : ASP.NET no funciona con la cuenta ASPNET predeterminada en un controlador de dominio

Volver al principio
Propiedades

Id. de artículo: 317012 - Última revisión: 17 ene. 2017 - Revisión: 1

Comentarios