Mes: noviembre 2008

Nueva beta de RunASAdmin

La Beta de RunAsAdmin Explorer Shim V2 beta10 se ha liberado!

Una herramienta para usar cuentas sin privilegios y aplicarlos si se necesitan, o al revés, usar cuentas con privilegios y lanzar programas con cuentas sin ellos.

Monitorizar la fiabilidad de los servicios

Monitorizar la fiabilidad de los servicios nos ayudará en su seguimiento y en la medición del tiempo medio existente entre fallos. Este tiempo medio nos indica el tiempo de espera desde que falla un servicio hasta que vuelve a estar operativo. Conociéndolo, tal vez seamos capaces de impedir que ocurran problemas antes de producirse.  Por ejemplo, si sabemos que un servicio falla cada 10 días, más que esperar a que falle (momento que podría ser inconveniente para los usuarios) podemos programarlo para que se detenga y reinicie periódicamente; además podemos seguirlo para ver si la solución nos sirve (a veces hay que echar mano de lo que sea).

Este seguimiento también nos puede indicar el tiempo que tarda un servicio en recuperarse del fallo.

Los métodos para seguir la fiabilidad:

• Suscripción a sucesos. Podemos crear una suscripción a un suceso que notifique cada x tiempo si un servicio cambia de estado. Si además guarda la información en una BD o archivo que podamos contrastar, podremos realizar un cálculo del tiempo medio entre los fallos y el tiempo necesario para restaurar su funcionalidad completamente.
• Registro de sucesos (Event Log). En Windows Server 203 los cambios en el estado de un servicio se guardan en el Registro del Sistema (System Log visible con el Event viewer). Extrayendo periódicamente estos eventos, también podemos calcular la fiabilidad de nuestros servicios.

Si lo hacemos mediante script podemos usar: Shell script (EventQuery.vbs (es), EventTriggers.exe(es), WMI (Colecciones Win32_Service y Win32_NTLogEvent).

• Usando una suscripción de sucesos temporal o permanente.
• Usando el registro de sucesos.

Monitorizar los cambios en el estado de un servicio con una suscripción de suceso temporal

   1: 'Este script sirve para comprobar cambios de estado de los servicios

   2: ' usando una suscripción temporal a event log y volcado en un archivo de texto

   3:  

   4: '(c) Juansa 29-11-2008

   5:  

   6:  

   7:  

   8: Const ForReading = 1, ForWriting = 2

   9: Dim TabStop, NewLine

  10: TabStop = Chr(9)

  11: NewLine = Chr(10)

  12: Set objFSO = CreateObject("Scripting.FileSystemObject")

  13: Set objFile = objFSO.OpenTextFile("C:scriptsCambio_Servicios.txt", ForWriting, True)

  14:  

  15:  

  16: StrComputer = "."

  17: Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=Impersonate}!\" & strComputer & "rootcimv2")

  18: Set objwmiEventSource = objWMIService.ExecNotificationQuery ("SELECT * FROM __InstanceModificationEvent " & "WITHIN 3 WHERE TargetInstance  ISA 'Win32_Service'")

  19:  

  20:   Do

  21:     Set objService = objwmiEventSource.NextEvent

  22:       If objService.TargetInstance.State <> objService.PreviousInstance.State Then

  23:         objFile.WriteLine Date & TabStop & objService.TargetInstance.DisplayName & " está " & objService.TargetInstance.State & ". Anteriormente  estaba " & objService.PreviousInstance.State & "."

  24:       end if

  25:   Loop

  26:  

Este script se ejecuta de continuo, para detenerlo hay que abrir el Administrador de Tareas y matar el proceso wscript.exe que se crea al ejecutarlo.

Se ejecuta y no escribe nada en el archivo, pero yo hago una prueba manual: abro services.msc desde inicio->ejecutar y detengo el servicio (el que sea) Background Intelligent Transfer Service(BITS) y luego lo vuelvo a iniciar. Al echar un vistazo al archivo donde le he dicho que me guarde los cambios, veo:

¿Qué hace el script?

Su cuerpo, ya conocemos la creación y preparación del archivo donde guardará la info, Creamos la variable para el equipo local (StrComputer), Usamos GetObject y conectamos con el espacio de nombres rootcimv2 con nivel impersonate.

Usamos el método ExecNotificationQuery para registrar la notificación de cada vez que una instancia se modifica. Como sólo queremos los cambios en los servicios, usamos una cláusula WHERE para limitar la monitorización de los datos que nos devuelve la clase Win32_Service.

Creamos un bucle que ejecutará el script indefinidamente (podemos detenerlo como he indicado arriba, o con Taskkill.exe, Cerrando la sesión también se detiene).

Usamos el método NextEvent para recuperar el suceso cuando ocurre.

Así, cada vez que un servicio se modifica de alguna forma, el script comprueba el estado actual con el estado anterior, si no ha cambiado sigue a la espera, si es diferente lo graba en el archivo Cambios_servicios.txt.

Muchas de las operaciones que hace un equipo (especialmente un servidor) es ejecutar servicios. Esto hace que debamos ser cuidadosos con monitorizar los servicios que se ejecutan en los equipos de nuestra red. Una de las maneras más prácticas de monitorización es el uso de scripts.

Muchos de los servicios (DNS, DHCP,…) son críticos y un error en un único servidor puede tener un impacto en cientos, incluso miles, de usuarios, impidiéndoles iniciar sesión o acceder a los recursos de la red.

Como normas más generales de monitorización:

• Monitorizar la disponibilidad del servicio: Medir el porcentaje de tiempo que un servicio está disponible.

La definición exacta de disponibilidad depende de lo que se espera de cada servicio. Si un recurso debe estar disponible todos los días de 22:00 a 06:00 horas y éste fallase un domingo a las 8:00 de la mañana, no se consideraría fallo de disponibilidad.

• Monitorizar la fiabilidad del servicio: Medir la frecuencia de fallos de un servicio y el tiempo necesario para restaurarlo a su funcionalidad.

La fiabilidad se calcula mediante la división del tiempo que el servicio está en funcionamiento por el número total de días en un año. Por ejemplo,un servicio que ha sufrido paradas en 6 días durante un año tendría una fiabilidad de 98,3% ((359 días disponible)/365 días en un año)

• Monitorizar el rendimiento del servicio: Medir si el servicio cumple su tarea en la forma esperada.

Monitorizar la disponibilidad del servicio

Cuando monitorizamos la disponibilidad de un servicio, comprobamos sólo que el servicio se esté ejecutando. Si necesitamos saber si el servicio se ejecuta con máxima eficiencia, necesitamos usar otro tipo de monitorización (el rendimiento). Aunque relativamente es simple, la monitorización de disponibilidad es muy importante; otras cuestiones, como si el servicio se comporta en el nivel esperado, no tienen sentido si no se está ejecutando.

Esta monitorización comprende normalmente una prueba que nos devolverá el estado del servicio. Guardando el resultado de cada prueba en una BD podemos calcular la disponibilidad de un servicio. Si realizamos 100 pruebas y el servicio responde 97 veces, someramente, está disponible un 97%.

La disponibilidad frecuentemente se expresa con la media de tiempo que durante un año el servicio no ha estado disponible.

Para incrementar la disponibilidad de un servicio podemos intentar:

• Aumentar el tiempo medio entre fallos: Desafortunadamente, un fallo de servicio es causado frecuentemente por un error del propio servicio o del sistema operativo. A menos que seamos los autores del código, poco podremos cambiar para solucionar el error y así aumentar el tiempo entre fallos.
• Disminuir el tiempo necesario para reiniciar el servicio: Si hemos de reiniciar el servicio manualmente cada vez que falle, el servicio no será funcional a menos que lo reiniciemos. Para aumentar la disponibilidad, podemos escribir un script que compruebe su estado y reinicie, en su caso, el servicio automáticamente, periódicamente.

Podemos usar scripts de Shell (sc.exe y net.exe), WSH, WMI (Scriptomatic utility) y ADSI (ADSI Scriptomatic).

Informar sobre la disponibilidad de los servicios puede hacerse mediante:

• Informar sobre el estado del servicio.
• Informar de los servicios que se encuentran en un estado específico (e.g. en ejecución o detenidos)

Informar del estado de todos los servicios.

   1: 'Este script sirve para comprobar el estado de todos los servicios

   2: 'en un archivo de texto

   3:  

   4: '(c) Juansa 28-11-2008

   5:  

   6: Const ForReading = 1, ForWriting = 2

   7: Dim TabStop, NewLine

   8: TabStop = Chr(9)

   9: NewLine = Chr(10)

  10: Set objFSO = CreateObject("Scripting.FileSystemObject")

  11: Set objFile = objFSO.OpenTextFile("C:scriptsEstado_Servicios.txt", ForWriting, True)

  12:  

  13: StrComputer = "."

  14: Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=Impersonate}!\" & strComputer & "rootcimv2")

  15: Set colServices = objWMIService.ExecQuery("SELECT * FROM Win32_Service")

  16: For each objService in colServices

  17: 'escribimos el nombre y el estado del servicio

  18: objFile.WriteLine Date & TabStop & objService.DisplayName 

  19: objFile.WriteLine objService.State

  20:  

  21: Next

  22:  

  23: Wscript.Echo  "FINALIZADO"

El resultado:

* Podemos incluirlo en una tarea programada y realizar la comprobación diaria o a horas determinadas. Se puede incluir además de la fecha, la hora en la que se realiza la comprobación en el script.

1. Creamos una constante de lectura y escritura
2. creamos las variables de Tab y Nueva linea
3. Asignamos los valores de Tab y NewLine
4. Creamos el objeto del archivo
5. Abrimos el archivo, indicando su ruta y nombre, para escritura.
6. variable del equipo, el punto indica equipo local.
7. conectamos con el espacio de nombres WMI rootcimv2 con GetObject, estableciendo el nivel de impersonation en impersonate.
8. Usamos el método ExecQuery para conectar con la clase Win32_Service, lo que nos devolverá una colección que consiste en todos los servicios instalados en el equipo.
9. Para cada servicio devuelto en la colección, se escribe una nueva línea para la fecha actual y el nombre del servicio y una nueva línea para su estado, en el archivo abierto.
10. Lanzamos un mensaje al acabar. -Podemos eliminarlo si el script no requiere de nuestra presencia.

Informar sólo de aquéllos servicios que no están en ejecución

   1: 'Este script sirve para listar los servicios en estado detenido en un archivo de texto

   2:  

   3: '(c) Juansa 28-11-2008

   4:  

   5: Const ForReading = 1, ForWriting = 2

   6: Dim TabStop, NewLine

   7: TabStop = Chr(9)

   8: NewLine = Chr(10)

   9: Set objFSO = CreateObject("Scripting.FileSystemObject")

  10: Set objFile = objFSO.OpenTextFile("C:scriptsServicios_detenidos.txt", ForWriting, True)

  11:  

  12: StrComputer = "."

  13: Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=Impersonate}!\" & strComputer & "rootcimv2")

  14: Set colserviciosdetenidos = objWMIService.ExecQuery("SELECT DisplayName, State FROM Win32_Service WHERE State <> 'Running'")

  15: 'escribimos el título en el archivo

  16: objFile.WriteLine "LISTADO DE SERVICIOS QUE NO SE ESTÁN EJECUTANDO EN FECHA: " & Date

  17: objFile.WriteLine

  18: For each objService in colserviciosdetenidos

  19: 'escribimos el nombre y el estado del servicio

  20: objFile.WriteLine objService.DisplayName & ": " & objService.State

  21:  

  22: Next

  23:  

  24: Wscript.Echo  "FINALIZADO"

* El cambio es evidente, hemos modificado la consulta (SELECT) para que sólo devuelva los servicios que no tengan un estado Running.

Crear una tarea en Windows para que se ejecute el script diariamente

1. Desde Inicio, todos los programas, accesorios, herramientas del sistema, programador de tareas.
   
2. Desde la ventana del programador, doble clic en Agregar tarea programada y seguiremos el asistente, primer paso, pulsar siguiente.
   
3. Siguiente ventana, pulsaremos en Examinar para ir donde tenemos nuestro script, lo elegiremos y pulsaremos en Abrir del correspondiente cuadro de diálogo.
   
4. Elegimos un nombre descriptivo para la tarea, y marcamos la secuencia deseada, en este caso diariamente.
   
5. Hora de inicio, frecuencia de días y día de inicio, siguiente.
   
6. Datos de la cuenta con la que se ejecutará la tarea. Ojo, si la cuenta no tiene suficientes privilegios no ejecutará la tarea o incluso el script.
   
7. Si deseamos configurar alguna opción avanzada o sólo comprobarlas, marcaremos la casilla de verificación y pulsamos en Finalizar.
   
8. Avanzadas, ventanas Tarea, Programación, Configuración y Seguridad.
   
9. La tarea se ha añadido al programador de tareas.
   

Para facilitar la implantación y administración de configuración de seguridad en la red de la organización, Windows Server 2003 incluye el complemento de Plantillas de seguridad. Este complemento permite a los administradores definir plantillas estándar y aplicarlas uniformemente a múltiple equipos o usuarios.

Una plantilla de seguridad es una representación física de una configuración de seguridad, un archivo en el que un grupo de valores de seguridad pueden almacenarse. Windows Server 2003 incluye un conjunto de plantillas estándar, cada una apropiada para la función de un equipo. El rango de plantillas va desde una configuración de baja seguridad para clientes de dominio hasta alta seguridad para controladores de dominio. Podemos usar estas plantillas como están o modificarlas, o usarlas como base de plantillas para crearlas nosotros.

La herramienta de análisis y configuración de seguridad es el compañero del complemento de Plantillas de Seguridad. Se usa para aplicar las restricciones definidas en una plantilla a los sistemas reales. También para analizar la seguridad de un sistema y compararlo con la configuración de equipos que han sido desplegados para asegurarnos que cumple con los estándares de la compañía.

1. Desde el botón Inicio, seleccionamos Ejecutar, escribimos mmc y pulsamos ENTER
   
2. Aparece Microsoft Management Console, Pulsamos en Menú Console y luego en Add/Remove snap-in, en la ventana siguiente en el botón Add.
   
3. Nos deslizamos por los complementos hasta Configuración y Análisis de Seguridad, lo seleccionamos y pulsamos Add. Cerramos y Aceptar.
   
4. Clic derecho en el complemento que ahora se muestra en la Consola, seleccionamos Abrir Base de Datos.
   
5. Escribimos un nombre distintivo y pulsamos en Abrir.
   
6. Escogeremos una de las plantillas de seguridad predefinidas o una que hayamos creado nosotros.
   
7. Elegimos la adecuada a la configuración de seguridad que queremos analizar y pulsamos en Abrir.
   
8. Clic derecho sobre el complemento otra vea, ahora seleccionamos Analizar equipo ahora , indicamos la ruta para guardar el log con la info y se comenzará la comparación de la configuración actual con la de la plantilla elegida.
   
9. Cuando finaliza la comparación, vemos en las opciones de seguridad la información.
   
10. Un dato que no cumpla se mostrará con una Aspa roja.
    

Las plantillas predefinidas en Windows Server 2003 (Fuente KnowledgeBase de Microsoft):

• compatws.inf Esta plantilla cambia los permisos predeterminados de archivos y del Registro que se conceden a los miembros del grupo Usuarios de manera que sean coherentes con los requisitos de la mayoría de los programas que no pertenecen al programa de logotipo de Windows para software (Windows Logo Program for Software). La plantilla Compatible también quita todos los miembros del grupo Usuarios avanzados.

• DC security.inf Esta plantilla se crea cuando se promueve un servidor a controlador de dominio. Refleja la configuración de seguridad predeterminada de los archivos, el Registro y los servicios del sistema. Si vuelve a aplicar esta plantilla, esta configuración se establecerá en los valores predeterminados. Sin embargo, la plantilla puede sobrescribir los permisos de los nuevos archivos, claves del Registro y servicios del sistema creados por otros programas.

• hisecdc.inf
• hisecws.inf

Las plantillas Highly Secure especifican restricciones adicionales no definidas por las plantillas Secure, como niveles de cifrado y la firma necesarios para la autenticación y el intercambio de datos a través de canales seguros, y entre los clientes y servidores de Bloque de mensajes del servidor (SMB).

• iesacls.inf

Internet Explorer Security ACLs

•  rootsec.inf Esta plantilla especifica los permisos raíz. De forma predeterminada, Rootsec.inf define estos permisos para la raíz de la unidad del sistema. Puede utilizar esta plantilla para volver a aplicar los permisos del directorio raíz si se cambian inadvertidamente o puede modificar la plantilla para aplicar los mismos permisos raíz a otros volúmenes. Como se especifica, la plantilla no sobrescribe los permisos explícitos definidos en los objetos secundarios; sólo propaga los permisos heredados por los objetos secundarios.

• securedc.inf
• securews.inf

  Las plantillas Secure definen configuraciones de seguridad mejorada que es menos probable que afecten a la compatibilidad de programas. Por ejemplo, las plantillas Secure definen configuraciones más seguras de contraseñas, bloqueo y auditoría. Además, las plantillas limitan el uso de LAN Manager y los protocolos de autenticación NTLM configurando los clientes para enviar únicamente respuestas de NTLMv2 y configurando los servidores para que rechacen las respuestas de LAN Manager.

  Hay dos plantillas Secure predefinidas en Windows Server 2003: Securews.inf para las estaciones de trabajo y Securedc.inf para los controladores de dominio. Para obtener información adicional acerca de cómo utilizar estas plantillas y otras plantillas de seguridad, busque «plantillas de seguridad predefinidas» en el Centro de ayuda y soporte técnico.

• setup security.inf

  La plantilla Setup security.inf se crea durante la instalación y es específica de cada equipo. Varía de un equipo a otro, dependiendo de si se trata de una instalación limpia o de una actualización. Setup security.inf representa la configuración de seguridad predeterminada que se aplica durante la instalación del sistema operativo, incluyendo los permisos de archivo para la raíz de la unidad del sistema. Puede utilizarse en servidores y en equipos cliente; no puede aplicarse a controladores de dominio. Puede aplicar partes de esta plantilla para la recuperación tras desastres.

  No aplique Setup security.inf utilizando Directiva de grupo. Si lo hace, puede disminuir el rendimiento.

Aplicar una plantilla de seguridad

1. clic derecho en Configuración y análisis de seguridad y, a continuación, clic en Abrir base de datos.
2. En el cuadro Nombre de archivo, escribir el nombre de la base de datos y clic en Abrir.
3. clic en la plantilla de seguridad que deseamos aplicar y, seguidamente, clic en Abrir para importar a la base de datos las entradas contenidas en la plantilla.
4. clic derecho en Configuración y análisis de seguridad y, después, clic en Configurar el equipo ahora.

En el procedimiento descrito para añadir el complemento de Configuración y análisis de seguridad, nos sirve para añadir también las plantillas de seguridad, en el paso 3 buscamos el complemento y lo agregamos de igual modo que lo hemos hecho con Configuración y análisis de seguridad. Así en la misma consola podemos tener ambos complementos.

Crear y definir una plantilla de seguridad nueva

1. En la consola, extendemos Plantillas de seguridad.

2. clic derecho en %raíz_del_sistema%SecurityTemplates y después, clic en Nueva plantilla.

3. En el cuadro Nombre, escribimos uno para la plantilla nueva.
clic en Aceptar.
La plantilla de seguridad aparece en la lista de plantillas de seguridad. Ver que aún no se define la configuración de seguridad para esta plantilla. Cuando extendemos la plantilla se extienden además cada componente de la misma y seguidamente, doble clic en cada valor que muestre el estado No Definido en la columna Configuración del equipo.

4. Para directivas de Directivas de cuenta, Directivas locales o registro de sucesos:

a. Extendemos el componente que contiene la configuración de seguridad que queremos configurar.

b. A la derecha, doble clic en la configuración de seguridad a configurar.

c. clic para seleccionar la casilla de verificación Definir esta configuración de directiva en la plantilla, especificamos la opción o configuración que creeemos que es la apropiada en la configuración de seguridad y después, clic en Aceptar.

5. Para definir una directiva Grupos restringidos:

. clic derecho en Grupos restringidos y seguidamente, clic en Agregar grupo.

a. clic en Examinar.

b. En el cuadro de diálogo Seleccionar grupos, escribimos el nombre del grupo al que queremos restringir el acceso, clic en Aceptar y después, clic en Aceptar.

c. En el cuadro de diálogo Propiedades Nombre de Grupo bajo miembros de este grupo, clic en Agregar miembros para agregar los miembros que queramos al grupo.
Para agregar este grupo como miembro de otro grupo, en Este grupo es miembro de, clic en Agregar grupos.

d. clic en Aceptar.

6. Para definir directiva de Servicios del sistema:

. Extendemos Servicios del sistema.

a. A la derecha, doble clic en el servicio a configurar.

b. Especificamos las opciones que queremos y seguidamente, clic en Aceptar.

7. Para definir seguridad para claves de Registro:

. clic derecho en Registro y después, clic en Agregar clave.

a. En el cuadro de diálogo Seleccionar clave de registro, clic en la clave de Registro a la que queremos definir seguridad y después, clic en Aceptar.

b. En el cuadro de diálogo Seguridad de base de datos para Clave Seleccionada especificamos los permisos para la clave de Registro y después, clic en Aceptar.

c. En el cuadro de diálogo Agregar objeto, especificamos cómo queremos los permisos para esta clave heredada, clic en Aceptar y después, clic en Aceptar.

8. Para definir seguridad para archivos o carpetas:

. clic derecho Sistema de archivos y después, clic en Agregar archivo.

a. En el cuadro de diálogo Agregar archivo o carpeta, clic en una carpeta o en un archivo al que queremos agregar seguridad y después, clic en Aceptar.

b. En el cuadro de diálogo Seguridad de base de datos para Nombre archivo o Nombre carpeta especificamos los permisos que queremos, clic en Aceptar y después, clic en Aceptar.

Copiar configuración de seguridad de una plantilla predefinida en otra plantilla

1. Extendemos una plantilla predefinida que contenga las configuraciones que queremos copiar, clic derecho en el componente a copiar y después, clic en Copiar.

2. Extendemos la plantilla personalizada, clic derecho en el componente apropiado y luego, clic en Pegar.

Cree una plantilla nueva de seguridad basada en una plantilla predefinida

1. clic derecho en la plantilla a copiar y seguidamente, clic en Guardar como.

2. En Guardar como, escribimos un nombre y después, clic en Guardar.
La plantilla de seguridad nueva aparece en la lista de plantilla de seguridad. Configurar la plantilla con las configuraciones deseadas.

Cada servicio dispone de permisos especiales que podemos asignar o denegar a cada usuario o grupo. Podemos establecer permisos para servicios individuales con sc.exe, directivas, o plantillas de seguridad. Podemos establecer permisos para grupos mediante el complemento de consola Usuarios y Equipos de Active Directory.

Los servicios deben iniciar sesión con una cuenta para acceder a recursos y objetos. Algunos servicios están configurados de forma predeterminada con la cuenta LocalSystem, que es una cuenta privilegiada con acceso completo al sistema. Si un servicio inicia sesión con esta cuenta en un controlador de dominio, el servicio tiene acceso al dominio entero. Otros servicios lo están con las cuentas LocalService o NetworkService, que son cuentas especiales integradas similares a una cuenta de usuario autenticado. Estas cuentas tienen el mismo nivel de acceso a los recursos y objetos que los miembros de grupos de usuarios. Este acceso limitado salvaguarda el sistema si se ven comprometidos servicios o procesos individuales.

Lista de permisos de un servicio

Implementando seguridad en los servicios del sistema en Windows Server 2003 nos permite controlar quien puede administrarlos en un equipo cliente, servidor miembro o controlador de dominio. Actualmente, el único camino para cambiar un servicio del sistema es mediante la configuración de directivas. Si implementamos directivas en la Default Domain Policy, la directiva se aplica a todos los equipos del dominio, si la implementamos en la Default Domain Controllers Policy, se aplica sólo a los servidores en la OU de controladores de dominio. Podemos crear OUs que contengan equipos a los que aplicarles la directiva.

El procedimiento paso a paso podría resumirse en:

1. Iniciar el complemento Usuarios y Equipos de Active Directory del controlador de dominio (DC) correspondiente.
   
2. Clic derecho sobre el dominio al que se desea añadir la OU, elegimos Nuevo y luego Unidad Organizativa.
   
3. Le damos un nombre apropiado y pulsamos en Aceptar. La nueva OU saldrá listada bajo el dominio.
   
4. Clic derecho sobre la nueva OU y luego en propiedades.
   
5. En la pestaña Directiva de Grupo, pulsamos en Nueva. 
6. Le damos un nombre apropiado.
7. Después de la creación de la directiva, la seleccionamos y pulsamos en el botón Editar.
   
8. Doble clic en Configuración de Equipo, doble clic en Configuración de Windows, doble clic en Configuración de Seguridad y doble clic en Servicios del sistema. 
9. Doble clic en el servicio al que queremos aplicar permisos.
10. Marcamos la casilla de verificación Definir esta configuración de directiva.
11. Clic en Modificar Seguridad.
    
12. Clic en Agregar para añadir la cuenta LocalSystem y cualquier otra cuenta de usuario a la que queremos asignarle acceso. Para agregar la cuenta LocalSystem, escribimos SYSTEM en el cuadro Escriba los nombres de objeto que desea seleccionar y luego en Aceptar.
       
13. Para cada cuenta de usuario o grupo añadido, seleccionamos el nombre, y seleccionamos la casilla de verificación Permitir bajo Control Total, además de los permisos apropiados para el usuario o grupo.
    
    • De forma predeterminada, sólo Iniciar, detener y poner en pausa están asignados a los nuevos usuarios.
      
14. Cuando terminamos de añadir usuarios o grupos y asignar sus permisos, clic en Aceptar.
15. El modo de inicio predeterminado del servicio está establecido en Deshabilitado. Cambiarlo al modo que queramos (normalmente Automático).
    
16. Pulsamos en Aceptar, cerramos la directiva de grupo y cerramos las propiedades de la OU.

La configuración de directivas locales no proporcionan la capacidad de configurar servicios. Si queremos configurar equipos aleatorios y restringir a un usuario detener o iniciar un servicio, usaremos el complemento plantillas de seguridad para definir una. Aplicaremos la plantilla al equipo mediante la herramienta Security Configuration and Analisys o la de línea de comandos Secedit.exe.

NOTA Si el usuario no es miembro del dominio, no podremos configurar servicios con directiva de grupo ya que no podemos definir la configuración de un servicio a menos qué seamos capaces de seleccionar el usuario desde el editor ACL. Con una cuenta específica de un equipo no es práctico crear una directiva de grupo y aplicarla a otros equipos que no reconocen la cuenta.
Un usuario del dominio puede usar la infraestructura de directivas de grupo para configurar múltiples equipos. Nosotros definimos la configuración de un servicio de la misma forma que con las plantillas de seguridad, excepto que usamos el editor de directivas y la misma se aplica automáticamente.

Herramientas del resource kit Windows 2000

Support tools XP SP2

support tools sp1 2003

Resource kit 2003

updates resource kit 2003

Exetype herramienta en línea de comandos del resource kit de Windows 2000, puedes descargarla desde Exetype.zip.

Creas un directorio, por ejemplo, C:TOOLS, y lo añades al path, y vas guardandote las herramientas en éste directorio.

Esta herramienta nos indica a que tipo de ejecutable pertenece el programa exe que consultamos, si es un programa GUI o es de consola, y otras pequeñas curiosidades. Abrimos una ventana cmd y tecleamos el comando y sus parámetros:

exetype programa_exe

Incluso me ha funcionado en un Vista.

Dependency walker herramienta GUI del mismo resource kit, puedes descargarla desde Dependency Walker Tool.

Podemos ver las dependencias, en la imagen las de NTOSKRNL.exe.

En mi Vista no funciona, aunque hay muchas alertas, es una herramienta 32 bits y mi máquina es de 64.

Ver los controladores instalados:

Podemos listarlos usando información del sistema desde inicio->todos los programas->accesorios->herramientas del sistema->entorno de software->controladores.

O podemos usar, drivers.exe o pstat (del resource kit 2000 o support tools de xp/2003) desde la línea de comandos,

El complemento Servicios puede usarse para reconfigurar un servicio, para ello abrimos el complemento, clic derecho en el servicio y pulsamos en propiedades. El cuadro de diálogo propiedades contiene 4 pestañas, cada una permite reconfigurar partes del servicio seleccionado. En la pestaña General podemos examinar y reconfigurar información general sobre el servicio.

Un servicio se identifica por dos nombres: un nombre interno (nombre del servicio) que se utiliza con propósitos de programación, y un nombre a mostrar (una cadena que se muestra ante los usuarios y administradores). En cuanto se añaden servicios a la base de datos de servicios del equipo su nombre interno no puede alterarse.

El administrador puede cambiar el tipo de inicio a uno de los siguientes:

• Automático Si un servicio tiene este tipo de inicio, SCM inicia el servicio cuando el sistema se inicia/reinicia. Los servicios automáticos se ejecutan antes de cualquier inicio de sesión interactivo de usuario en el equipo. De hecho, muchos equipos están configurados para ejecutar sólo servicios.
• Manual Si el tipo de inicio es manual, SCM no inicia el servicio al iniciarse/reiniciarse el equipo. Un administrador puede iniciarel servicio manualmente con SC.exe o Net.exe, o sea con una llamada explícita a StartService. Otro nombre con el que se conoce es un servicio de demand-start inicio por demanda, que también podrá iniciarlo otro servicio que dependa de que el servicio manual esté iniciado.
• Deshabilitado Cuando está configurado éste valor, SCM no inicia el servicio bajo ninguna circunstancia. Cualquier intento de iniciarlo con la API StartService fallará con el ERROR_SERVICE_DISABLED.

Configurar servicios con las herramientas de línea de comandos

Además del complemento Servicios, Windows Server 2003 nos da dos programas de control de servicios en línea de comandos.

Net.exe El límite de esta herramienta es que se circunscribe a los servicios residentes en el equipo local. Con ella podemos iniciar, detener, pausar y seguir servicios.

Net stop <nombre_servicio>     Net start <nombre_servicio>

Por ejemplo el servicio DHCP server, cuyo nombre interno es DHCPServer.

 Sc.exe Otra de las herramientas en línea de comandos. Localizado en raíz_Del_sistemasystem32 implementa llamadas a todas las funciones API Windows de control de servicios. Podemos establecer parámetros a dichas funciones especificándolas en la línea de comandos. También nos muestra el estado del servicio y recupera los valores almacenados en los campos de la estructura de estado. Nos deja además especificar el nombre de un equipo remoto para llamar a las funciones API de servicios o ver los estados de los servicios en el equipo remoto. Podemos cambiar la ruta al servicio con esta heramienta.

Configuración de las opciones de recuperación del servicio

La pestaña Recuperación del cuadro de diálogo propiedades nos permite definir un juego de acciones a tomar si un servicio falla, existiendo el servicio y en un estado distinto a detenido. Hay tres opciones de recuperación: primer error, segundo error y siguientes errores. La API subyacente permite un número de errores específicos no restringidos antes de responder con lo especificado en Siguientes errores; sin embargo, el complemento Servicios sólo expone dos.

Cuatro son las configuraciones disponibles para las opciones de recuperación:

• No realizar ninguna acción Si el servicio falla no se realizará ninguna acción. Opción predeterminada para todos los servicios.
• Reiniciar el servicio Si el servicio falla, será reiniciado.
• Ejecutar un programa Si el servicio falla, un programa seleccionado por un administrador se ejecutará en el contexto el servicio. Si está opción está seleccionada, los campos bajo Ejecutar programa se activan y se necesitará configurar parámetros adicionales, como el programa a ejecutar.

• Reiniciar el equipo Si el servicio falla, el equipo se reiniciará. Si esta opción está seleccionada, el botón de opciones de reinicio del equipo se activa y hay que configurar parámetros adicionales -como el tiempo que se esperará hasta el reinicio del equipo-. SCM envía un mensaje a dosos los equipos con sesiones activas conectadas a éste equipo antes del reinicio.

Podemos configurar las opciones de recuperación para cómo responderá el sistema en el caso de un error del servicio. Sin embargo, hay limitaciones para configurar los servicios. Ya que ellos ejecutan procesos críticos del sistema, los siguientes servicios están preconfigurados automáticamente para reiniciar el equipo si fallan y no tienen opciones de recuperación configuradas:

• Registro de sucesos (Event Log)
• Servicios IPSEC (IPSEC Services)
• Inicio de sesión (Net Logon)
• Enchufar y listo (Plug and Play)
• Almacenamiento protegido (Protected Storage)
• Administrador de cuentas de seguridad (Security Accounts Manager)

El servicio RPC también está preconfigurado para reiniciar el equipo si falla, pero podemos reconfigurar sus opciones de recuperación.

Los siguientes lo están para ser reiniciados por el SCM en su primer y segundo error:

• Coordinador de Transacciones Distribuidas (Distributed Transaction Coordinator)
• Ayuda y Soporte (Help and Support)
• Cola de impresión (Print Spooler)
• Administrador de subidas (Upload Manager)
• Hora de Windows (Windows Time)

Las opciones de recuperación ocurren sólo si el servicio falla, no en otros casos.

Windows Server 2003 ofrece herramientas que permiten administrar/configurar un servicio tanto local como remotamente desde otros equipos de la red. Cuando usamos estas herramientas no es necesario estar frente a la máquina física que ejecuta el servicio.

Integradas con Windows Server nos ayudan a la administración y configuración de servicios:

• Elementos de consola MMC (snap-in) Servicios.
• Sc.exe Herramienta de línea de comandos, comunicación con SCM e instalador de servicios. Sc.exe Recupera y establece la información de control de los servicios.
• Net.exe Herramienta de línea de comandos, detiene, inicia, sigue y pausa servicios.
• Elementos de plantillas de seguridad (snap-in) Una plantilla de seguridad es un archivo que representa una configuración de seguridad o una configuración de directiva de seguridad. Estas plantilla pueden entonces aplicarse al equipo local o importada a una GPO. El elemento Servicios, Sc.exe y Net.exe son programas de control de servicio.

Para usar Servicios en la administración remota debemos ir a Administración de equipos (herramientas administrativas) del panel de Control, una vez abierto: desde el Menú Acción elegiremos Conectar con otro equipo. El nodo Servicios aparece bajo Servicios y Aplicaciones.

También podemos seleccionar Services (Local) en el árbol de la consola Services y elegir conectar con otro equipo del menú Acción.

Inicio-> Ejecutar -> services.msc ENTER

Clic derecho en Servicios (locales) o clic en Menú Acción, y elegimos conetar con otro equipo.

Para el uso de Sc.exe en un equipo remoto, usamos el parámetro ServerName para especificar el nombre el equipo remoto donde se encuentra el servicio. El nombre debe usarse con la convención UNC, por ejemplo \juansa-xp.

sc <servername> [comando] [servicename] <option1> <option2>

Después de establecida la conexión con el equipo remoto ya podemos consultar y comunicar con el SCM.

Inicio, detención, deshabilitar y reemprender servicios.

Las tareas más comunes asociadas con la administración de los servicios son: iniciarlos, detenerlos, deshabilitarlos y cambiar la forma en que se inician.

Podemos realizar las tareas, tanto local como remotamente, mediante el elemento Services, normalmente:

• Iniciar un servicio     Clic derecho sobre el servicio y luego en propiedades. Pestaña General, pulsar en iniciar. Sólo los servicios con un tipo de inicio automático o manual pueden iniciarse; los deshabilitados no.
• Deshabilitar un servicio    Clic derecho sobre el servicio y luego en propiedades. Pestaña General, pulsar en deshabilitar. Deshabilitar un servicio puede ser útil para la resolución de problemas en un equipo.
• Detener un servicio     Clic derecho sobre el servicio y luego en propiedades. Pestaña General, pulsar en detener. Hay algunos servicios que no permiten detenerse a ellos mismos una vez arrancados. Sólo se detienen cuando se apaga el equipo.
• Pausar o resumir un servicio   Clic derecho sobre el servicio y luego en propiedades. Pestaña General, pulsar en pausar o resumir según convenga. Hay servicios que no se dejan pausar ellos mismos. La pausa no tienen una definición exacta; pues para un servicio pausar puede significar que el servicio no aceptará solicitudes de clientes hasta que finalice el proceso de salida de solicitudes, mientras que para otro puede significar que el servicio no seguirá ningún proceso de sus operaciones.
• Reiniciar un servicio   Clic derecho sobre el servicio y luego en propiedades. Pestaña General, pulsar en Reiniciar. El reinicio causa una detención y un inicio acto seguido. Es una conveniente y simple característica, bastante útil cuando depuramos nuestro propio servicio.

Todas las tareas pueden realizarse también desde los botones de la barra de herramientas del complemento Servicios.

NetworkService

En equipos con Windows Server 2003 los servicios también pueden configurarse para iniciar sesión con la cuenta NetworkService. Como LocalSystem no necesita contraseña, es decir, su contraseña es una contraseña vacía.

Cuenta integrada del sistema tiene los privilegios de un usuario autentificado; por lo que ofrece una alternativa para la ejecución de servicios en lugar de la cuenta LocalSystem. No hay directiva de bloqueo para la cuenta NetworkService ya que no está protegida por contraseña. El mecanismo de protección es qué sólo un proceso ejecutándose bajo la cuenta LocalSystem puede relizar un inicio de sesión con NetworkService (o LocalSystem), y debe ser un servicio tipo con inicio de sesión.

La cuenta NetworkService está prevista para servicios que no tienen la necesidad de privilegios locales extensivos, ya que no necesita acceso a red autentificada. Los servicios que se ejecutan bajo esta cuenta acceden a los recursos locales como usuarios corrientes. Cuando acceden a recursos de red, deben utilizar las credenciales del equipo. Un servicio ejecutándose con NetworkService tiene el mismo acceso de red como uno que se ejecuta bajo LocalSystem, pero con un acceso local significativamente reducido.

Los privilegios siguientes están disponibles para servicios ejecutándose con la cuenta NetworkService:

• SeShutdownPrivilege
• SeAuditPrivilege
• SeChangeNotifyPrivilege
• SeUndockPrivilege
• SeImpersonatePrivilege

Para información sobre estos privilegios http://msdn.microsoft.com/en-us/library/bb530716(VS.85).aspx

LocalService

En equipos con Windows Server 2003 también puede usarse para iniciar sesión servicios, e igualmente a las anteriores esta cuenta no necesita de contraseña.

La cuenta LocalService se provee para servicios que son locales del equipo, no tiene privilegios extendidos y no necesita autentificación de red. Tanto bajo LocalService como bajo NetworkService se disponen de los mismos privilegios. Acceden a los recursos locales como usuarios corrientes y acceden a los recursos de red como usuarios anónimos. Un servicio ejecutándose con esta cuenta tiene menos autoridad que uno que lo hace bajo LocalSystem, tanto en local como en red.

La lista de privilegios es idéntica a la expuesta arriba.

Cuenta de usuario del dominio

Muchos servicios necesitan ejecutarse con una cuenta de inicio de sesión separada con permisos más específicos que LocalSystem, NetworkService o LocalService. Los programas instaladores de estos servicios se encargan de crear la cuenta de inicio de sesión y configurar las listas de control de acceso (ACLs) necesarias para darle los derechos apropiados a la cuenta.

Instalar un servicio con el uso de una cuenta de usuario del dominio con contraseña permite al servicio tener el acceso que la cuenta de dominio ofrece. Esta cuenta puede ser miembro de múltiples grupos de seguridad y no está sujeta a eliminación o renovación si el equipo abandona o se vuelve a unir al dominio. Para asignar acceso a áreas de Active Directory a servicios que usan cuentas de usuario de inicio de sesión, podemos fácilmente usar pertenencias a grupos; sin embargo, ejecutar un servicio bajo este contexto tiene ciertas desventajas:

• La cuenta debe crearse antes que el servicio pueda ejecutarse. Si el programa de instalación del servicio crea la cuenta, éste debe ejecutarse desde una cuenta con los suficientes privilegios para la creación de cuentas en el servicio de directorio.
• Los nombres y contraseñas de cuentas se almacenan en cada equipo donde el servicio se instala. Si la contraseña de una cuenta del servicio de un equipo se cambia o caduca, el servicio no podrá iniciarse en el equipo hasta que la contraseña se establezca como nueva contraseña para ese servicio. La recomendación es utilizar LocalService y NetworkService siempre que sea posible en lugar de una cuenta que requiere de contraseña, con ello simplificamos la administración de contraseñas.
• Si una cuenta de servicio se renombra, bloquea, desactiva o elimina, el servicio no podrá iniciarse en el equipo hasta reiniciarla.

Una cuenta de usuario del dominio tiene dos formatos que necesitamos para realizar diversas operaciones: el nombre distinguido del objeto usuario en el directorio y el formato DOMINIONOMBRE_USUARIO utilizado por el SCM local.

Cuando configuramos un servicio para ejecutarse con cierta cuenta, el SCM llamará a Lsass.exe para mirar la cuenta mediante las APIs LsaLookup. LocalSystem es una excepción ya que hay demasiadas variaciones para el nombre. Si la cuenta es válida, SCM permite el cambio de configuración. La próxima vez que el servicio se inicie, SCM llama a LogonUser para la cuenta mediante la contraseña especificada (usando el nombre _SC-Service como contraseña, técnicamente) para realizar el inicio de sesión del servicio-tipo, e inicia el proceso con el token de inicio de sesión devuelto. Si el proceso recibe el SID del servicio en su token, el proceso se identifica como un proceso de servicio.

Cuenta de usuario Local

Una cuenta de usuario local sólo existe en la base de datos SAM del equipo local; no tiene objeto de usuario en AD. Esto significa que un usuario local no puede autentificarse en el dominio. Consecuentemente, un servicio ejecutándose con una cuenta de usuario local no tiene acceso a recursos de red(excepto como usuario anónimo) y no es compatible con Kerberos. Por estas razones, este tipo de cuenta resulta inapropiado para servicios relacionados con el directorio. Sin embargo, bajo este contexto de seguridad se tienen muy pocos privilegios y puede causarse poco daño en el caso malintencionado de la cuenta.

Los servicios ejecutándose como administradores en controladores de dominio son una excepción para las cuentas bajo el contexto de seguridad de cuentas de usuario local para servicios de directorio; consecuentemente, los mismos cuidados son de aplicación a cuentas de usuario local en cuanto a nombre de cuenta y contraseña como a las cuentas de usuario del dominio.

LocalSystem es una cuenta local predefinida especial, disponible sólo para procesos del sistema. Esta cuenta no tiene contraseña.

En equipos con NT un servicio que se sejecuta en el contexto de LocalSystem hereda el contexto de SCM. El servicio no está asociado a ninguna sesión iniciada por una cuenta de usuario y no dispone de credenciales (nombre de dominio, nombre de usuario y contraseña) para utilizarse como comprobación. El servicio tiene acceso limitado a los recursos de red, ya que no tiene credenciales y se conecta por medio de una sesión nula.

En equipos con Windows 2000/2003, el mismo servicio y contexto usa las credenciales del equipo cuando accede a recursos sobre la red y tiene acceso total a los recursos locales. Para aquéllos servicios que acceden al servicio de directorio (AD), el contexto de LocalSystem es restringido. Cuando un servicio se ejecuta bajo LocalSystem en un equipo que es miembro de un dominio, el servicio se ejecuta bajo el contexto de la cuenta del equipo en cuanto accede a los recursos del dominio. Las cuentas de equipo normalmente disponen de pocos privilegios y no pertenecen a Grupos. Añadir cuentas de equipo a grupos no es recomendable ya que las cuentas están sujetas a eliminación y nueva creación si el equipo abandona o se vuelve a unir al dominio.

Por otro lado, un servicio ejecutándose bajo el contexto de LocalSystem en un controlador de dominio tiene acceso total al directorio, ya que el DC aloja una réplica y LocalSystem tiene acceso total a los recursos locales. El servicio NET LOGON es un ejemplo de un servicio que se ejecuta bajo la cuenta LocalSystem.

Si es posible, no ejecutar servicios bajo LocalSystem en un controlador de dominio. Ya que haciéndolo damos al servicio demasiado acceso a AD, ya que en un DC LocalSystem tiene control total del AD, y podría causar daños serios a la información de directorio.

La cuenta Localystem es la misma cuenta en que todos los componentes del sistema operativo en modo usuario de Windows Server 2003 se ejecutan, incluyendo Smss.exe (Session Manager), Crss.exe (Client/Server Runtime Subsystem), Lsass.exe (local security authority subsystem service), Winlogon.exe (Winlogon process), algunos servicios ubicados en la carpeta ruta_del_sistemaSystem32, y Services.exe (SCM).

Desde una perspectiva de seguridad, ésta cuenta es extremadamente potente -más que cualquier cuenta local o de dominio cuando se trata de un equipo local. Algunas de sus características:

• Es miembro del grupo de Administradores.
• Tiene el derecho a permitir cualquier privilegio, incluso aquéllos que normalmente no dispone la cuenta de administrador local, como crear tokens de seguridad.
• La mayoría de archivos y claves del registro permiten acceso total a la cuenta LocalSystem. Incluso no permitiéndole acceso total, un proceso en ejecución bajo su contexto puede ejercer el privilegio de tomar propiedad para ganar el acceso necesario.
• Los procesos que se ejecutan bajo la cuenta LocalSystem corren con el perfil de Default user (HKEY_USERS.DEFAULT). Pueden acceder a información de configuración almacenada en los perfiles de usuario de otras cuentas mediante la clave del registro HKEY_USERS<SID>.
• Cuando un equipo es miembro de un dominio basado en Windows Server 2003, la cuenta LocalSystem incluye el SID del equipo en el que el servicio se ejecuta. Por lo tanto, un proceso en ejecución con esta cuenta se autenticará automáticamente en otro equipo en el mismo bosque mediante la cuenta de equipo del equipo donde se ejecuta el servicio.
• A menos que específicamente le esté permitido a la cuenta de equipo acceder a recursos (como carpetas compartidas y otros), un proceso puede acceder a recursos de red a los que permite una sesión nula -es decir, conexiones que no necesitan credenciales. Podemos especificar las carpetas compartidas y Named pipes en un equipo en particular que permita sesiones nulas en las entradas del registro NullSessionPipes y NullSessionShares de la clave HKLMSYSTEMCurrentControlSetServicesLanmanserverparameters.

Puedes ver parte de los privilegios de LocalSystem Account aquí.

Otra restricción para servicios ejecutándose bajo la cuenta LocalSystem es que estos generalmente no pueden mostrar cuadros de diálogo o ventanas iterativas en el escritorio del usuario sin el uso de una bandera especial de la función MessageBox. Esta limitación nos es resultado directo de ejecución bajo LocalSystem, es una consecuencia de la forma en que SCM asigna los servicios a las estaciones de ventanas.

Csrss.exe asocia cada proceso Win32 con una window station. Esta, a su vez, contiene escritorios, y los escritorios contienen ventanas. Sólo una window station puede ser visible en una consola y recibir la entrada de ratón y teclado. En un entorno de Terminal Server, una window station por sesión es visible, pero los servicios se ejecutan todos como parte de una sesión de consola. Win32 nombra la ventana visible como WinSta0. Todos los procesos iteractivos acceden a WinSta0.

Un servicio interactivo debe abrir WinSta0, pero antes de que SCM permita al servicio interactivo acceder a WinSta0 comprobará si ve si el valor de la entrada del registro NonInteractiveServices que cuelga de HKLMSYSTEMCurrentControlSetControlWindows es 1. Los administradores establecen este valor para impedir que los servicios configurados como interactivos muestren pantallas en la consola. Esta opción es deseable en un entorno de servidor sin atención en el que no hay presente usuario para responder a cuadros de mensajes de los servicios interactivos.

Nota:La herramienta de línea de comandos Objdir.exe puede utilizarse para ver objetos nombrados, incluyendo window stations en el objeto de directorio ruta_del_sistemaWindowStations. Winobj es la versión GUI. Para listar todos los servicios interactivos, debemos enumerar todos los servicios y llamar a QueryServiceConfig para cada servicio. Una buena forma es crear un script para hacer esto usando WMI o un archivo por lotes (BAT).

A menos que se indique otra cosa, SCM asocia los servicios con una window station no visible llamada Service-0x0-3e7$ que todos los servicios no interactivos comparten. El número en el nombre, 3e7, representa el identificador de sesión iniciada que Lsass.exe asigna para la cuenta LocalSystem.

De forma más específica, SCM utiliza el <LUID> del servicio donde <LUID> es el LOGON ID del inicio de sesión realizado por este servicio. Los servicios que se ejecutan con la cuenta LocalSystem reciben 0x0-3e5 y los que se ejecutan con la cuenta NetworkService 0x0-3e4. Aunque los primeros normalmente reciben el 0x0-3e7.

Los servicios configurados para ejecutarse con una cuenta de usuario se ejecutan en una window station no visible distinta cuyo nombre es el Lsass.exe LOGON PID asignado para la sesión iniciada del servicio.

A pesar de si los servicios se ejecutan con una cuenta de usuario o la cuenta LocalSystem, los que no se ejecutan en la window station visible no reciben entradas desde nosotros o de la pantalla en la consola. De hecho, si un servicio abre un cuadro de diálogo normal en la window station puede que aparezca como colgado ya que no hay usuario capaz de ver el cuadro de diálogo, que por supuesto impediría al usuario proporcionar cualquier entrada (ratón o teclado) para descartarlo.

Sólo los servicios configurados para ejecutarse con la cuenta LocalSystem pueden configurarse como interactivos.

Cuando SCM inicia un servicio configurado como interactivo, inicia el proceso en el contexto de seguridad de la cuenta LocalSystem pero lo conecta con WinSta0 en lugar de la window station de servicio no interactivo. Esta conexión hacia WinSta0 permite al servicio mostrar cuadros de diálogo y ventanas en la consola y permite a estas ventanas responder a entradas del usuario.