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

«Un servicio que funciona con LocalSystem recibió en la auditoría la observación de privilegios excesivos. ¿A qué debería cambiarlo?» «Usamos un usuario de dominio para conectar a una carpeta compartida, pero el servicio se detiene cuando vence la contraseña» — estas dos son las consultas típicas que aparecen cuando la cuenta de ejecución del servicio no es una decisión de diseño, sino que ha quedado fijada como «la configuración que funcionó».

Al elegir la cuenta de ejecución, conviene pensar por separado qué puede hacer el servicio dentro del PC, quién lo ve desde el destino al que se conecta y quién gestiona la contraseña. Reforzar los privilegios locales y poder autenticarse y conectar a una carpeta compartida no son lo mismo.¹²

La conclusión de este artículo es tomar como primera opción una cuenta virtual para un servicio de negocio que se completa dentro de una sola máquina, y gMSA cuando hace falta una identidad propia del servicio dentro del dominio. La base es una configuración en la que «el servicio no lleva una contraseña de tipo humano», y el usuario de dominio queda como último recurso. Eso no significa cambiar de inmediato todos los servicios existentes: compruebe los privilegios necesarios y el impacto de la migración.³⁴

El público son responsables de sistemas de pequeñas y medianas empresas y desarrolladores de aplicaciones de Windows. La explicación, basada en Microsoft Learn en agosto de 2026, fecha del artículo original, se organiza en el orden selección → privilegios locales → identidad en red → implantación de gMSA → cambio y auditoría. Para cómo construir el servicio en sí, véase «Cómo crear y operar un servicio de Windows».

1. Primero elegir: seis cuentas y cuatro preguntas

1.1 Los ejes de comparación son privilegios, identidad y gestión de contraseñas

Al arrancar el servicio, el Administrador de control de servicios (SCM) inicia sesión con la cuenta configurada. Si tiene éxito, asigna un token de acceso al proceso del servicio y, a partir de ahí, cada acceso a archivos o canalizaciones se decide cotejando ese token con la lista de control de acceso (ACL). Elegir la cuenta de ejecución es decidir el contenido del token que se entrega al servicio.¹

La autenticación de red como PC$ de la tabla presupone un entorno de dominio. En un grupo de trabajo el mismo método no está disponible. LocalSystem también tiene límites, como las áreas protegidas por WRP. No tome «casi ilimitados» como ilimitados en sentido literal.⁵⁶²⁷

Con LocalSystem, LocalService, NetworkService y las cuentas virtuales, el usuario no tiene que establecer ni gestionar una contraseña para el servicio. En una configuración que usa un usuario de dominio o un usuario local, en cambio, una persona gestiona el vencimiento y los cambios de la contraseña guardada en el SCM. gMSA sí tiene contraseña, pero su gestión se deja en manos de AD.¹⁸

1.2 Avance la selección con cuatro preguntas

Confirme primero si el servicio se conecta a otras máquinas con autenticación de Windows y, si es así, decida en este orden si el equipo está unido a un dominio, si basta una identidad por máquina y si la aplicación admite gMSA.

flowchart TB
    accTitle: Flujo de decisión de la cuenta de ejecución
    accDescr: Decidir la cuenta de ejecución respondiendo en orden a cuatro preguntas: si hay acceso de red, si el equipo está unido a un dominio, si basta una identidad por máquina y si la aplicación admite gMSA
    q1{"¿Conecta a otras máquinas con autenticación de Windows?"} -->|No| va["Cuenta virtual"]
    va -.-> sys["LocalSystem si hacen falta privilegios"]
    q1 -->|Sí| q2{"¿Unido a un dominio?"}
    q2 -->|No| cred["Proteger y guardar las credenciales"]
    q2 -->|Sí| q3{"¿Basta la identidad por máquina?"}
    q3 -->|Sí| pcacl["Cuenta virtual + permiso a PC$"]
    q3 -->|No| q4{"¿La aplicación admite gMSA?"}
    q4 -->|Sí| gmsa["gMSA"]
    q4 -->|No| du["Usuario dedicado + mitigaciones"]

Figura 1: Si todo queda en local, use una cuenta virtual. Dentro del dominio, si PC$ no da la granularidad suficiente, pase a gMSA. En un grupo de trabajo, diseñe las credenciales por separado.

No hace falta sustituir sin motivo todo el procesamiento local existente con LocalService, ni todo el acceso por máquina con NetworkService. Al elegir de nuevo, tome como base la cuenta virtual, que combina privilegios bajos y aislamiento por servicio.

En el diagrama, una línea continua marca una relación que siempre se cumple y una línea discontinua una relación condicional (las condiciones están en la explicación de cada relación en la página de detalle). La lista completa de relaciones (19 en total, con evidencia y grado de certeza) y las definiciones de los conceptos principales están reunidas en la página de detalle del mapa de conocimiento (en japonés). Datos: JSON-LD / Turtle

2. Decidir los privilegios dentro del PC: tomar la cuenta virtual como base

2.1 LocalService y NetworkService se diferencian en la identidad en red

LocalService y NetworkService son cuentas integradas para servicios de bajo privilegio. En local, ambas se ejecutan con privilegios mínimos, más o menos equivalentes a un miembro del grupo Users. Lo que cambia es la credencial que presentan en remoto.⁶³

La distinción es: LocalService si el servicio no sale a la red o no se le pide una identidad, y NetworkService si necesita la identidad de la máquina dentro del dominio.

Tenga en cuenta, no obstante, que en ambos casos varios servicios comparten la misma cuenta. Mientras las ACL se concedan a esa cuenta compartida, no se puede distinguir un servicio de otro. Si cinco servicios se ejecutan con LocalService, los cinco pueden acceder a cualquier recurso permitido a esa cuenta. La razón por la que SQL Server no admite Local Service es la misma: una cuenta compartida no se puede aislar de otros servicios.³

2.2 Con una cuenta virtual se pueden conceder ACL por servicio

La cuenta virtual es una cuenta local administrada disponible desde Windows Server 2008 R2 / Windows 7. Su nombre es NT SERVICE\<nombre_del_servicio>. No hace falta crear la cuenta ni establecer una contraseña, y cada servicio tiene una identidad propia. Para el acceso de red en un entorno de dominio usa las credenciales de la cuenta de equipo.²

Conserva la ventaja de LocalService y NetworkService —«no hay que gestionar contraseñas»— y elimina la debilidad de compartir la cuenta. Que el programa de instalación de SQL Server use de forma predeterminada NT SERVICE\MSSQLSERVER y similares sigue este mismo planteamiento.³

La ventaja práctica es que el servicio se puede indicar de forma directa en una ACL. Sin añadir creación de grupos ni gestión de contraseñas, se puede configurar «conceder a este servicio el permiso de modificación sobre esta carpeta de datos».

El ejemplo siguiente cambia un MyAppService existente a una cuenta virtual. Antes de ejecutarlo, compruebe el derecho de inicio de sesión, la ubicación de los datos y DPAPI del capítulo 7, y verifique el arranque y las funciones principales en un entorno de prueba.

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

# Comprobar la configuración (revise SERVICE_START_NAME)
sc.exe qc MyAppService

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

En la interfaz gráfica, abra las propiedades del servicio en services.msc, vaya a la pestaña «Iniciar sesión», ponga el nombre de cuenta NT SERVICE\nombre_del_servicio y deje los campos de contraseña vacíos. En las cuentas virtuales y las MSA no se especifica contraseña. El cambio se aplica al reiniciar el servicio.³

Tener una identidad propia en local no garantiza que los servicios se puedan distinguir al otro lado de la red. El capítulo 3 explica esta limitación.

2.3 Juzgue LocalSystem por los privilegios necesarios, no porque «funciona»

LocalSystem (NT AUTHORITY\SYSTEM, el nombre mostrado es Sistema local) es una cuenta predefinida que usa el SCM. El token incluye los SID NT AUTHORITY\SYSTEM y BUILTIN\Administrators, y tiene privilegios locales amplios. Privilegios fuertes como SeDebugPrivilege y SeTcbPrivilege también están habilitados de forma predeterminada.⁵

Esa fortaleza es también el tamaño del daño si se ve comprometida. Si un servicio LocalSystem tiene una vulnerabilidad de ejecución de código arbitrario, puede convertirse en el punto de partida para leer y alterar los archivos de todos los usuarios, leer la memoria de otros procesos, robar credenciales y el movimiento lateral. En NTFS, SYSTEM tiene Control total de forma predeterminada.⁶ La relación entre el robo de credenciales y el movimiento lateral también se trata en «NTLM y Kerberos explicados con diagramas» y «Guía práctica de Windows LAPS».

Aun así, LocalSystem sigue eligiéndose porque es el valor predeterminado de sc.exe create cuando se omite obj=, y porque queda en muchos ejemplos antiguos y plantillas de instaladores. Durante el desarrollo es difícil tropezar con errores de privilegios, y resulta fácil dejarlo en «funcionó, así que se queda». Microsoft también indica que la mayoría de los servicios no necesitan este nivel de privilegios y que, si no hace falta, conviene considerar LocalService o NetworkService.⁹⁵

Ni siquiera LocalSystem puede cambiarlo todo de forma incondicional. A partir de Windows Vista, la Protección de recursos de Windows (WRP) restringe los cambios de archivos, carpetas y claves del Registro del sistema importantes a TrustedInstaller (el servicio Windows Modules Installer). Ni SYSTEM ni un administrador pueden reescribirlos por la vía habitual: reciben un acceso denegado. El mensaje «Se necesitan permisos de TrustedInstaller» es este mecanismo.⁷

Esa restricción no cambia que, para un servicio de negocio, LocalSystem sigue siendo un privilegio excesivo. Las excepciones razonables son el acoplamiento estrecho con controladores de dispositivo, la operación de la base de seguridad del SO, o la gestión de otros servicios y sesiones: procesos cuyos privilegios exigidos superan de entrada los de un administrador. En un agente de copia de seguridad o un EDR, esa necesidad se convierte en un problema.

Aunque el servicio entre en una excepción, compruebe si hay una ruta de código que use de verdad el privilegio, y si esa parte se puede aislar. Para cómo distinguirlo, véase «Cuándo se necesita el privilegio de administrador en Windows».

3. Decidir la identidad que ve el destino: ¿basta PC$?

3.1 Si solo hace falta conectar a una carpeta compartida, a menudo no hace falta un usuario de dominio

En una máquina unida al dominio, un servicio que usa LocalSystem, NetworkService o una cuenta virtual se autentica en remoto como DOMAIN\nombre_del_equipo$. Que el servicio no pueda acceder a una carpeta compartida a veces se reduce a que la ACL del destino no permite a ese PC$.⁵²

Lo que hace falta aquí no es reforzar los privilegios locales del servicio, sino permitir en el destino la identidad correcta. En una carpeta compartida hay que configurar tanto los permisos de recurso compartido como los permisos NTFS.

El ejemplo siguiente, en el servidor de archivos, concede el permiso de modificación al servicio que se ejecuta en APPSV01. Si elige la cuenta en la interfaz gráfica, incluya «Equipos» en «Tipos de objeto».

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

En SQL Server, la idea de registrar la cuenta de equipo como inicio de sesión de Windows es la misma. Use Integrated Security=true en la cadena de conexión y conecte sin que el servicio lleve la contraseña de un usuario de dominio.

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

Esto es un ejemplo de la parte en la que el servidor de base de datos crea el inicio de sesión de Windows. El principio —conceder en el destino los permisos necesarios— no cambia respecto a la carpeta compartida.

3.2 Con PC$ no se puede autorizar ni auditar por servicio

La identidad de una cuenta virtual es local a la máquina y el dominio no la reconoce. Al salir a la red se agrupa en PC$, de modo que solo con la cuenta no se puede distinguir de qué servicio de la misma máquina proviene el acceso.¹⁰⁴

flowchart TB
    accTitle: La identidad de la cuenta virtual se reduce fuera de la máquina
    accDescr: Aunque dentro de la máquina cada servicio tenga una cuenta virtual propia, en la red se reduce a la cuenta de equipo, y el lado remoto no puede distinguir de qué servicio se trata
    vaa["Cuenta virtual A"] --> pc["Cuenta de equipo PC$"]
    vab["Cuenta virtual B"] --> pc
    pc --> remote["Identidad que ve el lado remoto"]
    remote -.-> nodist["No se puede distinguir qué servicio es"]

Figura 2: Aunque dentro del PC se puedan separar los servicios, el destino ve el mismo PC$. El aislamiento local y el aislamiento en red son decisiones distintas.

Este enfoque tiene dos límites.

Compartir la misma identidad en varios servidores también queda fuera de lo que pueden dar un PC$ distinto por máquina o una cuenta virtual. Cuando dentro del dominio hace falta una identidad propia del servicio, o una identidad común a varios servidores, considere gMSA antes que un usuario de dominio: esa es la política de este artículo. gMSA tampoco se puede usar en un grupo de trabajo.

4. El papel de gMSA: una identidad propia y la gestión de la contraseña en manos de AD

4.1 Separar de las personas la generación, la distribución y la renovación de la contraseña

gMSA (group Managed Service Account, cuenta de servicio administrada de grupo) es una cuenta de dominio cuya gestión de contraseña se deja en los controladores de dominio. El controlador de dominio calcula la contraseña a partir de la clave raíz de KDS (Key Distribution Service, servicio de distribución de claves), y solo los hosts permitidos la obtienen y la usan para el servicio.⁸

flowchart TB
    accTitle: Cómo gestiona gMSA la contraseña
    accDescr: El controlador de dominio calcula la contraseña a partir de la clave raíz de KDS, solo los hosts permitidos la obtienen y la usan para ejecutar el servicio, y la contraseña rota de forma automática cada 30 días de forma predeterminada
    kds["Clave raíz de KDS"] --> dc["El DC calcula la contraseña"]
    dc --> host["El host permitido la obtiene"]
    host --> svc["Se usa para ejecutar el servicio"]
    dc -.-> rot["Rotación automática cada 30 días de forma predeterminada"]

Figura 3: Sin que ninguna persona conozca la contraseña, los hosts permitidos la obtienen y el servicio se opera con credenciales que se renuevan de forma automática.

Estas son las razones para preferir gMSA a un usuario de dominio gestionado a mano.¹¹ Windows LAPS automatiza la gestión de las contraseñas de administrador local; gMSA se ocupa de las contraseñas de las cuentas de servicio. Verlo así ayuda a situar cada mecanismo. Ambos resuelven problemas distintos.

4.2 No omita la comprobación de si la aplicación lo admite

gMSA es compatible de forma amplia con lo que configura la identidad de inicio de sesión mediante los mecanismos estándar: servicios de Windows, grupos de aplicaciones de IIS, el Programador de tareas, etc. Pero no todas las aplicaciones pueden usarlo. Un diseño que pide la contraseña internamente no sirve, y hay restricciones como que la propia agrupación en clúster de conmutación por error no admite gMSA.¹⁰

Si gMSA es candidato, confirme en un entorno de prueba, antes de pasarlo a producción, que «arranca con gMSA» y que «puede acceder a los recursos necesarios». Microsoft también exige este paso.¹¹

Entre las opciones relacionadas están sMSA (standalone Managed Service Account, cuenta de servicio administrada independiente) para un solo servidor, y dMSA (delegated Managed Service Account, cuenta de servicio administrada delegada), introducida en Windows Server 2025. dMSA vincula la autenticación a la identificación del dispositivo para oponerse al robo de credenciales. En una configuración nueva, tome gMSA como base y considere también estas según los requisitos.²

5. Implantar gMSA: de la comprobación de requisitos a la configuración del servicio

5.1 Requisitos que hay que confirmar primero

El nombre de gMSA y el intervalo de cambio también se deciden antes de la implantación. Pensarlos después de crear la cuenta implica volver a crearla.¹⁰

5.2 Compruebe la clave raíz de KDS y, si no existe, créela

Crear la clave raíz de KDS es un trabajo de una sola vez por bosque. Compruebe primero si ya hay una clave y añádala solo si no existe.

# 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)

# Comprobar si existe la clave raíz de KDS y, si no, crearla (una sola vez por bosque)
Get-KdsRootKey
Add-KdsRootKey -EffectiveImmediately   # En la práctica se puede usar hasta 10 horas después

Aunque especifique -EffectiveImmediately, no está garantizado que se pueda usar justo después de crearla. Hay que esperar a la replicación a todos los controladores de dominio, de modo que tras la creación hay un tiempo de espera de hasta 10 horas, y en ese intervalo no se puede crear un gMSA. Así se evitan fallos al pasar a obtener la contraseña con la replicación incompleta. Incluya este tiempo en el plan de implantación.¹²

5.3 Restrinja los hosts autorizados a obtener la contraseña y configure el gMSA

El procedimiento tiene cuatro etapas. La primera mitad es configuración del lado de AD; la segunda, trabajo en cada servidor que ejecuta el servicio.¹⁰

Antes de ejecutar el ejemplo siguiente, configure también el derecho «Iniciar sesión como servicio» de 7.1. Que sc.exe config tenga éxito y que el servicio pueda iniciar sesión son dos cosas distintas.

# 1. Crear un grupo de seguridad autorizado a obtener la contraseña
#    y añadir las cuentas de equipo de los servidores que ejecutan el servicio
New-ADGroup -Name "GG-SvcBatchHosts" -GroupScope Global
Add-ADGroupMember -Identity "GG-SvcBatchHosts" -Members "APPSV01$", "APPSV02$"
# La pertenencia al grupo se evalúa cuando el equipo inicia sesión,
# así que lo más seguro es reiniciar los servidores de destino después de añadirlos

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

# 3. En cada servidor que ejecuta el servicio, instalar y verificar el gMSA
Install-ADServiceAccount -Identity "svc-batch"
Test-ADServiceAccount -Identity "svc-batch"   # True significa que se puede obtener la contraseña

# 4. Configurarlo como cuenta de ejecución del servicio. Añada $ al final del nombre
#    y no especifique una contraseña
sc.exe config MyBatchService obj= "CORP\svc-batch$"
Restart-Service MyBatchService

También en services.msc, el nombre de cuenta se indica con $ al final, como CORP\svc-batch$, y los campos de contraseña se dejan vacíos. Las cuentas de tipo MSA no se pueden usar para un inicio de sesión interactivo.³

En la carpeta compartida o en SQL Server de destino, conceda los permisos necesarios a CORP\svc-batch$ en lugar de a PC$. Así se obtiene una configuración en la que nadie gestiona la contraseña y el servicio accede a la red con una identidad propia. No se detenga en la comprobación de obtención con Test-ADServiceAccount; verifique también las funciones principales del servicio de verdad.

6. El usuario de dominio es el último recurso: si lo usa, reúna las mitigaciones

6.1 Evitar el vencimiento fija otro riesgo

Si asigna al servicio un usuario de dominio o un usuario local, el SCM guarda la contraseña y la usa para iniciar sesión en cada arranque. El SCM, sin embargo, no gestiona el vencimiento. Si la contraseña guardada vence, el inicio de sesión falla y el servicio deja de arrancar.¹

De ahí nace un círculo vicioso: para evitar el incidente de vencimiento se pasa a «nunca expira», la misma contraseña queda en texto plano en procedimientos, scripts y tareas de varios servidores y, al final, «no se sabe qué se detendrá si se cambia», de modo que ni cuando alguien deja la empresa se puede cambiar.

Microsoft también señala que, en una configuración que usa una cuenta de dominio para un servicio, la gestión manual de la contraseña y del SPN consume esfuerzo operativo, y que el mantenimiento puede provocar una detención del servicio. Pasar la contraseña a «nunca expira» no resuelve por sí solo el problema de gestión.³

6.2 Una cuenta con SPN también es un objetivo de Kerberoasting

Un servicio que recibe autenticación Kerberos registra un SPN (Service Principal Name, nombre de entidad de seguridad de servicio) en la cuenta de ejecución. Cualquier usuario autenticado del dominio puede pedir el ticket de servicio, de modo que el atacante obtiene el ticket y prueba la contraseña fuera de línea por fuerza bruta: eso es Kerberoasting.

En lugar de confiar en una contraseña de unos 10 a 16 caracteres elegida por una persona, la medida es usar una contraseña larga generada al azar. Microsoft también cita la imposición de contraseñas largas y gMSA, que usa un valor aleatorio largo generado por máquina.¹³

El armoring de Kerberos (FAST) que menciona el mismo documento protege los datos de autenticación previa y da resistencia a la suplantación del KDC. No impide que un usuario autenticado pida un ticket de servicio para un SPN, y no sustituye la fortaleza de la contraseña de la cuenta de servicio. Para el SPN, Kerberos y las condiciones en las que la autenticación pasa a NTLM, véase «NTLM y Kerberos explicados con diagramas».

6.3 Si la aplicación no lo admite, combine una cuenta dedicada con la operación

Si, por ejemplo porque la aplicación no admite gMSA, no queda más remedio que usar un usuario de dominio dedicado, aplique todas las mitigaciones siguientes.

Separar la identidad del servicio de las cuentas de personas también es un principio importante.⁴ Seguir gestionando esto a mano es más costoso y menos seguro que pasar los servicios compatibles a gMSA: esa es la razón para priorizar gMSA.

7. Cambio y auditoría: no termina con cambiar el nombre de la cuenta

7.1 Compruebe el derecho «Iniciar sesión como servicio»

Para arrancar como servicio, la cuenta necesita SeServiceLogonRight (Iniciar sesión como servicio). LocalSystem, LocalService y NetworkService lo tienen de forma integrada, pero si el servicio se ejecuta con cualquier otra cuenta hay que comprobar la asignación de este derecho.¹⁴

Deje escrito en el procedimiento de implementación cómo se configura el derecho con la Directiva de seguridad local (secpol.msc), GPO o Intune. No conviene depender de los efectos secundarios de las herramientas. En una cuenta dedicada al servicio, combine también la denegación del inicio de sesión interactivo.

7.2 Compruebe los datos bajo el perfil y las ACL

Al arrancar el servicio, el SCM carga el perfil de usuario de esa cuenta. Por tanto, %TEMP%, %APPDATA% y HKEY_CURRENT_USER tienen una entidad distinta en cada cuenta. Que tras el cambio la configuración o la caché «hayan desaparecido» se debe a que se está leyendo un perfil distinto del de la cuenta anterior.¹

La medida es colocar los datos del servicio en una ruta explícita como C:\ProgramData\<nombre_de_la_aplicación> y conceder la ACL a la cuenta de ejecución. Si se despega del perfil de cada cuenta, el siguiente cambio de cuenta no obliga a volver a mover el destino de almacenamiento. Si ya hay datos bajo el perfil, incluya la migración en el plan de cambio.

Compruebe no solo las carpetas necesarias, sino también los permisos del Registro y similares. Tras bajar la cuenta a un privilegio menor, verifique que no fallen procesos que daban por sentados los privilegios anteriores de LocalSystem.

7.3 Los datos protegidos con DPAPI no se heredan solo con mover archivos

Los datos protegidos con DPAPI de ámbito de usuario (CryptProtectData, ProtectedData de .NET, etc.) en principio solo se pueden descifrar con la misma cuenta que los protegió. Si cambia la cuenta de ejecución, las cadenas de conexión y las claves de API ya guardadas dejan de poder leerse.

Por eso, aparte de migrar los archivos del perfil, prepare un procedimiento para volver a introducir los secretos después del cambio. Aunque DPAPI esté protegiendo los datos de forma correcta, sin esa preparación se convierte en un fallo del servicio. Para el diseño del destino de almacenamiento, véase «Almacenamiento de información confidencial en aplicaciones Windows».

Si la conexión se resuelve con autenticación integrada de Windows mediante gMSA o PC$, se puede eliminar por completo el almacenamiento de secretos. El orden es pensar primero si se puede no guardar, y después dónde guardar.

Además, si quiere «procesar con los privilegios del usuario que llama», no refuerce la cuenta de ejecución del servicio: considere la suplantación (impersonation). Lo explica «Cómo manejar correctamente los tokens de suplantación de Windows».

7.4 Haga inventario con la lista de servicios y confirme la identidad de arranque en el registro

Para el primer inventario, agregue las cuentas de ejecución de la lista de servicios. El ejemplo siguiente comprueba el recuento por cuenta y los servicios LocalSystem cuya ruta está fuera de la carpeta de Windows.

# Agregar con qué cuenta se ejecuta cada servicio
Get-CimInstance Win32_Service |
    Group-Object StartName |
    Sort-Object Count -Descending |
    Select-Object Count, Name

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

Si un servicio de negocio se ejecuta con LocalSystem o con un usuario de dominio, vuelva a la decisión del capítulo 1 y compruebe los privilegios necesarios y la identidad que hace falta en el destino. Use la extracción por ruta como pista para encontrar candidatos, y decida según el uso real del servicio y lo que procesa.

El arranque del servicio se puede confirmar en el registro de eventos de seguridad con el evento 4624, tipo de inicio de sesión 5 (Service). Representa el inicio de sesión del SCM al arrancar el servicio. El campo «Virtual Account» indica si el inicio de sesión es de una MSA o de una cuenta virtual, y también sirve para vigilar el uso de cuentas administradas.¹⁵

7.5 Resuma las comprobaciones antes del cambio en producción

Tanto si se sale de LocalSystem como si se introduce gMSA, cambie la producción cuando estas comprobaciones hayan terminado. El punto de la migración es verificar juntas la reducción a privilegio mínimo y que las funciones necesarias siguen funcionando.

8. Resumen

Al elegir la cuenta de servicio, piense por separado privilegios locales, identidad en red y gestión de contraseñas. Que LocalSystem sea el valor predeterminado no es una razón para usarlo. Tome como base la cuenta virtual para un servicio de negocio habitual y concédale las ACL necesarias. Considere LocalSystem solo cuando realmente hagan falta privilegios fuertes.⁵³

Si en el destino dentro del dominio basta una identidad por máquina, a veces alcanza con una cuenta virtual u otra similar y un permiso a PC$. Si hace falta una identidad propia del servicio, o una identidad común en varios servidores, elija gMSA y deje la gestión de la contraseña en AD. En un grupo de trabajo no se pueden usar ni PC$ ni gMSA, y hace falta otro diseño que trate las credenciales.²¹⁰

Si hace falta un usuario de dominio, reúna una cuenta dedicada, una contraseña larga aleatoria, restricciones de inicio de sesión, privilegio mínimo, rotación y un registro. En el cambio, no se detenga en el nombre de la cuenta: compruebe también el derecho de inicio de sesión, el perfil y DPAPI.

La pregunta al configurar el siguiente servicio es «como quién, y hasta dónde, debería poder acceder este servicio». Elija la cuenta según esa respuesta, y no la deje fijada como «la configuración que funcionó».

Artículos relacionados

• Cómo crear y operar un servicio de Windows — de la diferencia con el Programador de tareas a la creación de servicios con BackgroundService
• Cuándo se necesita el privilegio de administrador en Windows - UAC, áreas protegidas y cómo distinguirlo por diseño
• Cómo manejar correctamente los tokens de suplantación de Windows — préstamo de privilegios por hilo y una forma segura de revertirlos
• NTLM y Kerberos explicados con diagramas — por qué la autenticación «cae» a NTLM
• Guía práctica de Windows LAPS — abandone la contraseña de administrador local común a todos los PC
• Almacenamiento de información confidencial en aplicaciones Windows - Cómo evitar la configuración en texto plano con DPAPI

Áreas de consultoría relacionadas

KomuraSoft LLC se ocupa del diseño de la cuenta de ejecución y de la reducción a privilegio mínimo de servicios de Windows y aplicaciones residentes, de la migración a cuentas virtuales o gMSA de servicios existentes pensados para LocalSystem, y de la investigación de fallos de acceso denegado, DPAPI y perfil que aparecen al cambiar de cuenta. Puede consultar ya en la fase «la auditoría lo señaló, pero no sabemos por dónde empezar».

• Desarrollo de aplicaciones para Windows
• Investigación de errores y análisis de causa raíz
• Consultoría técnica y revisión de diseño
• Contacto

Referencias

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?

Un cambio inmediato y uniforme no es siempre la respuesta correcta. Primero compruebe si ese servicio realmente necesita privilegios locales equivalentes a LocalSystem (privilegios fuertes que superan a los de un administrador). Si solo lee y escribe archivos y se comunica por red, la primera opción es pasarlo a una cuenta virtual (NT SERVICE\servicio). Durante la migración, confirme la concesión de permisos a las carpetas y claves del Registro necesarias, el tratamiento de los datos que dependen del perfil o de DPAPI, y si existe el derecho «Iniciar sesión como servicio». Verifique el arranque y las funciones principales en un entorno de prueba y, después, cambie la producción.

¿Debo elegir la cuenta virtual o NetworkService?

Si va a elegir una cuenta nueva, se recomienda la cuenta virtual. En la red ambas se ven como la cuenta de equipo (DOMAIN\equipo$) y también se parecen en que los privilegios locales son reducidos. Sin embargo, NetworkService es compartida por varios servicios, de modo que una ACL no puede expresar «permitir solo a este servicio». La cuenta virtual tiene una identidad propia por servicio y se puede indicar directamente NT SERVICE\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. gMSA es un mecanismo en el que el controlador de dominio de Active Directory genera y gestiona la contraseña, y presupone un dominio y la creación de la clave raíz de KDS. En un grupo de trabajo, lo básico es completar el procesamiento local con una cuenta virtual o con LocalService/NetworkService. Si hace falta acceder a otra máquina, se necesita otro diseño, por ejemplo usar de forma explícita 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 y similares) en principio solo se pueden descifrar con la misma cuenta que los protegió. Además, los archivos guardados bajo el perfil (AppData y similares) 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 muchos casos no. 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\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.