GPO para seguridad:

las directivas que de verdad mueven la aguja

Administración de sistemas Windows  |  unfantasmaenelsistema.com

Una directiva de grupo (GPO, Group Policy Object) es la forma nativa de imponer configuración a cientos o miles de equipos y usuarios de un dominio Active Directory desde un único sitio. El problema no es que falten opciones: un editor de directivas ofrece varios miles de ajustes. El problema es que casi nadie sabe cuáles importan de verdad para la seguridad, en qué orden se aplican, y por qué la configuración que «debería» estar activa a veces no lo está en el equipo de destino.

Este artículo separa las dos cosas que hay que dominar para usar GPO como herramienta defensiva: el motor de procesamiento (cómo Windows decide qué directiva gana cuando varias se pisan) y el catálogo corto de directivas de alto impacto que frenan la mayoría de las técnicas de ataque internas. Todo desde el lado del administrador, sobre un dominio propio o de laboratorio.

1. De qué está hecha una GPO

Una GPO tiene dos mitades. El Group Policy Container vive en Active Directory (metadatos, versión, estado) y la Group Policy Template vive en la carpeta compartida SYSVOL de los controladores de dominio (los ficheros reales: plantillas ADMX, scripts, ficheros de seguridad). Cuando enlazas una GPO a un sitio, dominio o unidad organizativa (OU), los equipos afectados descargan esa plantilla y aplican su contenido en el arranque (parte de equipo) y en el inicio de sesión (parte de usuario), y después cada 90 minutos aproximadamente con un margen aleatorio.

1.1 Plantillas administrativas frente a preferencias

Las plantillas administrativas (Administrative Templates) escriben en zonas del registro reservadas para directivas. Son de cumplimiento forzoso: si el usuario cambia el valor a mano, en el siguiente refresco vuelve a su sitio, y si la GPO deja de aplicarse el ajuste se revierte. Es el comportamiento que quieres para seguridad.

Las preferencias de directiva de grupo (Group Policy Preferences) configuran cosas que históricamente se tocaban a mano: unidades de red, tareas programadas, variables de entorno, miembros de grupos locales. Por defecto se aplican una vez y no se revierten si la GPO desaparece («tatuaje» del sistema). Son útiles, pero conviene marcar la opción «Quitar este elemento cuando ya no se aplique» cuando el objetivo es mantener un estado controlado.

2. Cómo se procesan las GPO: el orden manda

Cuando un equipo o un usuario está bajo varias GPO con ajustes contradictorios, gana la última que se aplica. El orden es el acrónimo LSDOU:

• L — Local: la directiva local del propio equipo (gpedit.msc), la primera y la más débil
• S — Site (sitio): GPO enlazadas al sitio de Active Directory al que pertenece la IP del equipo
• D — Domain (dominio): GPO enlazadas a la raíz del dominio, como la Default Domain Policy
• O — OU (unidad organizativa): de la OU más alta a la más profunda; la OU que contiene directamente el objeto es la última y, por tanto, la que prevalece

Dentro de un mismo contenedor, si hay varias GPO enlazadas, el orden de vínculo decide: el número 1 se procesa el último y gana. Sobre esa regla base actúan cuatro modificadores.

2.1 Herencia, bloqueo y enforcement

La combinación importante: Enforced gana siempre a Block Inheritance. Si necesitas garantizar que una política llega a toda la organización pase lo que pase en las OU, márcala como aplicada en el vínculo del dominio.

2.2 Filtrado por seguridad y filtros WMI

Que una GPO esté enlazada a una OU no significa que se aplique a todo lo que hay dentro. Para que un objeto procese la GPO necesita el permiso Leer y Aplicar directiva de grupo sobre ella. Por defecto lo tiene el grupo «Usuarios autenticados»; restringiendo esa lista a un grupo concreto limitas el alcance real. Desde el parche de 2016 (MS16-072), además, el equipo necesita permiso de lectura aunque filtres por usuarios, así que si filtras por un grupo hay que añadir también «Equipos del dominio» con permiso de solo lectura.

Un filtro WMI añade una condición evaluada en el cliente: «aplica esta GPO solo si el sistema operativo es servidor», «solo si es un portátil», «solo si queda espacio en disco». Son cómodos pero cuestan tiempo en cada refresco; conviene usarlos con moderación.

2.3 El modo loopback

Normalmente la parte de usuario de una GPO se decide por dónde está la cuenta de usuario en el árbol, no por el equipo donde inicia sesión. El procesamiento de bucle invertido (loopback) invierte eso: hace que las directivas de usuario dependan de la OU del equipo. Es esencial para escenarios de escritorio bloqueado — servidores de terminales, quioscos, aulas, servidores de salto — donde quieres que cualquiera que entre en esa máquina reciba una configuración endurecida independientemente de quién sea. Tiene dos modos: Merge (combina las directivas de usuario normales con las del equipo) y Replace (ignora por completo las del usuario).

3. Las directivas que de verdad reducen la superficie de ataque

De los miles de ajustes disponibles, un grupo reducido concentra casi todo el valor defensivo. Están casi todos bajo Configuración del equipo > Directivas > Configuración de Windows > Configuración de seguridad.

4. No empieces de cero: baselines de Microsoft

Microsoft publica gratis las Security Baselines dentro del Security Compliance Toolkit: juegos de GPO ya preparados para cada versión de Windows 10/11 y Windows Server, con la justificación de cada ajuste en una hoja de cálculo y scripts de importación. Son el punto de partida recomendado: en lugar de decidir miles de valores, importas la baseline, la revisas y ajustas las excepciones que tu entorno necesite.

El toolkit incluye LGPO.exe, una utilidad de línea de comandos para aplicar, exportar y comparar directiva local — clave para preparar imágenes base, endurecer equipos que no están en el dominio, o revisar en un laboratorio qué cambia una baseline antes de tocar producción. PolicyAnalyzer compara varios conjuntos de directivas entre sí y contra el estado efectivo de una máquina.

REM --- Comparar y aplicar una baseline en un equipo de laboratorio (LGPO) ---
REM Exportar la directiva local actual a una carpeta de respaldo
LGPO.exe /b C:\GPO\backup-antes
 
REM Aplicar un backup de GPO (por ejemplo la baseline de Windows 11)
LGPO.exe /g C:\GPO\Win11-Baseline\GPOs
 
REM Volcar una GPO de dominio respaldada a texto legible para revisarla
LGPO.exe /parse /m C:\GPO\Win11-Baseline\GPOs\{GUID}\DomainSysvol\GPO\Machine\registry.pol

5. Auditar lo que realmente se aplica

El error más común es asumir que la GPO configurada es la GPO aplicada. Entre una y otra hay herencia, bloqueos, filtros de seguridad, filtros WMI, errores de replicación de SYSVOL y precedencia de vínculos. Estas herramientas cierran esa brecha, y todas son de lectura:

# --- Inventario y salud de las GPO del dominio (todo lectura) ---
Import-Module GroupPolicy
 
# Informe del estado efectivo en el equipo actual
gpresult /h $env:USERPROFILE\Desktop\rsop.html /f
 
# Listar todas las GPO con su estado
Get-GPO -All | Sort-Object DisplayName |
    Select-Object DisplayName, GpoStatus, ModificationTime
 
# GPO sin ningun enlace (candidatas a huerfanas)
$sominados = (Get-GPOReport -All -ReportType Xml)
Get-GPO -All | Where-Object {
    ([xml](Get-GPOReport -Guid $_.Id -ReportType Xml)).GPO.LinksTo -eq $null
} | Select-Object DisplayName, Id
 
# Copia de seguridad completa de todas las GPO antes de tocar nada
Backup-GPO -All -Path C:\GPO\backup-$(Get-Date -Format yyyyMMdd)

5.1 GPO huérfanas y restos que conviene limpiar

• GPO sin enlace: existen en el dominio pero no están enlazadas a ningún sitio, dominio ni OU — no hacen nada, pero ensucian el inventario y pueden reactivarse por error
• Enlaces a GPO borradas: la OU apunta a un GUID que ya no existe; aparecen como «No se encontró» en la consola
• Carpetas de SYSVOL sin GPC: restos en el recurso compartido que no corresponden a ninguna GPO viva
• Permisos incoherentes: GPO donde alguien quitó «Usuarios autenticados» sin añadir «Equipos del dominio», con lo que desde MS16-072 dejan de aplicarse en silencio
• Versión de equipo y de usuario desincronizada entre AD y SYSVOL: síntoma de un problema de replicación (DFS-R) que hay que resolver antes de confiar en ninguna directiva

6. Errores que anulan el esfuerzo

• Meter todos los ajustes de seguridad en la Default Domain Policy: mézclalo con la política de contraseñas del dominio y cualquier restauración de emergencia te lleva todo por delante. Crea GPO propias y deja las Default casi como vienen
• Editar directivas en producción sin copia de seguridad previa ni ventana de cambios: `Backup-GPO` cuesta un segundo y `Import-GPO` te devuelve el estado anterior
• Abusar de Block Inheritance y de filtros WMI hasta que nadie entiende qué se aplica dónde; casi siempre se resuelve mejor con la estructura de OU y el orden de vínculos
• Desplegar una baseline entera de golpe sobre todo el parque y descubrir a la vez veinte aplicaciones rotas
• Activar auditoría avanzada sin nadie que recoja y mire esos eventos: la telemetría sin un SIEM detrás es solo disco ocupado
• Olvidar el lado de usuario + loopback en los servidores de salto y de terminales, que son precisamente las máquinas que más gente distinta pisa

Conclusión

Las GPO no fallan por falta de opciones, fallan por falta de método. Primero hay que entender el motor — LSDOU, herencia, enforcement, filtrado y loopback — porque sin eso no sabes si la directiva que configuraste es la que llega al equipo. Después, en lugar de perderte entre miles de ajustes, aplicas una baseline de Microsoft y la adaptas: contraseñas y bloqueo, derechos de inicio de sesión, opciones de seguridad, auditoría avanzada, restricción de NTLM, firewall entre estaciones y control de ejecución concentran casi todo el valor defensivo.

Y el trabajo no termina al guardar: se audita con GPResult y RSoP, se hace copia de seguridad antes de cada cambio, se despliega por anillos y se limpian las GPO huérfanas y los permisos rotos. Una directiva de grupo bien mantenida es de las medidas de seguridad más rentables que existen en un dominio Windows; una mal entendida da una falsa sensación de control que es peor que no tener ninguna.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)