Utilizar la cuenta de servicio de red para obtener acceso a los recursos de ASP.NET

Agosto de 2005

Publicado: 21 de Diciembre de 2005

patterns & practices Developer Center (en inglés)

J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Andy Wigley
Microsoft Corporation

Este artículo se aplica a:
ASP.NET versión 1.1
ASP.NET versión 2.0
Windows Server 2003

Resumen: En este artículo se describe cómo se utiliza la cuenta de equipo NT AUTHORITY\Servicio de red para obtener acceso a los recursos locales y de red. De forma predeterminada, en Windows Server 2003, las aplicaciones ASP.NET se ejecutan con la identidad de esta cuenta. Es una cuenta con menos privilegios y con derechos de usuario y permisos limitados. Sin embargo, tiene credenciales de red, lo que significa que se puede utilizar para realizar autenticación con los recursos de red de un dominio. En este documento se describe cómo se utiliza la cuenta Servicio de red para obtener acceso a los recursos del servidor, como el registro de sucesos de Windows, el Registro de Windows, el sistema de archivos y las bases de datos locales y remotas de SQL Server.

En esta página

Objetivos Objetivos
Descripción general Descripción general
Acceso al registro de sucesos Acceso al registro de sucesos
Acceso al Registro Acceso al Registro
Acceso a archivos Acceso a archivos
SQL Server SQL Server
Comentarios Comentarios
Soporte técnico Soporte técnico
Comunidad y grupos de noticias Comunidad y grupos de noticias
Colaboradores y revisores Colaboradores y revisores

Objetivos

  • Aprender las limitaciones que impone el uso de la cuenta Servicio de red para obtener acceso a los recursos.

  • Utilizar la cuenta Servicio de red para obtener acceso a los siguientes tipos de recursos:

    • Registro de sucesos de Windows

    • Registro de Windows

    • Sistema de archivos local

    • Bases de datos locales y remotas

Descripción general

De forma predeterminada, Servicios de Microsoft Internet Information Server (IIS) 6.0 en Windows Server 2003 ejecuta aplicaciones ASP.NET en agrupaciones de aplicaciones que utilizan la identidad de la cuenta NT AUTHORITY\Servicio de red. Esta cuenta de equipo tiene menos privilegios y permisos limitados. Las aplicaciones que se ejecuten con esta cuenta tienen limitado el acceso al registro de sucesos, al Registro y al sistema de archivos. La cuenta tiene credenciales de red, lo que significa que se puede utilizar para obtener acceso a recursos de la red y a bases de datos remotas mediante la autenticación de Windows. Los recursos de red deben estar en el mismo dominio que el servidor Web o en un dominio de confianza.

En algunos escenarios, el uso de una cuenta de servicio de dominio es más aconsejable que el de la cuenta Servicio de red. Las cuentas personalizadas de servicio de dominio se deben utilizar si:

  • Se desea aislar varias aplicaciones de un único servidor entre ellas.

  • Se necesitan distintos controles de acceso para cada aplicación de los recursos locales y remotos. Por ejemplo, otras aplicaciones no pueden obtener acceso a las bases de datos de una aplicación si dicho acceso está limitado a la cuenta de la aplicación.

  • Se desea utilizar la auditoría de Windows para hacer un seguimiento de la actividad de cada aplicación por separado.

  • Desea evitar que los cambios accidentales o deliberados que se realicen en los controles de acceso o en los permisos asociados con la cuenta Servicio de red de carácter de red afecten a la aplicación.

En este documento se muestra cómo se puede utilizar la cuenta Servicio de red para obtener acceso a una variedad de tipos de recursos incluyendo el registro de sucesos, el Registro, el sistema de archivos y bases de datos.

Acceso al registro de sucesos

Las aplicaciones que se ejecutan con la identidad de Servicio de red pueden escribir en el registro de sucesos utilizando los orígenes de sucesos existentes, pero no pueden crear orígenes de sucesos nuevos, ya que los permisos del Registro son insuficientes. Cuando se utiliza el método EventLog.Write, si el origen del suceso especificado no existe, este método intenta crearlo. A menos que haya definido los permisos apropiados en el Registro, se genera una excepción de seguridad.

Nota

Es útil usar orígenes de sucesos específicos de la aplicación, con el fin de que los sucesos de su aplicación se puedan diferenciar fácilmente de los de otras aplicaciones.

Para habilitar su aplicación ASP.NET para que escriba en el registro de sucesos con un origen de sucesos que no exista, dispone de dos opciones:

  • Crear orígenes de sucesos nuevos en tiempo de instalación de la aplicación

  • Conceder acceso de escritura a las entradas del registro de sucesos del Registro

Creación de un origen de sucesos nuevo en tiempo de instalación

Con esta opción se crea una clase del instalador especializada que se ejecuta mediante la utilidad de instalación para crear un origen de sucesos nuevo en tiempo de instalación. La utilidad de instalación debe ejecutarse con una cuenta de administrador para que pueda disponer del permiso para crear el origen de sucesos nuevo.

Para crear una clase del instalador que cree orígenes de sucesos

  1. Utilice Visual Studio .NET 2005 para crear un proyecto de biblioteca de clases llamado InstallerClass.dll. Agregue una referencia de System.Configuration.Install al proyecto InstallerClass

  2. Asigne a la clase el nombre CustomEventLogInstaller y derívela de System.Configuration.Install.Installer.

  3. Establezca el atributo RunInstaller de la clase como true.

  4. Cree una instancia de System.Diagnostics.EventLogInstaller por cada registro de suceso nuevo que necesite la aplicación y llame a Installers.Add para agregar dicha instancia a la clase del instalador del proyecto. La clase de ejemplo siguiente agrega un origen de sucesos nuevo llamado customLog al registro de eventos de la aplicación.

    using System;
    using System.Configuration.Install;
    using System.Diagnostics;
    using System.ComponentModel;
      
    [RunInstaller(true)]
    public class CustomEventLogInstaller: Installer
    {
         private EventLogInstaller customEventLogInstaller;
          public CustomEventLogInstaller() 
         {
               // Create an instance of 'EventLogInstaller'.
               customEventLogInstaller = new EventLogInstaller();
               // Set the 'Source' of the event log, to be created.
               customEventLogInstaller.Source = "customLog";
               // Set the 'Event Log' that the source is created in.
               customEventLogInstaller.Log = "Application";
               // Add myEventLogInstaller to 'InstallerCollection'.
               Installers.Add(customEventLogInstaller);     
         }
         public static void Main()
         {
         }
    }
    
  5. Compile el código de la biblioteca InstallerClass.dll.

  6. Utilice una cuenta con derechos administrativos para ejecutar la utilidad InstallUtil.exe y escriba el nombre de la DLL en la línea de comandos. Por ejemplo, abra el símbolo del sistema de Visual Studio y escriba el comando siguiente.

    InstallUtil.exe <dll path>\InstallerClass.dll
    

Cuando la utilidad de instalación se llama mediante la clase del instalador, examina RunInstallerAttribute. Si su valor es true, la utilidad instala todos los elementos de la colección Installers. De esta forma se crean en la aplicación ASP.NET los orígenes de sucesos especificados.

Concesión de acceso de escritura

Para crear orígenes de sucesos nuevos en tiempo de ejecución, el método EventLog.WriteEntry tiene que crear una entrada nueva debajo de la siguiente clave de Registro. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\

Para permitir a la cuenta Servicio de red escribir en esta clave de Registro

  1. Inicie la herramienta Editor del Registro, Regedit.exe.

  2. Expanda la lista del panel izquierdo hasta encontrar el icono de la carpeta EventLog en la ruta de acceso anterior.

  3. Haga clic con el botón secundario del mouse (ratón) y, a continuación, haga clic en Permisos.

  4. En el cuadro de diálogo Permission for Eventlog (Permiso para Eventlog), haga clic en Agregar.

  5. En el cuadro de diálogo Seleccionar usuarios, equipos o grupos, escriba SERVICIO DE RED en el cuadro de texto y haga clic en Comprobar nombres. El nombre Servicio de red se subrayará, lo que indica que es un principal de seguridad válido. Haga clic en Aceptar.

  6. En el cuadro de diálogo Permissions for Eventlog (Permisos de Eventlog), haga clic en el nombre de usuario Servicio de red en la lista y en la sección Permissions for NETWORK SERVICE (Permisos de SERVICIO DE RED), active la casilla de verificación Control completo de la columna Permitir. Haga clic en Aplicar y, a continuación, en Aceptar

La cuenta Servicio de red ya tiene permiso para crear un origen de sucesos nuevo en el Registro.

Nota

Debe tener cuidado al editar el Registro, ya que cualquier error puede provocar inestabilidad en el sistema. El método recomendado es no editar el Registro directamente, sino utilizar una técnica alternativa como la creación de orígenes de sucesos nuevos en tiempo de instalación

Supervisión del mantenimiento

La supervisión del mantenimiento en la versión 2.0 de ASP.NET escribe en el registro de sucesos de aplicación de Windows para notificar de los eventos importantes de duración y de seguridad, siempre que esté configurada para hacerlo. Con la supervisión del mantenimiento de ASP.NET es posible hacer que los eventos personalizados del código escriban en el registro de sucesos. Este método no utiliza EventLog.WriteEntry, pero tiene la limitación de que hay que utilizar un origen de sucesos predefinido. Para obtener más información acerca de la supervisión del mantenimiento, consulte How To: Use Health Monitoring in ASP.NET 2.0 (en inglés).

Acceso al Registro

La cuenta Servicio de red no tiene acceso de escritura al Registro. Si una aplicación necesita escribir en el Registro, hay que configurar las listas de control de acceso (ACL) necesarias en las claves de Registro requeridas.

Concesión de acceso al Registro a Servicio de red

En el ejemplo siguiente, una aplicación tiene que cambiar y mostrar el nombre del servidor de hora de Internet con el que Windows se sincroniza automáticamente. Cualquier operador puede cambiar esta configuración con la ficha Hora de Internet del elemento Fecha y hora del Panel de control.

La aplicación tiene que modificar la clave de Registro siguiente:HKLM\SOFTWARE\ Microsoft\Windows\CurrentVersion\DateTime\Servers

Para permitir a la cuenta Servicio de red acceso de escritura en esta clave de Registro

Para realizar los pasos siguientes, es necesario utilizar una cuenta de administrador con permiso para modificar la seguridad del Registro

  1. En la barra de tareas, haga clic en Inicio y, a continuación, en Ejecutar. Escriba regedit en el cuadro Abrir y haga clic en Aceptar.

  2. Expanda la lista del panel izquierdo hasta encontrar el icono de la carpeta DateTime en la ruta de acceso anterior.

  3. Haga clic con el botón secundario del mouse y, a continuación, haga clic en Permisos.

  4. En el cuadro de diálogo Permission for Servers (Permiso de servidores), haga clic en el botón Agregar

  5. En el cuadro de diálogo Seleccionar usuarios, equipos o grupos, escriba SERVICIO DE RED en el cuadro de texto y haga clic en Comprobar nombres. El nombre Servicio de red se subrayará, lo que indica que es un principal de seguridad válido. Haga clic en Aceptar

  6. En el cuadro de diálogo Permissions for Servers (Permisos de servidores), haga clic en el nombre de usuario Servicio de red en la lista y en la sección Permissions for NETWORK SERVICE (Permisos de SERVICIO DE RED), haga clic en Opciones avanzadas

  7. En el cuadro de diálogo Configuración de seguridad avanzada para servidores, haga clic en Servicio de red y, a continuación, en Editar

  8. En el cuadro de diálogo Permission Entry for Servers (Entrada de permiso para servidores), active las casillas de verificación Establecer valor y Crear subclave de la columna Permitir para permitir el acceso de escritura. Haga clic en Aceptar varias veces hasta que se cierre el cuadro de diálogo Permisos

Nota

Debe tener cuidado al editar el Registro, ya que cualquier error puede provocar inestabilidad en el sistema.

La aplicación ASP.NET ya puede utilizar código similar al del ejemplo siguiente para modificar y mostrar el nombre del servidor de hora de Internet

using Microsoft.Win32;
...
protected void Button1_Click(object sender, EventArgs e)
{
  //change the time server
  RegistryKey rk = Registry.LocalMachine.OpenSubKey(
              @"SOFTWARE\Microsoft\Windows\CurrentVersion\DateTime\Servers", 
              true); //writable - this will fail without proper access
  string sDefault = (String)rk.GetValue(");
  int iDefault = Convert.ToInt32(sDefault);
  //this an array of all the server names
  string[] sServers = rk.GetValueNames(); //requires enumerate sub keys
  iDefault++;
  if (iDefault >= sServers.Length) 
      iDefault=1;
  rk.SetValue(", iDefault.ToString());
  // update display
  Response.write(rk.GetValue(sServers[iDefault]).ToString());
 }

Acceso a archivos

De forma predeterminada, la cuenta Servicio de red tiene permisos de lectura y ejecución en la carpeta raíz del servidor IIS, denominada Wwwroot, lo que significa que la aplicación ASP.NET implementada en la carpeta raíz ya tiene permisos de lectura y ejecución en sus carpetas de aplicaciones. Sin embargo, si la aplicación ASP.NET necesita utilizar archivos o carpetas de otras ubicaciones, debe habilitar específicamente el acceso

Concesión de acceso a los archivos a Servicio de red

Para proporcionar acceso a una aplicación ASP.NET que se ejecute como Servicio de red, debe conceder acceso a la cuenta Servicio de red.

Para conceder permisos de lectura, escritura y modificación a un archivo concreto

  1. En el Explorador de Windows, busque y seleccione el archivo requerido.

  2. Haga clic con el botón secundario del mouse y, a continuación, haga clic en Propiedades.

  3. En el cuadro de diálogo Propiedades, haga clic en la ficha Seguridad.

  4. En la ficha Seguridad, examine la lista de usuarios. Si la cuenta Servicio de red no aparece en dicha lista, agréguela.

  5. En el cuadro de diálogo Propiedades, haga clic en el nombre de usuario Servicio de red y en la sección Permissions for NETWORK SERVICE (Permisos de SERVICIO DE RED), seleccione los permisos Lectura, Escritura y Modificación.

  6. Haga clic en Aplicar y, a continuación, en Aceptar.

La aplicación ASP.NET ya puede escribir en el archivo especificado.

Nota

Si necesita permitir el mismo nivel de acceso a un recurso en todas las cuentas que ejecutan aplicaciones ASP.NET (Servicio de red o una cuenta de servicio personalizada), puede conceder acceso al grupo IIS_WPG, en lugar de concedérselo específicamente a la cuenta Servicio de red. Todas las cuentas que se utilicen para ejecutar ASP.NET son obligatorias para ser miembro del grupo IIS_WPG.

Para obtener más información acerca de cómo crear una cuenta personalizada para ejecutar una aplicación ASP.NET, consulte How To: Create a Service Account for an ASP.NET 2.0 Application (en inglés).

SQL Server

Las aplicaciones ASP.NET deben utilizar la autenticación de Windows para conectarse a cualquier base de datos. Mediante el uso de la autenticación de Windows se evita tanto el almacenamiento de credenciales de la base de datos en las cadenas de conexión como el paso de contraseñas al servidor de bases de datos a través de la red.

Con la autenticación de Windows, la cuenta de proceso de la aplicación se utiliza de forma predeterminada para la autenticación. Para poder tener acceso a una base de datos, la cuenta requiere:

  • Un inicio de sesión de SQL Server en el servidor de bases de datos.

  • Permisos en los objetos requeridos (por ejemplos, procedimientos almacenados, vistas o tablas) en la base de datos requerida.

Concesión de acceso a un servidor SQL Server local

Cuando el servidor SQL Server está en el servidor Web, hay que crear un inicio de sesión de base de datos para la cuenta NT AUTHORITY\Servicio de red.

Para obtener acceso a una base de datos del servidor SQL Server local con Servicio de red

  1. Inicie el Administrador corporativo de SQL Server.

  2. Expanda las carpetas del panel izquierdo y busque la carpeta Seguridad del servidor SQL Server local

  3. Haga clic con el botón secundario en Inicios de sesión en la carpeta Seguridad y, a continuación, haga clic en Nuevo inicio de sesión

  4. En el cuadro de diálogo Propiedades de inicio de sesión - Nuevo inicio de sesión, en el cuadro Nombre, escriba NT AUTHORITY\SERVICIO DE RED. Acepte los valores predeterminados de los parámetros restantes y haga clic en Aceptar.

  5. Expanda las carpetas de bases de datos y, a continuación, la base de datos Pubs (o una equivalente).

  6. Haga clic con el botón secundario en Usuarios y, a continuación, haga clic en Nuevo usuario de base de datos.

  7. Haga clic con el botón secundario en Usuarios y, a continuación, haga clic en Nuevo usuario de base de datos.

  8. En el cuadro de diálogo Propiedades del usuario de la base de datos - Nuevo usuario, seleccione la cuenta NT  AUTHORITY\SERVICIO DE RED.

  9. En la lista Permitir en la función de base de datos, active la casilla de verificación db_datareader

  10. Haga clic en Aceptar y cierre el Administrador corporativo de SQL Server.

La cuenta Servicio de red ya tiene permiso para leer los datos de las tablas de la base de datos designada.

En la práctica, los requisitos de una aplicación pueden ser más complejos. Por ejemplo, es posible que desee permitir el acceso de lectura a ciertas tablas y el acceso de actualización a otras. El enfoque recomendado para ayudar a mitigar el riesgo que plantea la inyección SQL es conceder permisos de ejecución a la cuenta Servicio de red en un conjunto seleccionado de procedimientos almacenados y no proporcionar acceso directo a las tablas.

Concesión de acceso a un servidor SQL Server remoto

Si va a obtener acceso a una base de datos que se encuentre en otro servidor del mismo dominio (o de un dominio de confianza), las credenciales de red de la cuenta Servicio de red se utilizan para realizar la autenticación en la base de datos. Las credenciales de la cuenta Servicio de red son de la forma NombreDeDominio \ ServidorAspNet $, donde NombreDeDominio es el dominio del servidor ASP.NET y ServidorAspNet es el nombre de su servidor Web.

Por ejemplo, si la aplicación ASP.NET se ejecuta en un servidor llamado SVR1 del dominio CONTOSO, el servidor SQL Server ve una solicitud de acceso a la base de datos de CONTOSO\SVR1$.

Para obtener acceso a un servidor SQL Server remoto con Servicio de red

Para conceder acceso a un servidor de bases de datos remoto en el mismo dominio o en un dominio de confianza, siga los pasos descritos anteriormente para las bases de datos locales, excepto en el paso 4, utilice la cuenta NombreDeDominio\ServidorAspNet$ para crear el inicio de sesión de la base de datos.

Nota

En los entornos de producción, la cuenta Servicio de red se debe colocar en un grupo de Windows y crear un inicio de sesión de SQL Server para el grupo de Windows.

Comentarios

Si desea enviar comentarios puede utilizar la wikipedia (en inglés) o el correo electrónico:

Nos interesan especialmente sus comentarios sobre los aspectos siguientes:

  • Problemas técnicos relacionados con nuestras recomendaciones

  • Problemas de aprovechamiento y utilidad

Soporte técnico

Los servicios de soporte de Microsoft ofrecen el soporte técnico de los productos y tecnologías de Microsoft a los que se hace referencia en esta guía. Para obtener información sobre soporte, visite el sitio Web de soporte de Microsoft en http://msdn.microsoft.com/security/default.aspx?pull=/isapi/gosupport.asp?Target=/.

Comunidad y grupos de noticias

El soporte técnico de la comunidad se ofrece en los foros y grupos de noticias:

Para sacar el mayor partido de estos foros, busque el grupo de noticias correspondiente a su tecnología o problema. Por ejemplo, si tiene un problema con las características de seguridad de ASP.NET, debería utilizar el foro de seguridad de ASP.NET (ASP.NET Security).

Colaboradores y revisores

  • Colaboradores y revisores externos: Andy Eunson; Chris Ullman, Content Master; David Raphael, Foundstone Professional Services, Rudolph Araujo, Foundstone Professional Services; Manoranjan M. Paul

  • Colaboradores y revisores de PSS y Microsoft Consulting Services: Wade Mascia, Tom Christian, Adam Semel, Nobuyuki Akama, Microsoft Corporation

  • Colaboradores y revisores de Microsoft Product Group: Stefan Schackow, Vikas Malhotra, Microsoft Corporation

  • Colaboradores y revisores de MSDN: Kent Sharkey, Microsoft Corporation

  • Colaboradores y revisores de Microsoft IT: Eric Rachner, Shawn Veney (ACE Team), Microsoft Corporation

  • Equipo de pruebas: Larry Brader, Microsoft Corporation; Nadupalli Venkata Surya Sateesh, Sivanthapatham Shanmugasundaram, Sameer Tarey, Infosys Technologies Ltd.

  • Equipo de edición: Nelly Delgado, Microsoft Corporation; Sharon Smith, Tina Burden McGrayne, Linda Werner & Associates Inc.

  • Dirección de publicación: Sanjeev Garg, Satyam Computer Services

Mostrar: