KomuraSoft LLC
Contáctenos
Menú

Selección de la cuenta de un servicio de Windows — Cuándo usar LocalSystem, cuentas virtuales y gMSA

· Actualizado el: · · Windows, Servicios de Windows, Cuentas de servicio, gMSA, LocalSystem, Cuentas virtuales, Seguridad, Active Directory, Privilegio mínimo

«El servicio interno que veníamos ejecutando con LocalSystem “por ahora” recibió en la auditoría de seguridad la observación de “privilegios excesivos”. ¿A qué debería cambiarlo?» «Como el servicio no podía acceder a la carpeta compartida, lo ejecutamos con un usuario de dominio. Como el servicio se detiene cuando vence la contraseña, la configuramos sin vencimiento, y quedó escrita en texto plano en el procedimiento» — estas dos consultas sobre servicios de Windows son clásicas entre nuestros clientes.

Lo que tienen en común ambos casos es que la cuenta de ejecución del servicio quedó fija como una “configuración que funcionó”, no como una “decisión de diseño”. Un servicio de Windows siempre se ejecuta en el contexto de seguridad de alguna cuenta, y esa cuenta determina por completo qué puede hacer localmente, quién la ve desde el otro lado de la red y quién gestiona la contraseña. Si se deja este punto en su valor predeterminado, la vulnerabilidad de un solo servicio se convierte directamente en la toma de control de toda la máquina, y las contraseñas en texto plano terminan dispersas por procedimientos y scripts.

Las tres cosas que determina la cuenta de ejecuciónUn servicio siempre se ejecuta en el contexto de seguridad de alguna cuenta, y esa cuenta determina qué puede hacer localmente, quién la ve desde el otro lado de la red y quién gestiona la contraseñaCuenta de ejecución del servicioQué puede hacer localmenteQuién la ve desde el otro lado de la redQuién gestiona la contraseña

Figura 1: La elección de la cuenta de ejecución es una decisión de diseño que fija a la vez el privilegio local, la identidad en red y la gestión de la contraseña.

En la práctica hay seis opciones — LocalSystem, LocalService, NetworkService, la cuenta virtual (NT SERVICE\), el usuario de dominio y gMSA (cuenta de servicio administrada de grupo). Este artículo se dirige a responsables de sistemas de pequeñas y medianas empresas y a desarrolladores de aplicaciones de Windows: organiza en una sola tabla los privilegios, la identidad en red y la gestión de contraseñas de estas seis opciones, y llega hasta un flujo de decisión, todo basado en fuentes primarias de Microsoft Learn vigentes en agosto de 2026.

La forma de construir el servicio en sí (cuándo usarlo frente al Programador de tareas, la implementación con .NET Worker Service) se trata en «Cómo crear y operar servicios de Windows». Este artículo se centra en la “cuenta de ejecución”, que es donde ocurren la mayoría de los incidentes.

1. Conclusión principal

  • Si tiene dudas, para un servicio que se completa dentro de una sola máquina, la primera opción es la cuenta virtual; para uno que accede a recursos del dominio con una identidad propia del servicio, la primera opción es gMSA. Microsoft también recomienda usar siempre que sea posible una cuenta administrada (MSA/cuenta virtual).12
  • No elija LocalSystem solo “porque funciona”. Su token incluye SYSTEM y BUILTIN\Administrators y tiene privilegios potentes como SeDebugPrivilege, así que si lo comprometen, pierde prácticamente toda la máquina. Que el valor predeterminado de sc.exe create sea LocalSystem es el caldo de cultivo de este incidente.34
  • La diferencia entre LocalService y NetworkService es la identidad en red. El privilegio local es mínimo en ambos casos, pero de cara al exterior LocalService se ve como anónimo y NetworkService se ve como la cuenta de equipo.5
  • **La cuenta virtual (NT SERVICE\) es la solución moderna por defecto: separa la identidad de cada servicio sin necesidad de gestionar contraseñas.** Se puede indicar directamente "NT SERVICE\\nombre_del_servicio" en la ACL, y también es la cuenta de servicio predeterminada de SQL Server.[^understand-service-accounts][^sql-service-accounts]
  • Cuando LocalSystem, NetworkService o la cuenta virtual salen a la red, se convierten en la cuenta de equipo (DOMAIN\nombre_del_equipo$). Otorgar el PC$ a la carpeta compartida o a la ACL de SQL Server permite evitar el usuario de dominio en muchos casos.36
  • Usar un usuario de dominio en un servicio genera pasivos tanto en la operación de contraseñas como frente al Kerberoasting. El SCM inicia sesión con la contraseña guardada, así que el vencimiento provoca un fallo de inicio del servicio, y evitarlo con “sin vencimiento + nota en texto plano” es un regalo para los atacantes.78
  • gMSA hace que Active Directory genere y rote automáticamente la contraseña. Los requisitos son el dominio y la clave raíz de KDS; en el servicio se configura “DOMAIN\nombre_de_cuenta$” con el campo de contraseña vacío. Hay que verificar de antemano si la aplicación es compatible.910
  • Cambiar de cuenta cambia las suposiciones del perfil, %TEMP% y DPAPI. Los datos protegidos con DPAPI de la cuenta anterior no se pueden descifrar con la cuenta nueva.
  • El inventario actual se puede confirmar con la cuenta de ejecución de la lista de servicios y con el evento ID 4624 (tipo de inicio de sesión 5).11

Resumido en una frase, la conclusión de este artículo es: use como norma configuraciones que “no den al servicio una contraseña de tipo humano” (cuentas integradas, cuentas virtuales, gMSA), y deje el usuario de dominio como último recurso.

2. Panorama general de las opciones — Las 6 cuentas de ejecución en una sola tabla

Repasemos primero un punto de base. Al iniciarse el servicio, el Administrador de control de servicios (SCM) inicia sesión con la cuenta configurada y, si tiene éxito, crea un token de acceso y lo asigna al proceso del servicio. A partir de ahí, todo acceso a archivos, canalizaciones y demás recursos se decide comparando este token con la ACL.7 Es decir, elegir la cuenta de ejecución es diseñar el contenido del token que se entrega al proceso del servicio. A continuación se enumeran las seis opciones.

Lo que hace el SCM al iniciar un servicioEl SCM inicia sesión con la cuenta configurada y, si tiene éxito, crea un token de acceso y lo asigna al proceso del servicio; a partir de ahí, todo acceso a recursos se decide comparando el token con la ACLSíNoSCMInicia sesión con la cuenta configuradaCrea un token de accesoLo asigna al proceso del servicioAcceso a archivos o canalizaciones¿La ACL lo permite?Acceso concedidoAcceso denegado

Figura 2: Todo acceso a recursos del servicio se decide comparando el token que crea el SCM al iniciar con la ACL.

Cuenta Privilegio local Identidad en red Gestión de contraseña Uso principal
LocalSystem Prácticamente sin límite (SYSTEM+Administrators) Cuenta de equipo (PC$) No requerida (sin contraseña) Solo servicios excepcionales integrados con el SO
LocalService Mínimo (equivalente a Users) Anónimo No requerida Procesamiento local que no necesita identidad en red
NetworkService Mínimo (equivalente a Users) Cuenta de equipo (PC$) No requerida Bajo privilegio + identidad por máquina suficiente
Cuenta virtual NT SERVICE\ Mínimo + otorgado individualmente por ACL Cuenta de equipo (PC$) No requerida (gestión automática) Solución por defecto para servicios de negocio en un solo servidor
Usuario de dominio Solo lo otorgado El propio usuario Manual (vencimiento, filtración y rotación quedan a cargo de personas) Último recurso para apps no compatibles con gMSA
gMSA Solo lo otorgado El propio gMSA AD la genera y rota automáticamente Cuando se necesita una identidad propia del servicio en un entorno de dominio

LocalSystem, LocalService, NetworkService y la cuenta virtual no tienen siquiera el concepto de contraseña. Iniciar sesión con una contraseña guardada en el SCM (es decir, algo que puede vencer o filtrarse) solo ocurre con usuarios de dominio y usuarios locales.73

A continuación profundizamos esta tabla fila por fila.

3. Cuál es el problema de LocalSystem

3.1. Más fuerte que “ejecutar como administrador”

LocalSystem (cuyo nombre de presentación es Sistema local, NT AUTHORITY\SYSTEM) es la cuenta predefinida que usa el SCM, y tiene privilegios amplios en el equipo local. El token incluye los SID de NT AUTHORITY\SYSTEM y BUILTIN\Administrators, y puede acceder a casi todos los objetos del sistema. Además, tiene habilitados por defecto SeDebugPrivilege, que permite depurar otros procesos, y SeTcbPrivilege, que le permite actuar como parte del sistema operativo.3

Esta fortaleza equivale al tamaño del daño cuando lo comprometen. Si un servicio que se ejecuta con LocalSystem tiene una sola vulnerabilidad de ejecución remota de código, el atacante llega de una sola vez a leer y alterar los archivos de todos los usuarios (en NTFS, SYSTEM tiene control total por defecto5), leer la memoria de otros procesos gracias a SeDebugPrivilege, y robar credenciales para moverse lateralmente (por ejemplo, con un ataque Pass-the-Hash como punto de partida). La cadena de robo de credenciales y movimiento lateral se trata en «NTLM y Kerberos explicados con diagramas» y en «Guía práctica de Windows LAPS».

Daño cuando se compromete un servicio con LocalSystemSi un servicio que se ejecuta con LocalSystem tiene una sola vulnerabilidad de ejecución remota de código, el atacante llega a leer y alterar los archivos de todos los usuarios, leer la memoria de otros procesos, robar credenciales y moverse lateralmenteUna vulnerabilidad de ejecución de códigoEl atacante obtiene privilegios SYSTEMLectura y alteración de archivosLectura de memoria de otros procesosRobo de credencialesMovimiento lateral a otras máquinas

Figura 3: Con una sola vulnerabilidad en un servicio con LocalSystem, el atacante llega de una vez a tomar toda la máquina y a un punto de partida para el movimiento lateral.

3.2. Por qué se lo sigue eligiendo

La razón es simple: es el valor predeterminado y nunca produce un acceso denegado. Cuando se omite obj= en sc.exe create, el valor predeterminado es LocalSystem4, y todavía abundan ejemplos de código antiguos y plantillas de instalador que dan por sentado LocalSystem. Como durante el desarrollo no aparecen errores de permisos, se genera en serie el patrón de “funcionó, así que se deja así”. La propia documentación de Microsoft indica explícitamente que la mayoría de los servicios no necesita un nivel de privilegio tan alto, y que conviene considerar LocalService o NetworkService cuando no sea necesario.3

La estructura que perpetúa el uso de LocalSystemEl valor predeterminado de sc.exe create es LocalSystem, y muchos ejemplos y plantillas antiguos también lo dan por hecho, así que durante el desarrollo no aparecen errores de permisos y se generan en serie configuraciones que se dejan tal como funcionaronValor predeterminado de sc.exe createSe crea con LocalSystemEjemplos y plantillas antiguosNo aparece acceso denegado durante el desarrolloSe deja tal como funcionóSe generan en serie servicios con privilegios excesivos

Figura 4: El valor predeterminado y una experiencia de desarrollo sin “acceso denegado” generan en serie servicios que quedan fijos en LocalSystem.

3.3. Diferencia con TrustedInstaller — LocalSystem tampoco es ilimitado

Cabe aclarar que llamar a LocalSystem “la cuenta más fuerte de Windows” no es exacto. Desde Windows Vista, la Protección de recursos de Windows (WRP) permite modificar los archivos, carpetas y claves de registro críticos del sistema operativo solo a TrustedInstaller (el servicio Instalador de módulos de Windows); ni siquiera SYSTEM ni un administrador pueden escribir ahí, y reciben acceso denegado.12 El mensaje del Explorador «Necesita permiso de TrustedInstaller para realizar esta acción» refleja este mecanismo. Dicho de otro modo, LocalSystem tiene acceso a prácticamente todo lo que queda fuera del área protegida por WRP, y normalmente no hay motivo para otorgárselo a un servicio de negocio.

Relación entre el área protegida por WRP y TrustedInstallerSolo TrustedInstaller puede modificar los archivos de sistema y claves de registro críticos que protege WRP; incluso SYSTEM o un administrador reciben acceso denegadoPuede modificarAcceso denegadoCasi todo permitidoTrustedInstallerArchivos de sistema protegidos por WRPSYSTEM y administradoresFuera del área protegida por WRP

Figura 5: LocalSystem tampoco es ilimitado; la modificación del área protegida por WRP solo se permite a TrustedInstaller.

3.4. Casos en los que LocalSystem es razonable

Es razonable, como excepción, cuando el servicio interactúa estrechamente con controladores de dispositivo, manipula la base de seguridad del sistema operativo o administra otras sesiones o servicios: en resumen, cuando el privilegio requerido ya supera de por sí lo equivalente a un administrador. Software como los agentes de copia de seguridad o los EDR entra en esta categoría. Aun en esos casos, vale la pena confirmar si realmente existe una ruta de código que use ese privilegio, y evaluar si el procesamiento que lo necesita se puede aislar (para el criterio de cuándo hace falta, vea «Cuándo se necesita el privilegio de administrador en Windows»).

4. LocalService y NetworkService — Cuentas integradas de privilegio mínimo

LocalService (NT AUTHORITY\LOCAL SERVICE, SID: S-1-5-19) y NetworkService (NT AUTHORITY\NETWORK SERVICE, SID: S-1-5-20) son cuentas integradas preparadas para servicios de bajo privilegio. Ambas tienen solo privilegios mínimos en el ámbito local, aproximadamente equivalentes a los de un miembro del grupo Users.51

La diferencia entre ambas es un solo punto: quién las ve desde el otro lado de la red.5

  • LocalService: se conecta de forma remota con credenciales anónimas. No puede acceder a recursos que exijan autenticación.
  • NetworkService: presenta de forma remota las credenciales del equipo (en un entorno de dominio, DOMAIN\nombre_del_equipo$).

El criterio de uso es: si “no sale a la red, o le da igual la identidad al salir”, use LocalService; si “quiere acceder a un recurso del dominio con la identidad de la máquina”, use NetworkService.

Diferencia entre LocalService y NetworkServiceAmbos tienen privilegios locales mínimos, pero frente a un recurso remoto LocalService se conecta con credenciales anónimas y NetworkService presenta las credenciales del equipoLocalServiceSe conecta con credenciales anónimasNo sirve para recursos que exigen autenticaciónNetworkServicePresenta las credenciales del equipoEn un dominio se ve como PC$

Figura 6: Aunque el privilegio local sea el mismo mínimo en ambas, se diferencian en si la identidad vista desde la red es anónima o la cuenta de equipo.

Sin embargo, vistas desde una perspectiva moderna, estas dos cuentas tienen una debilidad: muchos servicios comparten la misma cuenta. Si hay cinco servicios ejecutándose con LocalService, mientras la ACL opere por cuenta, esos cinco pueden acceder entre sí a sus recursos. SQL Server tampoco admite la cuenta Local Service precisamente porque, al ser una cuenta compartida, no se puede separar de otros servicios.1

Una cuenta compartida no permite separaciónCuando varios servicios comparten el mismo LocalService, mientras la ACL opere por cuenta, pueden acceder entre sí a sus recursosServicio AMismo LocalServiceServicio BServicio CPueden acceder a los recursos mutuosPorque la ACL opera por cuenta

Figura 7: Los servicios que comparten una misma cuenta no se pueden separar entre sí mediante la ACL.

Resolver este “quiero mantener el bajo privilegio, pero separado por servicio” es el papel de la cuenta virtual, que se ve a continuación.

5. Cuenta virtual (NT SERVICE\) — La solución moderna por defecto

5.1. Una identidad propia por servicio, sin contraseña

La cuenta virtual es una “cuenta local administrada” disponible desde Windows Server 2008 R2 / Windows 7. Tiene tres características.6

  • La cuenta se administra automáticamente: no requiere crearla ni establecerle contraseña
  • El nombre es NT SERVICE\<nombre_del_servicio>, así que cada servicio obtiene una identidad propia
  • En un entorno de dominio, puede acceder a la red con las credenciales de la cuenta de equipo (DOMAIN\nombre_del_equipo$)

En otras palabras, conserva la ventaja de LocalService/NetworkService de “no requerir gestión de contraseñas” y, al mismo tiempo, resuelve la desventaja de “no poder separarse por compartir cuenta”. Que la instalación de SQL Server use por defecto una cuenta virtual como NT SERVICE\MSSQLSERVER obedece a esto.1

Lo que la cuenta virtual conciliaLa cuenta virtual conserva la ventaja de LocalService y NetworkService de no requerir gestión de contraseñas, resuelve la desventaja de no poder separarse por compartir cuenta, y da a cada servicio una identidad propiaSe conservaSe resuelveVentaja（no requiere gestión de contraseñas）Cuenta virtualDesventaja（no se puede separar al compartirse）Identidad propia por servicioNo requiere creación ni contraseña

Figura 8: La cuenta virtual conserva las ventajas de las cuentas integradas y solo resuelve la desventaja de no poder separarse al compartirse.

5.2. Se puede escribir “NT SERVICE\nombre_del_servicio” directamente en la ACL

La comodidad práctica es que se puede agregar a la ACL nombrando explícitamente solo a ese servicio. Se puede lograr “solo este servicio puede escribir en esta carpeta de datos”, sin crear un grupo ni gestionar contraseñas.

# Cambia la cuenta de inicio de sesión del servicio a una cuenta virtual
# El valor de obj= es "NT SERVICE\nombre_del_servicio". No se especifica contraseña
sc.exe config MyAppService obj= "NT SERVICE\MyAppService"

# Verifica la configuración (comprueba SERVICE_START_NAME)
sc.exe qc MyAppService

# Otorga permiso de modificación de la carpeta de datos solo a este servicio
icacls "C:\ProgramData\MyApp" /grant "NT SERVICE\MyAppService:(OI)(CI)M"

Desde la GUI, en services.msc, vaya a las propiedades del servicio → pestaña “Iniciar sesión” → en “Cuenta” escriba NT SERVICE\nombre_del_servicio, y deje el campo de contraseña en blanco (es una particularidad del SCM que no se especifique contraseña para cuentas virtuales o MSA). El cambio surte efecto al reiniciar el servicio.

5.3. Limitación — fuera de la máquina no se distingue “qué servicio es”

La identidad de la cuenta virtual es local a la máquina y el dominio no la reconoce. Como se ve más adelante, en la red se reduce a la cuenta de equipo, así que el lado remoto no puede distinguir “de qué servicio se trata”, ni tampoco se puede compartir la misma identidad entre varios servidores.10

La identidad de la cuenta virtual se reduce fuera de la máquinaDentro de la máquina cada servicio tiene su propia cuenta virtual, pero en la red se reduce a la cuenta de equipo, y del lado remoto no se puede distinguir de qué servicio se trataCuenta virtual ACuenta de equipo PC$Cuenta virtual BIdentidad vista desde el lado remotoNo se distingue de qué servicio se trata

Figura 9: Dentro de la máquina cada servicio tiene identidad propia, pero de cara a la red todos se ven como el mismo PC$.

Cuando esta limitación — necesitar una identidad propia del servicio de cara a la red, o necesitar la misma identidad en varios servidores — se vuelve un problema, entra en juego gMSA (capítulo 8).

6. La identidad al salir a la red — la práctica de la cuenta de equipo (PC$)

6.1. “El servicio no puede acceder a la carpeta compartida” es un malentendido

En una máquina unida al dominio, cuando un servicio que se ejecuta con LocalSystem, NetworkService o una cuenta virtual accede a un recurso remoto, se autentica como la cuenta de equipo (DOMAIN\nombre_del_equipo$).36 Muchas de las consultas del tipo “no podía acceder a la carpeta compartida, así que lo pasé a un usuario de dominio” mencionadas al inicio en realidad se resuelven con esto: la ACL del destino simplemente no permitía el PC$.

Acceso remoto como cuenta de equipoEn una máquina unida al dominio, los servicios que usan LocalSystem, NetworkService o una cuenta virtual se autentican de forma remota como cuenta de equipo, y acceden si la ACL del destino permite PC$SíNoServicio（LocalSystem, cuenta virtual, etc.）Se autentica como PC$¿La ACL del destino permite PC$?Acceso concedido a la carpeta o la BDAcceso denegado

Figura 10: En un entorno de dominio, basta con otorgar el PC$ en la ACL del destino para lograr acceso remoto sin usuario de dominio.

Otorgar el permiso en el lado del servidor de archivos es la misma operación de ACL de siempre: se indica el nombre de cuenta como nombre_del_equipo$ (en el cuadro de selección de objetos de la GUI, incluya “Equipos” en el tipo de objeto).

# Lado del servidor de archivos: otorga al servicio de APPSV01 permiso de modificación en la carpeta compartida
# Debe otorgarse tanto en los permisos de recurso compartido como en los permisos NTFS
Grant-SmbShareAccess -Name "AppData" -AccountName "CORP\APPSV01$" -AccessRight Change -Force
icacls "D:\Shares\AppData" /grant "CORP\APPSV01$:(OI)(CI)M"

De igual manera, en SQL Server, si crea la cuenta de equipo como inicio de sesión, la cadena de conexión pasa sin contraseña simplemente con Integrated Security=true.

-- Lado del servidor de base de datos: permite la autenticación integrada de Windows desde el servicio de APPSV01
CREATE LOGIN [CORP\APPSV01$] FROM WINDOWS;

6.2. Conozca los límites del método PC$

Este método tiene dos límites.

  1. La granularidad es por máquina. Los servicios que usan LocalSystem, NetworkService y todas las cuentas virtuales en la misma máquina se ven desde el exterior como el mismo PC$. No se puede otorgar “solo a este servicio” en el destino, ni se puede auditar qué servicio usó esa cuenta.2
  2. No funciona en un entorno de grupo de trabajo. La cuenta de equipo es un objeto de Active Directory, así que no existe en una máquina que no está unida al dominio. Hace falta un diseño que maneje explícitamente las credenciales de una cuenta en el destino.

Al querer superar el límite 1, la respuesta de 2026 no es pasar al usuario de dominio del siguiente capítulo, sino saltar directamente ese problema e ir a gMSA.

Los dos límites del método PC$La autenticación con PC$ tiene granularidad por máquina, sin permiso ni auditoría por servicio, y no funciona en un grupo de trabajo porque la cuenta de equipo no existeMétodo PC$Límite 1（granularidad por máquina）Límite 2（no funciona en grupo de trabajo）Sin permiso ni auditoría por servicioHacia un diseño de credenciales explícitasAl querer superarlo, pasar a gMSA

Figura 11: Al querer superar los dos límites de granularidad por máquina y dependencia del dominio, la respuesta es saltar el usuario de dominio e ir directo a gMSA.

7. El problema de usar un usuario de dominio para un servicio

7.1. El problema estructural de la contraseña

Cuando se asigna un usuario de dominio (o un usuario local) a un servicio, el SCM guarda esa contraseña y la usa para iniciar sesión cada vez que arranca. Como el SCM no gestiona el vencimiento, cuando la contraseña vence, el inicio de sesión falla y el servicio deja de poder iniciarse.7

A partir de ahí comienza una espiral negativa muy común en el terreno.

  1. Ocurre un incidente: el servicio se detiene por vencimiento de la contraseña
  2. Como medida preventiva, se configura la contraseña “sin vencimiento”
  3. Sin un procedimiento de cambio bien establecido, la misma contraseña en texto plano se va escribiendo en los procedimientos, scripts y tareas del Programador de tareas de varios servidores
  4. Aunque haya bajas de personal, la contraseña no cambia (porque no se sabe qué se detendría si se cambia)
La espiral negativa de operar con usuarios de dominioEl servicio se detiene al vencer la contraseña, se configura sin vencimiento como medida preventiva, la contraseña en texto plano se difunde por procedimientos y scripts, y aunque se vayan empleados ya no se puede cambiar1. Servicio detenido por vencimiento2. Se configura sin vencimiento3. La contraseña en texto plano se difundeProcedimientos, scripts y tareas4. No se puede cambiar aunque haya bajas

Figura 12: A partir del incidente por vencimiento, la contraseña sin vencimiento y su difusión en texto plano terminan fijándose como norma.

Microsoft también señala que las configuraciones que usan una cuenta de dominio en un servicio requieren un esfuerzo operativo considerable en la gestión manual de la contraseña y del SPN, y que el mantenimiento puede provocar interrupciones del servicio.1

7.2. Kerberoasting — las cuentas de servicio son un objetivo

Hay otro ataque propio de las cuentas de servicio basadas en usuarios de dominio: el Kerberoasting. Un servicio que recibe autenticación Kerberos registra un SPN (nombre principal de servicio) en su cuenta de ejecución. Como cualquier usuario autenticado del dominio puede solicitar un vale de servicio para la cuenta que tiene el SPN registrado, el atacante obtiene ese vale e intenta descifrar la contraseña por fuerza bruta sin conexión. Una contraseña de entre 10 y 16 caracteres decidida por una persona no resiste este ataque.

El flujo del KerberoastingCualquier usuario autenticado del dominio puede solicitar un vale de servicio para una cuenta de servicio con SPN registrado, así que el atacante obtiene el vale e intenta un ataque de fuerza bruta sin conexiónUsuario autenticado del dominioSolicita el vale dirigido al SPNObtiene el vale de servicioFuerza bruta sin conexiónUna contraseña de 10 a 16 caracteres se descifra

Figura 13: Cualquier usuario autenticado puede solicitar el vale, y una contraseña de la longitud que decide una persona no resiste la fuerza bruta sin conexión.

La medida realmente eficaz es hacer que la contraseña sea de una fortaleza que una persona no pueda adivinar ni descifrar. Microsoft también menciona forzar contraseñas largas y usar gMSA, cuya contraseña es un valor aleatorio largo generado por máquina.8 Cabe señalar que el mismo documento también menciona el blindaje de Kerberos (FAST), pero lo que protege FAST es la información de preautenticación y la resistencia a la suplantación del KDC; no impide que un usuario autenticado solicite un vale de servicio para el SPN, así que no sustituye a la fortaleza de la contraseña de la cuenta de servicio. La relación entre SPN y Kerberos, y las condiciones en las que la autenticación “cae” a NTLM, se explican en «NTLM y Kerberos explicados con diagramas».

7.3. Si aun así debe usar un usuario de dominio

Si por motivos como que la aplicación no admite gMSA no le queda otra opción que usar un usuario de dominio, aplique al menos las siguientes mitigaciones.

  • Genere la contraseña de forma aleatoria con 25 caracteres o más, y no la escriba fuera de un gestor de contraseñas (ni en procedimientos, scripts o un Excel compartido)
  • Use una cuenta dedicada exclusivamente al servicio y separada por servicio (no la comparta con la cuenta de una persona2)
  • Deniegue el inicio de sesión interactivo y el Escritorio remoto, permitiendo solo “Iniciar sesión como servicio”
  • Minimice los grupos a los que pertenece (agregarla a Domain Admins queda fuera de toda consideración)
  • Establezca un procedimiento de rotación periódica y lleve un registro de dónde se propaga cada cambio

Migrar a gMSA es más seguro y más cómodo que hacer todo esto, como se ve en el siguiente capítulo.

8. gMSA — delegar la gestión de contraseñas en Active Directory

8.1. Mecanismo y efecto

gMSA (cuenta de servicio administrada de grupo) es una cuenta de dominio que delega la gestión de la contraseña al controlador de dominio. La contraseña la calcula el controlador de dominio a partir de la clave raíz del KDS (Servicio de distribución de claves), y solo los hosts autorizados pueden obtenerla.13

Mecanismo de gestión de contraseñas de gMSAEl controlador de dominio calcula la contraseña a partir de la clave raíz de KDS, solo los hosts autorizados la obtienen para ejecutar el servicio, y de forma predeterminada rota automáticamente cada 30 díasClave raíz de KDSEl DC calcula la contraseñaLos hosts autorizados la obtienenSe usa para ejecutar el servicioRotación automática cada 30 días por defecto

Figura 14: El controlador de dominio se encarga de generar, distribuir y renovar la contraseña, de modo que las personas pueden operar sin conocerla.

El efecto es claro.9

  • Contraseña aleatoria de 240 bytes: la fuerza bruta y los ataques de diccionario dejan de ser viables, y la resistencia al Kerberoasting mejora enormemente
  • Rotación automática cada 30 días por defecto: no hace falta que una persona planifique el cambio ni que se detenga el servicio
  • Se puede compartir la misma identidad entre varios servidores: incluso en una granja de servidores detrás de un balanceo de carga, se puede autenticar mutuamente con el mismo principal
  • Simplifica la gestión de SPN: el registro y la gestión del SPN también se pueden delegar y simplificar

Las personas pueden operar sin conocer la contraseña — se entiende mejor si lo piensa como el mismo mecanismo que Windows LAPS aplica a la contraseña del administrador local, pero llevado a la cuenta de servicio.

8.2. Requisitos

gMSA tiene condiciones previas.10

  • Debe existir un entorno de dominio de Active Directory (no funciona en un grupo de trabajo)
  • El nivel funcional del dominio y del bosque debe ser Windows Server 2012 o superior
  • La clave raíz de KDS debe estar ya creada
  • El nombre del gMSA debe ser único en todo el bosque, no solo en el dominio
  • El intervalo de cambio de contraseña solo se puede configurar en el momento de la creación

Crear la clave raíz de KDS es un trabajo único, pero tras crearla, no se puede crear ningún gMSA durante un máximo de 10 horas, mientras se espera la réplica a todos los controladores de dominio. Es un mecanismo de seguridad para evitar que la obtención de la contraseña falle antes de que termine la réplica.14

De la creación de la clave raíz de KDS a la creación del gMSATras crear la clave raíz de KDS hay que esperar hasta 10 horas a que se replique en todos los controladores de dominio, y solo después de completarse la réplica se puede crear el gMSACrear la clave raíz de KDSEspera de hasta 10 horas de réplicaSalvaguarda contra fallos de obtenciónRéplica completa en todos los DCYa se puede crear el gMSA

Figura 15: Tras crear la clave raíz, las hasta 10 horas de espera evitan un fallo de obtención mientras la réplica aún no ha terminado.

# Ejecutar como administrador de dominio, en un controlador de dominio (o en un
# equipo de administración con el módulo de PowerShell de AD instalado)

# Comprueba si existe la clave raíz de KDS y, si no, la crea (solo una vez por bosque)
Get-KdsRootKey
Add-KdsRootKey -EffectiveImmediately   # Estará realmente disponible hasta 10 horas después

8.3. Procedimiento, de la creación a la configuración

El procedimiento tiene cuatro etapas: “① crear el grupo autorizado a obtenerla → ② crear el gMSA → ③ instalarlo en cada servidor → ④ configurarlo en el servicio”.10

Las cuatro etapas para implantar gMSASe implanta en cuatro etapas: crear el grupo que autoriza la obtención de la contraseña, crear el gMSA, instalarlo en cada servidor y configurarlo como cuenta de ejecución del servicio① Crear el grupo autorizado a obtenerla② Crear el gMSAAgregar el PC$ del servidor③ Instalar en cada servidorVerificar la obtención con Test④ Configurar en el servicio

Figura 16: Desde la creación del grupo hasta la configuración del servicio, la implantación de gMSA avanza en cuatro etapas.

# ① Crea el grupo de seguridad que autoriza la obtención de la contraseña
#    y agrega las cuentas de equipo de los servidores que ejecutarán el servicio
New-ADGroup -Name "GG-SvcBatchHosts" -GroupScope Global
Add-ADGroupMember -Identity "GG-SvcBatchHosts" -Members "APPSV01$", "APPSV02$"
# La pertenencia al grupo se evalúa al iniciar sesión el equipo, así que
# conviene reiniciar los servidores afectados después de agregarlos

# ② Crea el gMSA
New-ADServiceAccount -Name "svc-batch" `
    -DNSHostName "svc-batch.corp.example.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "GG-SvcBatchHosts"

# ③ En cada servidor que ejecutará el servicio, instala y verifica el gMSA
Install-ADServiceAccount -Identity "svc-batch"
Test-ADServiceAccount -Identity "svc-batch"   # Si devuelve True, la obtención funciona

# ④ Configúralo como cuenta de ejecución del servicio. Agrega $ al final del nombre y no especifiques contraseña
sc.exe config MyBatchService obj= "CORP\svc-batch$"
Restart-Service MyBatchService

Si lo configura desde services.msc, indique también el nombre de cuenta con $ al final, por ejemplo CORP\svc-batch$, y deje el campo de contraseña en blanco. Las cuentas de tipo MSA no se pueden usar para inicio de sesión interactivo.1 Después, basta con otorgar CORP\svc-batch$ en la ACL de la carpeta compartida o de SQL Server, en lugar del PC$, para completar el acceso de red con la identidad propia del servicio, sin contraseña.

8.4. Hay aplicaciones que no son compatibles

Como advertencia, no todo el software funciona con gMSA. Los servicios de Windows, los grupos de aplicaciones de IIS y las tareas del Programador de tareas —todo lo que configura la identidad de inicio de sesión mediante el mecanismo estándar— son ampliamente compatibles, pero hay restricciones, como que la conmutación por error (failover clustering) en sí no admite gMSA, y las aplicaciones que exigen contraseña internamente no se pueden usar.10 Microsoft también deja explícito que hay que confirmar el funcionamiento con gMSA en un entorno de prueba antes de llevarlo a producción.9

Cómo determinar si una aplicación admite gMSALas aplicaciones que configuran la identidad de inicio de sesión con el mecanismo estándar suelen admitir gMSA, pero no sirve para la conmutación por error ni para apps que exigen contraseña internamente, y conviene verificarlo en un entorno de prueba antes de producciónMecanismo estándarExige contraseñaAplicación que quiere usar¿Cómo configura el inicio de sesión?Admite gMSAServicios, IIS, tareas, etc.No admite gMSAClúster de conmutación por error, etc.Verificar en prueba antes de producción

Figura 17: Las aplicaciones que configuran el inicio de sesión con el mecanismo estándar suelen ser compatibles, pero también hay casos no compatibles, por lo que la verificación previa a producción es indispensable.

También existen dos parientes: sMSA (cuenta de servicio administrada independiente, para un solo servidor) y dMSA (cuenta de servicio administrada delegada, introducida en Windows Server 2025, que se vincula a la identificación del dispositivo para resistir el robo de credenciales). Al armar algo nuevo, considere gMSA como base y evalúe estas otras según los requisitos.6

9. Diseño asociado — derecho de inicio de sesión, perfil, DPAPI y auditoría

Hay otros cuatro puntos ligados a la cuenta que cambian y que conviene tener presentes.

9.1. El derecho “Iniciar sesión como servicio” (SeServiceLogonRight)

Para iniciarse como servicio, la cuenta necesita el derecho de usuario “Iniciar sesión como servicio”. LocalSystem, LocalService y NetworkService lo tienen de forma integrada, pero cualquier otra cuenta (usuario de dominio, gMSA, etc.) necesita que se le asigne explícitamente.15

Si lo configura desde la pestaña “Iniciar sesión” de la GUI de services.msc, el complemento otorga este derecho automáticamente. En cambio, CreateService/ChangeServiceConfig (la API que invoca sc.exe config) no verifica si la cuenta indicada tiene ese derecho. Esta es la causa típica de que un servicio configurado por script se detenga al iniciar con “Error al iniciar sesión”. No confíe en el efecto secundario de una herramienta: incluya explícitamente en el procedimiento de despliegue agregar la cuenta a “Iniciar sesión como servicio” en la directiva de seguridad local (secpol.msc), o configurarlo mediante GPO/Intune (tenga en cuenta también que, en un entorno donde este derecho se configura por directiva de grupo, el otorgamiento local se sobrescribe al aplicarse la directiva). A la inversa, es habitual configurar también “Denegar el inicio de sesión local” en las cuentas dedicadas a servicios.

Diferencia según la vía de configuración del derecho "Iniciar sesión como servicio"La GUI de services.msc otorga el derecho automáticamente, pero la API que invoca sc.exe config no lo verifica, así que una cuenta sin el derecho hace que el servicio se detenga por fallo de inicio de sesiónSíNoConfigurado con services.mscOtorga el derecho automáticamenteEl servicio puede iniciarseConfigurado con sc.exe configNo verifica el derecho¿Tiene el derecho?El servicio puede iniciarseSe detiene por fallo de inicio de sesiónOtorgarlo explícitamente con secpol.msc o GPO

Figura 18: La GUI otorga el derecho automáticamente, pero la configuración por script no lo verifica, por lo que hay que incluir el otorgamiento explícito en el procedimiento.

9.2. El perfil, %TEMP% y HKEY_CURRENT_USER cambian

El SCM carga el perfil de usuario de la cuenta al iniciar el servicio.7 Es decir, el contenido real de %TEMP%, %APPDATA% y HKEY_CURRENT_USER es distinto para cada cuenta de ejecución, y al cambiar de cuenta, la configuración o la caché que se guardaba en el perfil de la cuenta anterior parece haber “desaparecido”.

La mitigación de diseño es sencilla: colocar los datos del servicio en una ruta explícita, como C:\ProgramData\<nombre_de_la_app>, en lugar de bajo el perfil, y otorgar la ACL de esa ruta a la cuenta de ejecución. Así, cambiar de cuenta deja de requerir migrar datos.

Cómo mitigar la dependencia del perfil en la ubicación de los datosEl perfil real es distinto para cada cuenta de ejecución, así que al cambiar de cuenta los datos del perfil anterior parecen haber desaparecido, pero si los datos se colocan en una ruta explícita y se otorga la ACL a la cuenta, la migración deja de ser necesariaMitigaciónCambio de cuenta de ejecuciónSe carga otro perfilLos datos anteriores parecen desaparecerColocar los datos bajo ProgramDataOtorgar la ACL a la cuenta de ejecuciónYa no hace falta migrar al cambiar de cuenta

Figura 19: Si evita el perfil y coloca los datos en una ruta explícita con su ACL otorgada, el cambio de cuenta deja de implicar una migración de datos.

9.3. Los datos protegidos con DPAPI comparten destino con la cuenta

Un punto que se pasa por alto con más frecuencia es DPAPI. Los datos cifrados con DPAPI de ámbito de usuario (CryptProtectData o ProtectedData de .NET) en principio solo se pueden descifrar con la misma cuenta que los protegió. En el instante en que se cambia de cuenta, deja de poder leerse la cadena de conexión o la clave de API guardadas — es DPAPI haciendo bien su trabajo, pero se convierte en un incidente si no está en el procedimiento de migración.

Relación entre los datos protegidos con DPAPI y el cambio de cuentaLos datos protegidos con DPAPI de ámbito de usuario solo se pueden descifrar con la misma cuenta que los protegió, así que al cambiar la cuenta de ejecución hay que volver a introducir los secretosMisma cuenta anteriorCuenta nuevaProtección con DPAPI en la cuenta anteriorCadena de conexión protegida, etc.¿Con qué cuenta se descifra?Se puede descifrarNo se puede descifrarVolver a introducir el secreto

Figura 20: Los datos protegidos con DPAPI comparten destino con la cuenta que los protegió, y tras un cambio de cuenta hay que volver a introducirlos.

La solución es incluir en el plan de migración el paso de “volver a introducir los secretos después de cambiar de cuenta” (para el diseño de dónde guardarlos, vea «Almacenamiento de información confidencial en aplicaciones de Windows»). Cabe señalar que, si adopta una configuración que se resuelve con autenticación integrada de Windows mediante gMSA o PC$, puede eliminar por completo la necesidad de guardar el secreto. Antes de decidir “dónde guardarlo”, el orden correcto es evaluar “si hace falta guardarlo”.

Además, cuando un servicio necesita realizar un procesamiento “con los privilegios del usuario que lo invocó”, la solución no es fortalecer la cuenta, sino usar la suplantación (impersonation). Para esto, consulte «Cómo manejar correctamente los tokens de suplantación en Windows».

9.4. Auditoría — observe el tipo de inicio de sesión 5 del evento 4624

El inicio de un servicio se registra en el registro de eventos de seguridad como el evento ID 4624 (se inició sesión correctamente en una cuenta) con tipo de inicio de sesión 5 (Service: el SCM inició el servicio). El campo “Cuenta virtual” del evento indica si el inicio de sesión fue de una MSA o cuenta virtual, por lo que también sirve para supervisar el uso de cuentas administradas.11

El flujo de auditoría del inicio de un servicioEl inicio de un servicio por el SCM se registra como el evento 4624 con tipo de inicio de sesión 5, y el campo de cuenta virtual permite identificar si el inicio de sesión fue con una cuenta administradaEl SCM inicia el servicioSe registra el evento ID 4624Tipo de inicio de sesión 5（Service）Campo de cuenta virtualSupervisión de cuentas administradas

Figura 21: El inicio de un servicio se registra como el 4624 con tipo de inicio de sesión 5, y hasta permite rastrear el uso de cuentas administradas.

Para el inventario actual, lo más rápido es agregar las cuentas de ejecución de la lista de servicios.

# Agrupa qué servicios se ejecutan con qué cuenta
Get-CimInstance Win32_Service |
    Group-Object StartName |
    Sort-Object Count -Descending |
    Select-Object Count, Name

# Identifica los servicios no estándar que se ejecutan con LocalSystem (distínguelos por la ruta: propios o de terceros)
Get-CimInstance Win32_Service |
    Where-Object { $_.StartName -eq 'LocalSystem' -and $_.PathName -notlike '*\Windows\*' } |
    Select-Object Name, DisplayName, PathName

Si en esta salida aparecen “servicios de negocio con LocalSystem” o “servicios con usuario de dominio”, es el momento de aplicar el flujo de decisión del siguiente capítulo.

10. Flujo de decisión — decida con cuatro preguntas

Resumamos todo lo anterior como un procedimiento de selección. Responda en orden a estas cuatro preguntas.

Flujo de decisión de la cuenta de ejecuciónSe decide la cuenta de ejecución respondiendo en orden a cuatro preguntas: si hay acceso a la red, si hay unión al dominio, si basta con la identidad por máquina y si la aplicación admite gMSANoSíNoSíSíNoSíNo¿Se conecta a otra máquina con autenticación Windows?Cuenta virtualSi requiere privilegios, LocalSystem¿Unida al dominio?Proteger y guardar las credenciales¿Basta la identidad por máquina?Cuenta virtual + permiso a PC$¿La app admite gMSA?gMSAUsuario dedicado + mitigaciones

Figura 22: Respondiendo en orden a las cuatro preguntas, se determina cuál de las seis opciones usar.

Pregunta 1: ¿El servicio accede con autenticación Windows a otra máquina de la red (carpeta compartida, base de datos, API, etc.)?

Si no accede, la solución por defecto es la cuenta virtual. Solo si se necesita un privilegio local especial, evalúe LocalSystem tras confirmar esa necesidad.

Pregunta 2: (Si accede) ¿la máquina está unida al dominio?

En un grupo de trabajo no se puede usar ni PC$ ni gMSA. Diseñe un manejo explícito de las credenciales de la cuenta del destino (protegiendo su almacenamiento con, por ejemplo, DPAPI), o evalúe unirse al dominio.

Pregunta 3: (En caso de dominio) ¿basta con la identidad por máquina (PC$)?

Si basta, se completa con la cuenta virtual (o NetworkService) + otorgar PC$ en la ACL del destino. Si necesita una identidad propia del servicio, o la misma identidad en varios servidores, pase a la pregunta 4.

Pregunta 4: ¿la aplicación admite gMSA?

Si es compatible (el SCM, los grupos de aplicaciones de IIS, el Programador de tareas y, en general, todo lo que configura el inicio de sesión con el mecanismo estándar lo es), use gMSA. No olvide verificar el funcionamiento en un entorno de prueba. Si definitivamente no es compatible, aplique todas las mitigaciones de la sección 7.3 y use un usuario de dominio dedicado.

En forma de tabla queda así:

Situación Recomendación Notas
Se completa localmente, privilegio normal Cuenta virtual Otorgue la ACL a NT SERVICE\<nombre>
Se completa localmente, requiere privilegio superior a administrador LocalSystem Verifique primero la necesidad de ese privilegio
Procesamiento local que no necesita identidad en red LocalService Aceptable para mantener el estado actual de un servicio existente
Accede a un recurso del dominio con la identidad de la máquina Cuenta virtual (o NetworkService) Otorgue PC$ en la ACL del destino
Accede a un recurso del dominio con la identidad propia del servicio gMSA Clave raíz de KDS + verificación de compatibilidad
Misma identidad en varios servidores (balanceo de carga, etc.) gMSA No es posible con la cuenta virtual
App no compatible con gMSA + necesita identidad propia Usuario de dominio dedicado Las mitigaciones de la sección 7.3 son obligatorias
Grupo de trabajo + necesita acceso remoto Guardar credenciales explícitas de forma protegida Evalúe también revisar el diseño

11. Resumen

  • La cuenta de ejecución de un servicio es una decisión de diseño que fija a la vez el privilegio local, la identidad en red y la gestión de la contraseña. No la deje en su valor predeterminado (LocalSystem).
  • LocalSystem tiene el token de SYSTEM+Administrators y privilegios potentes, así que el daño al comprometerlo se maximiza. La mayoría de los servicios de negocio no necesita ese privilegio.
  • LocalService y NetworkService son ambos de bajo privilegio; la diferencia es la identidad en red (anónima o cuenta de equipo). Sin embargo, comparten la cuenta entre varios servicios, así que no permiten separación.
  • La cuenta virtual (NT SERVICE\) es la solución moderna por defecto: permite separación por servicio sin necesidad de gestionar contraseñas. Se puede indicar directamente en la ACL, y la configuración se limita a cambiar el nombre de la cuenta de inicio de sesión.
  • LocalSystem, NetworkService y la cuenta virtual salen a la red como DOMAIN\PC$ en un entorno de dominio. Otorgar PC$ en la ACL de la carpeta compartida o de SQL Server permite prescindir del usuario de dominio en muchos casos.
  • Usar un usuario de dominio en un servicio arrastra problemas estructurales: interrupciones por vencimiento, difusión de contraseñas en texto plano y Kerberoasting. Si lo usa, son obligatorios una cuenta dedicada, una contraseña larga y aleatoria, y restricciones de inicio de sesión.
  • gMSA es un mecanismo en el que AD genera y rota automáticamente la contraseña; sus requisitos son el dominio, nivel funcional 2012 o superior, y la clave raíz de KDS. En el servicio se configura “DOMAIN\nombre$” con el campo de contraseña vacío.
  • Al cambiar de cuenta, incluya en el procedimiento de migración el derecho “Iniciar sesión como servicio”, el traslado del perfil y de %TEMP%, y la reintroducción de los datos protegidos con DPAPI. La auditoría se puede confirmar con el evento ID 4624 de tipo de inicio de sesión 5.

La próxima vez que instale un servicio, deténgase un momento en la pantalla de configuración de inicio de sesión y pregúntese: ¿como quién debería ejecutarse este servicio, y hasta dónde debería poder acceder? La respuesta debería estar en alguna fila de la tabla de decisión de este artículo.

Artículos relacionados

Áreas de consultoría relacionadas

KomuraSoft LLC atiende el diseño de la cuenta de ejecución y la reducción de privilegios de servicios de Windows y aplicaciones residentes, la migración a cuentas virtuales y gMSA de servicios existentes construidos sobre la base de LocalSystem, y la investigación de fallos de acceso denegado, DPAPI o de perfil derivados de un cambio de cuenta. Puede empezar desde la etapa de “me lo señalaron en una auditoría, pero no sé por dónde empezar”.

Referencias

  1. Microsoft Learn, Configure Windows service accounts and permissions. Sobre que la cuenta de servicio predeterminada de SQL Server es una cuenta virtual (como NT SERVICE\MSSQLSERVER), que al indicar una cuenta virtual o MSA se deja el campo de contraseña vacío, que las MSA tienen el nombre terminado en $ y no se pueden usar para inicio de sesión interactivo, que Local Service es una cuenta compartida que no se puede separar y por eso SQL Server no la admite, que usar una cuenta de dominio implica esfuerzo de gestión manual de contraseña y SPN, con mantenimiento que puede provocar interrupciones del servicio, y que siempre conviene ejecutar el servicio con la cuenta de privilegio mínimo. ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  2. Microsoft Learn, Securing on-premises service accounts. Sobre el orden de prioridad para servicios locales (primero gMSA, si no se puede sMSA, luego la cuenta de equipo y por último la cuenta de usuario), que al usar una cuenta de equipo no se puede determinar qué servicio la usa ni auditar los cambios, y sobre el papel de la cuenta de servicio (identificación, autenticación e inicio del servicio). ↩ ↩2 ↩3

  3. Microsoft Learn, LocalSystem Account. Sobre que LocalSystem tiene privilegios amplios en el equipo local, que su token incluye los SID de NT AUTHORITY\SYSTEM y BUILTIN\Administrators, que no tiene contraseña, que presenta las credenciales del equipo ante un servidor remoto, la lista de privilegios que incluye SE_DEBUG_NAME y SE_TCB_NAME, y que la mayoría de los servicios no necesita este nivel de privilegio y debería considerar LocalService/NetworkService. ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  4. Microsoft Learn, sc.exe config. Sobre que la cuenta de ejecución del servicio se indica con el parámetro obj=, que su valor predeterminado es LocalSystem, y sobre el parámetro password= al usar una cuenta de usuario distinta de LocalSystem. ↩ ↩2

  5. Microsoft Learn, Local accounts. Sobre que SYSTEM (S-1-5-18) tiene control total por defecto en un volumen NTFS, que NETWORK SERVICE (S-1-5-20) presenta las credenciales del equipo ante un servidor remoto, y que LOCAL SERVICE (S-1-5-19) tiene privilegios mínimos en local y presenta credenciales anónimas ante la red. ↩ ↩2 ↩3 ↩4

  6. Microsoft Learn, Service accounts. Sobre que la cuenta virtual es una cuenta local administrada automáticamente que no requiere gestión de contraseña, que su nombre tiene el formato NT SERVICE<SERVICENAME>, que en un entorno de dominio accede a la red con las credenciales de la cuenta de equipo (\$), y sobre los criterios de uso entre sMSA, gMSA, dMSA y la cuenta virtual. ↩ ↩2 ↩3 ↩4

  7. Microsoft Learn, Service User Accounts. Sobre que los servicios se ejecutan en el contexto de seguridad de una cuenta de usuario, que el SCM inicia sesión con la cuenta al arrancar y asocia el token de acceso al proceso del servicio, que el SCM carga el perfil de usuario, y que el SCM no gestiona el vencimiento de la contraseña, por lo que al vencer falla el inicio de sesión y el servicio no arranca. ↩ ↩2 ↩3 ↩4 ↩5

  8. Microsoft Learn, Protect SMB traffic from interception. Sobre gMSA como medida de protección de la cuenta de servicio (que la contraseña aleatoria larga generada por máquina hace inviable descifrarla por fuerza bruta o diccionario), la exigencia de contraseñas largas, y la mención al blindaje de Kerberos (FAST), entre otras recomendaciones. ↩ ↩2

  9. Microsoft Learn, Secure group managed service accounts. Sobre que la contraseña de gMSA es un valor aleatorio de 240 bytes difícil de atacar por fuerza bruta o diccionario, que el sistema operativo Windows la cambia cada 30 días sin que un administrador tenga que planificar el cambio ni detener el servicio, la simplificación del despliegue en granjas de servidores y de la gestión de SPN, que si un servicio no admite gMSA se debe usar sMSA, y si eso tampoco es posible, una cuenta de usuario estándar con una gestión de contraseñas sólida, y que conviene confirmar el funcionamiento con gMSA en un entorno de prueba antes de producción. ↩ ↩2 ↩3

  10. Microsoft Learn, Manage group Managed Service Accounts. Sobre los requisitos previos de gMSA (nivel funcional de dominio/bosque 2012 o superior, creación de la clave raíz de KDS), que el nombre del gMSA debe ser único en todo el bosque, que el intervalo de cambio de contraseña solo se puede configurar en la creación, que -PrincipalsAllowedToRetrieveManagedPassword de New-ADServiceAccount indica el grupo autorizado a obtener la contraseña, el procedimiento de Install-ADServiceAccount/Test-ADServiceAccount, que la identidad de la cuenta virtual es local a la máquina y el dominio no la reconoce, que la conmutación por error no admite gMSA, y que el SCM, los grupos de aplicaciones de IIS y el Programador de tareas admiten configurar el inicio de sesión con gMSA. ↩ ↩2 ↩3 ↩4 ↩5

  11. Microsoft Learn, 4624(S): An account was successfully logged on. Sobre que el evento 4624 se registra en el equipo de acceso al crearse una sesión de inicio de sesión, que el tipo de inicio de sesión 5 significa Service (el SCM inició un servicio), y que el campo “Virtual Account” permite identificar el inicio de sesión de una MSA o cuenta virtual, útil para supervisar cuentas de servicio administradas. ↩ ↩2

  12. Microsoft Learn, About Windows Resource Protection. Sobre que la Protección de recursos de Windows (WRP) evita el reemplazo de archivos, carpetas y claves de registro críticos del sistema, que el acceso total a los recursos protegidos por WRP está limitado a TrustedInstaller, que las modificaciones solo se pueden hacer a través de un mecanismo de reemplazo admitido mediante el servicio Instalador de módulos de Windows, y que las aplicaciones que intentan modificar un recurso protegido reciben acceso denegado. ↩

  13. Microsoft Learn, Group Managed Service Accounts overview. Sobre que gMSA es una cuenta de dominio que delega la gestión de la contraseña a Windows, que el controlador de dominio calcula la contraseña a partir del secreto compartido del Servicio de distribución de claves (kdssvc.dll) y los hosts miembro la consultan al controlador de dominio para obtener la contraseña actual y la anterior, y que permite la autenticación mutua con el mismo principal en una granja de servidores. ↩

  14. Microsoft Learn, Create a Key Distribution Service (KDS) root key. Sobre que el controlador de dominio necesita la clave raíz para empezar a generar contraseñas de gMSA, el procedimiento de creación con Add-KdsRootKey -EffectiveImmediately, que tras la creación no se puede crear ningún gMSA durante un máximo de 10 horas mientras se espera a que converja la réplica de AD, y que la obtención de la contraseña puede fallar si la réplica está incompleta. ↩

  15. Microsoft Learn, Policy CSP - UserRights: LogOnAsService. Sobre que el derecho “Iniciar sesión como servicio” permite a una entidad de seguridad iniciar sesión como servicio, que Local System, Local Service y Network Service lo tienen de forma integrada, que las demás cuentas que ejecutan un servicio necesitan que se les asigne este derecho, y la ruta de configuración por directiva de grupo. ↩

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Debo cambiar de inmediato un servicio que por ahora funciona con LocalSystem?
No siempre es correcto cambiarlo de inmediato y de forma uniforme. Primero compruebe si ese servicio realmente necesita privilegios locales equivalentes a LocalSystem (privilegios fuertes que superan a los de un administrador). Si solo necesita leer y escribir archivos y comunicarse por red, la primera opción es migrarlo a una cuenta virtual (NT SERVICE\nombre_del_servicio). Durante la migración, confirme el otorgamiento de permisos a las carpetas o claves de registro necesarias, cómo se manejan los datos que dependen del perfil o de DPAPI, y si cuenta con el derecho "Iniciar sesión como servicio". Verifique el inicio y las funciones principales en un entorno de prueba antes de aplicar el cambio en producción.
¿Debo elegir la cuenta virtual o NetworkService?
Si va a elegir una cuenta nueva, se recomienda la cuenta virtual. Ambas se ven en la red como la cuenta de equipo (DOMAIN\nombre_del_equipo$) y también se parecen en tener privilegios locales reducidos. Sin embargo, NetworkService es compartida por varios servicios, por lo que en la ACL no se puede lograr "autorizar solo a este servicio". La cuenta virtual tiene una identidad propia por servicio y se puede indicar directamente NT SERVICE\nombre_del_servicio en la ACL. Productos recientes de Microsoft, como SQL Server, también usan la cuenta virtual como valor predeterminado.
¿Se puede usar gMSA en un entorno de grupo de trabajo (sin dominio)?
No se puede usar. gMSA es un mecanismo en el que el controlador de dominio de Active Directory genera y gestiona la contraseña, y presupone la existencia de un dominio y de la clave raíz de KDS. En un entorno de grupo de trabajo, lo básico es completar el procesamiento local con una cuenta virtual o con LocalService/NetworkService. Si se necesita acceder a otra máquina, hay que recurrir a otro diseño, como usar explícitamente las credenciales de una cuenta preparada en el destino. El acceso de red como cuenta de equipo (PC$) también solo funciona en un entorno de dominio.
Al cambiar la cuenta de ejecución del servicio, ya no puedo leer la configuración ni las credenciales que tenía guardadas. ¿Por qué?
Porque cada cuenta de ejecución tiene asociado su propio perfil de usuario, %TEMP%, HKEY_CURRENT_USER y claves DPAPI. En particular, los datos protegidos con DPAPI de ámbito de usuario (CryptProtectData, etc.) en principio solo se pueden descifrar con la misma cuenta que los protegió. Además, los archivos guardados bajo el perfil (AppData, etc.) quedan en otra ruta desde la cuenta nueva. Antes de cambiar de cuenta, planifique el procedimiento para volver a generar los datos protegidos con DPAPI (por ejemplo, reintroducir claves de API) y la migración de los archivos del perfil.
Si solo quiero que el servicio acceda a una carpeta compartida, ¿necesito un usuario de dominio?
En la mayoría de los casos no es necesario. En un entorno de dominio, los servicios que se ejecutan con LocalSystem, NetworkService o una cuenta virtual se autentican de forma remota como cuenta de equipo (DOMAIN\nombre_del_equipo$). Basta con agregar ese PC$ a los permisos de recurso compartido y a los permisos NTFS de la carpeta compartida para leer y escribir. Si necesita controlar el acceso con la identidad propia del servicio, o si varios servidores necesitan la misma identidad, considere gMSA en lugar de un usuario de dominio.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.

Contactar
Volver al blog