Hardening de controladores de dominio y GPO

Aviso ético y legal: los procedimientos de hardening, las herramientas (Microsoft Security Compliance Toolkit, LGPO.exe, Policy Analyzer, CIS-CAT) y los comandos de este módulo deben aplicarse exclusivamente sobre DCs de laboratorio propios o sobre infraestructura de producción con autorización expresa y por escrito del responsable del sistema. Modificar la Default Domain Policy, la Default Domain Controllers Policy o cualquier GPO enlazada a la OU de Domain Controllers sin autorización, o sin probarlo antes en un entorno de test, puede provocar una interrupción total del servicio de autenticación (todo el dominio deja de validar logons) y constituye una posible infracción grave de las políticas internas de TI. Contenido exclusivamente educativo dentro de un laboratorio Active Directory desechable (Hyper-V, VMware o VirtualBox).

Qué aprenderás

Este módulo cierra el bloque de fundamentos de seguridad de Active Directory centrándose en el objeto que, si cae, compromete todo el dominio: el controlador de dominio (DC). No es una lista de «buenas prácticas» genéricas, sino un procedimiento reproducible de hardening basado en las líneas base oficiales de Microsoft y en los CIS Benchmarks. Al terminar serás capaz de:

Descargar, entender e importar una Security Baseline de Microsoft (Security Compliance Toolkit) para la versión de Windows Server de tus DCs, de 2012 R2 a 2022/2025.
Usar LGPO.exe para aplicar, exportar y auditar GPO local y de dominio desde línea de comandos, sin depender de la consola gráfica.
Usar Policy Analyzer para comparar tu configuración contra la baseline y detectar desviaciones (drift) antes de que se conviertan en hallazgo de auditoría o vía de compromiso.
Mapear los principales controles del CIS Benchmark para Windows Server / Active Directory a su implementación real vía GPO y registro.
Reducir la superficie de ataque del DC: Print Spooler, roles innecesarios, protección de LSASS con RunAsPPL y, donde aplique, Credential Guard.
Entender el orden de precedencia de GPO (LSDOU) y por qué la Default Domain Controllers Policy es un objeto distinto —con distintas reglas de edición— que la Default Domain Policy.
Probar una baseline en una OU de laboratorio sin romper producción, usando RSAT, gpresult, filtrado WMI y un enfoque de solo-auditoría.

1. Punto de partida: por qué «funciona» no es lo mismo que «está protegido»

Es habitual encontrar dominios que arrancaron en Windows Server 2003 y han ido subiendo el nivel funcional del bosque (2008, 2012, 2016…) sin revisar nunca la seguridad heredada. Patrón típico: la Default Domain Controllers Policy sigue casi de fábrica; el Print Spooler está activo porque en 2003 era lo «normal»; LSASS corre sin RunAsPPL (inexistente hasta Windows 8.1/Server 2012 R2, KB2871997, 2014); la política de contraseñas es la por defecto, sin alinearse con CIS ni NIST SP 800-63B; y nadie sabe qué GPO gana en un conflicto porque no existe OU de test.

El objetivo moderno no es una configuración estática «perfecta», sino un proceso repetible: baseline oficial de Microsoft como punto de partida → ajuste guiado por el CIS Benchmark → prueba controlada en una OU de laboratorio → despliegue por anillos → auditoría periódica con Policy Analyzer para detectar drift. Ese proceso es exactamente lo que cubre este módulo, con los DCs como el activo de mayor criticidad de toda la infraestructura Windows.

2. El Microsoft Security Compliance Toolkit (SCT) y las Security Baselines

El Security Compliance Toolkit es el conjunto de herramientas y plantillas de GPO que Microsoft publica gratuitamente para llevar Windows y Windows Server a una configuración de seguridad recomendada. No es una imposición: es un punto de partida documentado y versionado que sustituye a «cada administrador aplica lo que le parece». Cada Security Baseline se publica como paquete descargable con, como mínimo: las plantillas administrativas (.admx/.adml) para verlas en GPMC; los GPO de ejemplo ya configurados, exportados como backup de GPO (importables con GPMC/PowerShell) y también como plantillas de LGPO.exe (.txt/.pol); una hoja de cálculo con cada directiva, el valor recomendado y la justificación de seguridad; y un checklist de «qué cambia respecto a la baseline anterior».

Microsoft publica baselines separadas para el sistema operativo cliente (Windows 10/11) y para Windows Server en sus distintas versiones (2012 R2, 2016, 2019, 2022 y, según disponibilidad, 2025), y distingue explícitamente el rol: un DC tiene requisitos que no aplican a un servidor de ficheros (replicación SYSVOL, Kerberos/KDC, NTDS, DNS integrado en AD), así que hay que aplicar siempre la baseline específica «Domain Controller», nunca la genérica de «Member Server», que puede desactivar servicios que el DC necesita para funcionar.

3. LGPO.exe: aplicar y auditar GPO desde línea de comandos

LGPO.exe es la utilidad de línea de comandos del Security Compliance Toolkit que permite importar, exportar, aplicar y convertir objetos de directiva de grupo local sin abrir gpedit.msc. Automatiza el despliegue de una baseline (imagen base de un DC, pipeline de aprovisionamiento) y audita en texto plano qué directivas tiene aplicadas una máquina en un momento dado.

Comando LGPO.exe	Qué hace
`LGPO.exe /g <carpeta_backup_GPO>`	Importa y aplica un GPO exportado en formato de backup de GPMC a la directiva de grupo local del equipo. Comando estándar para aplicar una baseline del SCT a un servidor concreto.
`LGPO.exe /b <carpeta_destino>`	Exporta la configuración de directiva de grupo local actual a una carpeta, en formato de backup de GPO. Captura el estado «antes» de un servidor de producción antes de tocar nada.
`LGPO.exe /r <archivo.pol> /v`	Vuelca en texto legible un Registry.pol, para revisar qué valores de registro impondría esa directiva antes de aplicarla.
`LGPO.exe /t <script.lgpo>`	Aplica un script de texto en formato LGPO (registro, derechos de usuario, configuración de seguridad) directamente, sin pasar por un backup de GPO completo.
`LGPO.exe /parse /m <Registry.pol>`	Convierte un Registry.pol binario a texto plano parseado, línea a línea, ideal para diff automatizado entre dos versiones de una baseline.

# Importar la baseline de Domain Controller del SCT descargada y descomprimida
# (aplica la configuración a la directiva de grupo LOCAL del DC en el que se ejecuta)
LGPO.exe /g "C:SCTWindows Server 2022 Security BaselineGPOs{Domain Controller}"

# Exportar el estado actual de un DC de producción ANTES de tocar nada (para poder comparar/revertir)
LGPO.exe /b C:BackupsDC01-antes-baseline-20260702

# Volcar en texto legible un Registry.pol para revisarlo antes de aplicarlo
LGPO.exe /r "C:SCTWindows Server 2022 Security BaselineGPOs{Domain Controller}DomainSysvolGPOMachineregistry.pol" /v

# Aplicar solo la parte de plantillas de seguridad (.inf) de una baseline, sin el resto del GPO
LGPO.exe /s "C:SCTWindows Server 2022 Security BaselineTemplatesbaseline-DC.inf"

La ruta con nombres entre llaves como {Domain Controller} corresponde al identificador legible que Microsoft asigna a cada carpeta de GPO dentro del paquete descargado del SCT; el nombre exacto de la carpeta varía ligeramente entre versiones del paquete, así que conviene listar el contenido de la carpeta GPOs tras descomprimir antes de referenciarla en un script.

4. Policy Analyzer: detectar drift entre tu configuración y la baseline

Policy Analyzer es la herramienta gráfica del SCT que compara varios conjuntos de GPO (o el estado de directiva local/efectiva de un equipo en vivo), resaltando en qué directivas difieren. Flujo habitual: cargar la baseline de Microsoft como «conjunto A», capturar el estado actual del DC como «conjunto B» (File → View / Compare → Add file… → System / Local (via GPResult)) y dejar que resalte cada divergencia fila por fila, con valor recomendado y valor real. Es la respuesta con evidencia a «¿sigue aplicada la baseline, o alguien ha cambiado algo?», y exporta la comparación a hoja de cálculo como evidencia de cumplimiento (ISO 27001, ENS) junto con las capturas de gpresult.

5. CIS Benchmarks: el complemento independiente a la baseline de Microsoft

El Center for Internet Security (CIS) publica sus CIS Benchmarks para Windows Server y Active Directory, por consenso de la comunidad (no solo del fabricante), en dos niveles: Nivel 1 (básico, compatible con la mayoría de entornos) y Nivel 2 (estricto, para entornos de alta seguridad, puede requerir ajustes). Suele ser más exhaustivo que la baseline de Microsoft en auditoría, servicios innecesarios y red, y añade una puntuación de conformidad medible con CIS-CAT Pro o, manualmente, cruzando cada control con gpresult y el registro. Recomendación de este módulo: la Security Baseline de Microsoft como capa base (ya empaquetada como GPO para LGPO.exe) y el CIS Benchmark como checklist adicional, sobre todo para los controles de la siguiente tabla.

6. Hardening específico del controlador de dominio

Tabla central del módulo: qué se endurece en un DC, por qué es un control real (no cosmético) y cómo se implementa, vía GPO, registro o comando.

Control de hardening	Por qué	Cómo (GPO / registro / comando)
Superficie mínima: sin roles ni características extra	Cada rol extra (IIS, servidor de archivos/impresión, herramientas de navegación) añade servicios escuchando, procesos con privilegios y parches que aplicar. Un DC comprometido tumba todo el dominio, así que su superficie debe ser mínima: AD DS, DNS y poco más.	`Get-WindowsFeature \| Where-Object InstallState -eq Installed` para auditar; `Uninstall-WindowsFeature` para lo no imprescindible. Un DC nunca debería tener IIS instalado ni usarse para navegar con sesión de administrador de dominio.
No usar el DC como estación de trabajo administrativa	Una sesión de Domain Admin usada para navegar o leer correo en el propio DC es la vía de entrada más citada en compromisos totales de dominio: cualquier malware de esa sesión captura credenciales cacheadas en LSASS.	Modelo de administración por niveles (Tier 0/1/2): acceso interactivo a DCs solo desde una Privileged Access Workstation (PAW) dedicada, nunca desde el puesto diario del administrador.
RestrictedAdmin Mode en RDP	Un RDP normal deja las credenciales completas en memoria del servidor destino, exponiéndolas a pass-the-hash/pass-the-ticket si ese servidor se compromete.	Conexión: `mstsc.exe /restrictedadmin`. Del lado DC: GPO Computer Configuration → Administrative Templates → System → Credentials Delegation → Restrict delegation of credentials to remote servers = Enabled, modo «Require Restricted Admin».
Protección de LSASS con RunAsPPL (Protected Process Light)	RunAsPPL convierte LSASS en «proceso protegido ligero»: solo drivers firmados y autorizados por Microsoft pueden inyectarse o volcar su memoria, bloqueando extractores de credenciales tipo Mimikatz sin driver compatible.	Registro: `HKLMSYSTEMCurrentControlSetControlLsa`, valor `RunAsPPL` (DWORD) = `1`. Requiere reinicio; desplegable vía GPO como preferencia de registro.
Credential Guard (donde el hardware y la edición lo soportan)	Aísla los secretos de LSASS en un contenedor virtualizado (VBS) separado del SO, de forma que ni un kernel comprometido lee directamente hashes NTLM ni tickets Kerberos en claro.	Requiere virtualización por hardware y, en muchas versiones, arranque seguro. GPO Administrative Templates → System → Device Guard → Turn On Virtualization Based Security, «Credential Guard Configuration» = Enabled. Probar compatibilidad en laboratorio antes de imponerlo.
Deshabilitar el servicio Print Spooler en los DCs	El Print Spooler expuesto en un DC es la superficie de PrintNightmare (CVE-2021-34527) y de la coacción de autenticación vía RPC del spooler. Microsoft recomienda deshabilitarlo en DCs salvo necesidad operativa justificada.	`Stop-Service -Name Spooler -Force` seguido de `Set-Service -Name Spooler -StartupType Disabled`. Vía GPO: Administrative Templates → Printers → Allow Print Spooler to accept client connections = Disabled.
Firewall del DC: solo los puertos de AD/DNS/Kerberos necesarios	Un DC solo necesita exponer LDAP 389/636, Kerberos 88, DNS 53, RPC 135+rango dinámico y SMB 445 (SYSVOL/NETLOGON); cualquier puerto adicional amplía la superficie de ataque.	Windows Defender Firewall vía GPO dedicada; auditar con `Get-NetFirewallRule \| Where-Object Enabled -eq True` y `netstat -ano`. Restringir origen de RDP/WinRM a la subred de administración o a las PAW.
Protección del NTDS.dit	`NTDS.dit` contiene la base de datos completa de AD, incluidos los hashes de todas las cuentas. Su robo (ntdsutil mal usado, VSS, copia del disco de la VM) equivale a comprometer el dominio offline.	Cifrado de disco (BitLocker) en los DCs físicos y virtuales; restricción estricta de quién hace backups de System State; en virtualización, controlar el acceso al hipervisor y a los snapshots/`.vhdx`.
Protección de las copias de seguridad del System State	Un backup de System State incluye el propio NTDS.dit y el registro con SYSKEY: mal protegido, es una vía de robo de credenciales de todo el dominio tan válida como atacar el DC en vivo.	`wbadmin start systemstatebackup -backupTarget:<ruta>` a un destino cifrado, con permisos restringidos a cuentas de backup dedicadas (no Domain Admins genéricos); auditar el acceso con SACL.
Restricción de «Debug programs»	`SeDebugPrivilege` permite adjuntarse a y leer la memoria de cualquier proceso, incluido LSASS: concedido de más, es una vía directa de volcado de credenciales.	GPO: User Rights Assignment → Debug programs. Debe quedar vacío o restringido a cuentas de servicio muy concretas y justificadas (nunca «Administrators» por defecto sin revisar).
Restricción de «Access this computer from the network»	Controla quién se autentica contra el DC vía red (SMB, RPC), el vector que usa la mayoría del movimiento lateral. Dejarlo abierto a grupos amplios facilita el pivotaje desde cualquier host comprometido.	GPO: mismo contenedor, directiva Access this computer from the network. La baseline de Domain Controller la restringe a Administrators, Authenticated Users y Enterprise Domain Controllers, excluyendo cuentas de servicio genéricas.
Cifrado en tránsito: LDAP Signing y Channel Binding	El tráfico LDAP sin firmar es susceptible de manipulación y relay (por ejemplo, relay NTLM contra LDAP), una de las vías de escalada más explotadas en post-explotación de AD.	GPO: Domain controller: LDAP server signing requirements = Require signing; más registro `LdapEnforceChannelBinding` bajo `HKLMSYSTEMCurrentControlSetServicesNTDSParameters` (alineado con ADV190023).
Política de contraseñas y bloqueo de cuenta	Una política débil o sin bloqueo habilita fuerza bruta y password spraying contra cualquier cuenta, incluidas las privilegiadas si no hay una Fine-Grained Password Policy más estricta.	GPO en la Default Domain Policy (solo surte efecto a nivel de dominio, no en OUs inferiores): longitud, complejidad, historial y bloqueo bajo Account Policies. Para privilegiadas: Fine-Grained Password Policies vía `New-ADFineGrainedPasswordPolicy`.

7. Precedencia de GPO: el orden LSDOU

Antes de tocar una sola directiva en producción hay que tener interiorizado el orden en que Windows procesa y aplica las GPO, porque de ese orden depende qué valor «gana» cuando dos directivas configuran el mismo ajuste de forma distinta. El acrónimo que resume ese orden es LSDOU: L — Local (la directiva de grupo local del propio equipo, la que edita/consulta gpedit.msc o LGPO.exe sin conexión a dominio, se procesa primero); S — Site (GPO enlazadas al sitio de Active Directory en Sites and Services); D — Domain (GPO enlazadas directamente al dominio, empezando por la Default Domain Policy); OU — Organizational Unit (GPO enlazadas a la OU que contiene el objeto, de la OU de más alto nivel a la más específica; si hay OUs anidadas, de fuera hacia dentro).

La regla de oro: la última directiva procesada gana en caso de conflicto directo, así que una GPO enlazada a la OU más específica tiene, por defecto, prioridad sobre una de dominio o de sitio. Esto hace especial a la Default Domain Controllers Policy: no es la misma GPO que la Default Domain Policy, sino un objeto independiente, enlazado a la OU «Domain Controllers», creado automáticamente al promocionar el primer DC del bosque. Al estar enlazada a una OU más específica que el dominio, sus valores prevalecen sobre los de la Default Domain Policy, salvo que se fuerce lo contrario con Enforced a nivel de dominio o se bloquee la herencia en la OU (Block Inheritance).

Dos matices que generan errores reales: Enforced (antes «No Override») hace que una GPO superior gane siempre frente a una OU inferior, aunque LSDOU procese la OU después —excepción explícita a «gana el último procesado»—; y Block Inheritance deja a una OU bloquear la herencia de niveles superiores, pero nunca una GPO Enforced, que siempre tiene la última palabra. Para depurar qué GPO se aplica realmente, la herramienta es gpresult en modo detallado, que muestra el «Winning GPO» de cada valor cuando compiten varias directivas.

8. Verificar y auditar GPO desde PowerShell y línea de comandos

# Listar TODOS los GPO del dominio con su fecha de última modificación
# (útil para detectar GPO "zombis" sin tocar en años o cambios recientes no documentados)
Get-GPO -All | Select-Object DisplayName, GpoStatus, ModificationTime | Sort-Object ModificationTime -Descending

# Ver el detalle de un GPO concreto, incluida su GUID (necesaria para cruzarla con el backup del SCT)
Get-GPO -Name "Default Domain Controllers Policy" | Format-List *

# Generar un informe HTML del resultado de directiva efectiva de un DC concreto (requiere permisos remotos)
Get-GPOReport -Name "Default Domain Controllers Policy" -ReportType Html -Path C:IRddcp-report.html

# Ver qué GPO están enlazadas a la OU de Domain Controllers, en orden de precedencia
Get-GPInheritance -Target "OU=Domain Controllers,DC=lab,DC=local"

# Generar el informe de directiva de grupo resultante (RSoP) del propio DC en formato HTML
gpresult /h C:IRgpresult-dc01.html /f

# Ver en consola, con detalle "verbose", qué directivas de seguridad ganaron y de qué GPO proceden
gpresult /r /v

# Forzar la actualización de directiva de grupo en el DC antes de verificar (equivalente a "gpupdate" clásico)
gpupdate /force /target:computer

9. Cómo probar una baseline sin romper producción

El error más caro en este módulo no es técnico, es de proceso: aplicar una baseline nueva directamente sobre la Default Domain Controllers Policy de producción «porque ya se ha probado en documentación de Microsoft». La secuencia correcta, pensada para no tumbar la autenticación del dominio:

Crear una OU de test dedicada (por ejemplo, OU=DC-Test,OU=Domain Controllers,DC=lab,DC=local, o mejor, un DC de laboratorio completamente aparte) — nunca la OU de Domain Controllers de producción directamente.
Crear un GPO NUEVO y separado con la baseline (nunca editar in-place la Default Domain Controllers Policy en el primer intento), enlazarlo solo a la OU de test, y acotar con filtrado de seguridad o filtrado WMI si hace falta (por ejemplo, a un solo DC por nombre).
Desplegar primero en modo auditoría cuando el control lo permita: directivas disruptivas (auditoría avanzada, algunas reglas de firewall, Credential Guard) admiten un periodo de solo-registro antes de forzar el bloqueo, para ver en los logs qué se rompería sin llegar a romperlo.
Verificar con RSAT y gpresult en el DC de test: que el GPO gane («Winning GPO» en gpresult /r /v) y que Netlogon, KDC, DNS y replicación SYSVOL sigan operativos con dcdiag /v y repadmin /replsummary.
Comparar con Policy Analyzer el estado resultante frente a la baseline oficial, para descartar desviaciones no intencionadas de GPO heredadas.
Desplegar por anillos en producción: un único DC no crítico primero, monitorizar 24-72 horas, y solo entonces extender al resto de la OU real.
Documentar el rollback antes de cada paso: backup de GPO previo (Backup-GPO) y backup de LGPO.exe del estado local, para que revertir sea un comando, no una reconstrucción manual.

10. Laboratorio: aplicar la Security Baseline a una OU de DCs de laboratorio

Objetivo: en un dominio Active Directory de laboratorio (mínimo un DC, idealmente Windows Server 2019 o 2022, sin datos ni usuarios reales), descargar e importar la Security Baseline de Microsoft de Domain Controller, aplicarla de forma controlada y verificar el resultado con gpresult y Policy Analyzer.

Preparación: confirma la versión del DC de laboratorio (Get-ComputerInfo | Select WindowsProductName, OsVersion) y crea una OU de prueba: New-ADOrganizationalUnit -Name "DC-Baseline-Test" -Path "DC=lab,DC=local". Si solo tienes un DC, valora clonarlo o levantar uno desechable antes de continuar.
Descarga del SCT: obtén el paquete de la Security Baseline de tu versión de Windows Server desde el sitio oficial del Microsoft Security Compliance Toolkit, descomprímelo (por ejemplo en C:SCT) y verifica en GPOs el nombre exacto de la subcarpeta de Domain Controller.
Backup del estado previo: LGPO.exe /b C:Backupsantes-baseline en el DC, y Backup-GPO -Name "Default Domain Controllers Policy" -Path C:BackupsGPO a nivel de dominio.
Importar como GPO nuevo: crea en GPMC (o PowerShell) un GPO nuevo «Baseline-DC-2026-Test», impórtale la carpeta {Domain Controller} del SCT con el asistente de importación de backup de GPMC, y enlázalo solo a la OU DC-Baseline-Test.
Aplicar: mueve el objeto equipo del DC de laboratorio a la OU de prueba (o usa filtrado de seguridad), ejecuta gpupdate /force /target:computer y confirma que termina sin errores.
Verificación con gpresult: gpresult /h C:IRbaseline-test.html /f y confirma que «Baseline-DC-2026-Test» aparece como «Winning GPO» en la política de auditoría avanzada y los derechos de usuario de la baseline.
Verificación con Policy Analyzer: carga como referencia los archivos de la baseline original (Add files from a GPO(s)…) y compáralos con el estado en vivo del DC de test (View / Compare → System / Local (via GPResult)), confirmando que no hay divergencias no explicadas.
Comprobación funcional: dcdiag /v y repadmin /replsummary para confirmar autenticación, replicación y DNS con normalidad. Si algo falla, revierte con el backup del paso 3 y documenta qué directiva causó el problema.

11. Errores comunes

Editar directamente la Default Domain Policy o la Default Domain Controllers Policy «a lo loco»: modificarlas in-place sin backup ni prueba previa en OU de test deja sin autenticación a todo el dominio de forma inmediata tras gpupdate, porque ambas afectan a todos los DCs (o a todo el dominio) a la vez.
No crear nunca una OU de test: aplicar cualquier GPO nueva directamente contra la OU real de Domain Controllers «porque ya se ha revisado la documentación» salta el único paso que detecta incompatibilidades reales del entorno (software de terceros, configuraciones heredadas) antes de que afecten a todos los DCs a la vez.
Aplicar la baseline de «Member Server» a un DC en lugar de la específica de «Domain Controller», lo que puede restringir servicios que el DC necesita (Netlogon, KDC, replicación).
Confundir «Enforced» con «prioridad normal de OU»: asumir que una GPO de OU siempre gana porque LSDOU la procesa «al final», olvidando que una GPO superior marcada como Enforced anula esa regla para los valores que configura.
Desplegar Credential Guard sin comprobar compatibilidad: activarlo en todos los DCs sin verificar antes soporte de virtualización por hardware y compatibilidad de software, lo que puede impedir el arranque correcto del rol AD DS.
Deshabilitar el Print Spooler sin comprobar dependencias reales: en la mayoría de los DCs es correcto, pero si algún flujo legacy legítimo depende de impresión desde el propio DC, hay que documentarlo y migrarlo antes de deshabilitar, no después de que falle en producción.
No repetir la auditoría con Policy Analyzer periódicamente: aplicar la baseline una vez y no volver a comprobar el drift; un cambio manual posterior o un GPO nuevo mal enlazado degrada la postura de seguridad sin que nadie se entere hasta la siguiente auditoría externa.

12. Ejercicio

Te entregan el resultado de gpresult /r /v ejecutado en un DC de producción llamado DC02, del que extraes estos fragmentos relevantes:

Applied GPOs: Default Domain Policy (enlazada al dominio, no Enforced), Default Domain Controllers Policy (enlazada a OU=Domain Controllers, no Enforced), Legacy-Print-Policy-2011 (enlazada a OU=Domain Controllers, no Enforced, creada en 2011, habilita «Allow Print Spooler to accept client connections»).
Winning GPO para «Allow Print Spooler to accept client connections»: Legacy-Print-Policy-2011 = Enabled.
El servicio Spooler figura como Running, Startup Type: Automatic, a pesar de que la nueva «Baseline-DC-2026» (creada este mes y también enlazada a la misma OU) configura esa misma directiva como Disabled.
Orden de enlace en la OU Domain Controllers (Link Order, de mayor a menor precedencia): 1) Legacy-Print-Policy-2011, 2) Baseline-DC-2026.

Preguntas: (1) ¿Por qué está ganando Legacy-Print-Policy-2011 sobre Baseline-DC-2026 si esta última se creó más recientemente (pista: no es una cuestión de fecha de creación)? (2) ¿Qué acción sobre el Link Order resolvería el conflicto sin tocar ninguna de las dos GPO por dentro? (3) Además de reordenar el enlace, ¿qué otra acción sobre el contenido de Legacy-Print-Policy-2011 sería más correcta a medio plazo? (4) Redacta, en dos frases, el riesgo concreto de que el Print Spooler siga activo en este DC, relacionándolo con una vulnerabilidad real mencionada en el módulo.

Preguntas frecuentes

¿Puedo aplicar la Security Baseline de Microsoft directamente con LGPO.exe en cada DC, sin pasar por GPMC ni por un GPO de dominio?

Técnicamente sí: LGPO.exe /g aplica la baseline como directiva de grupo local en ese equipo, y es lo que hacen muchas organizaciones para la imagen base de un DC antes de promocionarlo. Pero para mantenimiento a largo plazo con varios DCs es preferible un GPO real enlazado a la OU de Domain Controllers: el cumplimiento se gestiona centralizadamente y queda auditable con Get-GPO y Policy Analyzer sin conectarte a cada servidor.

¿Qué diferencia hay entre RunAsPPL y Credential Guard? ¿Necesito los dos?

RunAsPPL protege LSASS convirtiéndolo en proceso protegido dentro del mismo sistema operativo: bloquea inyección o volcado no autorizados, pero si el kernel está comprometido puede eludirse. Credential Guard va más allá y aísla los secretos en un contenedor separado mediante virtualización (VBS), de forma que ni un kernel comprometido tiene acceso directo. No son excluyentes: lo habitual es habilitar RunAsPPL casi universalmente (bajo impacto) y evaluar Credential Guard donde hardware, edición y compatibilidad lo permitan, tras pruebas.

¿Por qué la política de contraseñas de dominio solo se puede configurar en la Default Domain Policy y no en una OU cualquiera?

Es una particularidad de diseño de AD: la política de contraseñas y bloqueo «clásica» (Account Policies) solo tiene efecto para cuentas de dominio cuando se define en un GPO enlazado al propio dominio; configurada en el GPO de una OU solo afectaría a las cuentas locales de esos equipos. Para políticas distintas por grupo (por ejemplo, más estricta para administradores) hace falta usar Fine-Grained Password Policies (PSO), objetos independientes del sistema de GPO tradicional.

¿Deshabilitar el Print Spooler en los DCs puede romper algo que no sea imprimir directamente desde el servidor?

El caso más citado no es la impresión en sí: algunos flujos legacy muy antiguos usaban RPC del spooler para operaciones que ya no son la forma recomendada de trabajar, y en un DC moderno ese tráfico no debería depender del propio controlador. Antes de deshabilitarlo en producción, revisa los logs de conexión al spooler durante un periodo (o despliega primero en modo auditoría en la OU de test) para confirmar que nada legítimo depende de él.

¿Cómo sé si una GPO nueva que acabo de enlazar realmente se está aplicando, sin esperar al ciclo de refresco automático?

Ejecuta gpupdate /force /target:computer para forzar el refresco de la configuración de equipo, y después gpresult /r /v o gpresult /h archivo.html /f. Busca el nombre de tu GPO en «Applied GPOs» y, para cada ajuste, confirma que aparece como «Winning GPO» — que esté «aplicada» no garantiza que haya ganado el valor final si otra GPO con más precedencia configura lo mismo.

«The Security Compliance Toolkit (SCT) is a set of tools that allows enterprise security administrators to download, analyze, test, edit, and store Microsoft-recommended security configuration baselines for Windows and other Microsoft products […] LGPO.exe is a command-line utility that is designed to help you manage Local Group Policy effectively.» — Microsoft Learn, «Microsoft Security Compliance Toolkit 1.0»

Módulo 4: Hardening de controladores de dominio y baselines de GPO