Hardening de la directiva de grupo y SYSVOL

La directiva de grupo es uno de los planos de control más potentes de Active Directory: una GPO vinculada a la OU equivocada, o un derecho de edición delegado al grupo equivocado, puede distribuir una tarea programada o un script de inicio a todos los equipos del ámbito. SYSVOL, el recurso compartido que replica el contenido de las GPO en todos los controladores de dominio, arrastra su propia larga lista de riesgos heredados, el más conocido de los cuales es el campo cpassword que dejó Group Policy Preferences. Esta guía cubre la revisión de la delegación, la limpieza de cpassword, los permisos de SYSVOL y el control de cambios, con PowerShell para cada uno.

Delegación de GPO: quién puede editar y vincular

Hay dos permisos distintos que importan y que a menudo se confunden: los derechos de edición sobre el propio objeto GPO (quién puede cambiar lo que hace la directiva) y los derechos de vinculación sobre el objeto de OU o de dominio (quién puede decidir dónde se aplica). Un usuario que solo tiene derechos de edición sobre una GPO que no está vinculada a nada sensible supone poco riesgo; un usuario con derechos de vinculación sobre la OU Domain Controllers o la raíz del dominio supone un riesgo alto independientemente de las GPO que pueda editar, porque puede vincular una GPO existente de aspecto inofensivo sobre la que otra persona tenga acceso de escritura.

Revisar los permisos actuales de las GPO

Import-Module GroupPolicy

Get-GPO -All | ForEach-Object {
    $gpo = $_
    Get-GPPermission -Guid $gpo.Id -All |
        Where-Object { $_.Permission -in 'GpoEditDeleteModifySecurity','GpoEdit' } |
        Select-Object @{n='GPOName';e={$gpo.DisplayName}}, Trustee, Permission
} | Format-Table -AutoSize

Revisar quién puede vincular GPO (acceso de escritura a gPLink)

Los derechos de vinculación residen en la ACL del objeto de OU o de dominio, no en la GPO. Compruebe específicamente la OU Domain Controllers y la raíz del dominio, ya que son los destinos de vinculación de mayor impacto:

$dcOU = (Get-ADDomain).DomainControllersContainer
$domainRoot = (Get-ADDomain).DistinguishedName

foreach ($target in @($dcOU, $domainRoot)) {
    Write-Host "== $target ==" -ForegroundColor Cyan
    (Get-Acl -Path "AD:\$target").Access |
        Where-Object { $_.ObjectType -eq 'f30e3bbe-9ff0-11d1-b603-0000f80367c1' -or $_.ActiveDirectoryRights -match 'WriteProperty|GenericAll|GenericWrite' } |
        Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType
}

El GUID f30e3bbe-9ff0-11d1-b603-0000f80367c1 es el GUID de esquema del atributo gPLink, así que esto filtra específicamente el acceso de escritura al atributo de vinculación, además de cualquier concesión amplia que lo cubra. Elimine aquí cualquier titular que no sea Domain Admins o un grupo de administración de directivas de grupo creado expresamente para ello: los derechos de vinculación sobre la OU Domain Controllers no deben delegarse de forma amplia.

El problema de cpassword en Group Policy Preferences

Antes de MS14-025 (KB2962486, publicado el 13 de mayo de 2014), Group Policy Preferences permitía a los administradores distribuir mediante GPO contraseñas de cuentas locales, asignaciones de unidades con credenciales, tareas programadas y servicios con contraseñas almacenadas, cifrando la contraseña con una clave AES estática que Microsoft había publicado como parte de la documentación de GPP. Cualquier usuario autenticado del dominio puede leer SYSVOL, por lo que cualquier valor cpassword que quede puede descifrarlo trivialmente cualquiera con acceso de lectura al recurso compartido: el cifrado no proporciona ninguna protección real.

El parche impidió que el editor de GPP escribiera nuevos valores cpassword, pero no hizo nada para eliminar los creados anteriormente. Es el hallazgo más común en los entornos de AD anteriores al parche.

Encontrar valores cpassword en SYSVOL

$sysvolPath = "\\$((Get-ADDomain).DNSRoot)\SYSVOL\$((Get-ADDomain).DNSRoot)\Policies"

Get-ChildItem -Path $sysvolPath -Recurse -Include *.xml -ErrorAction SilentlyContinue |
    Select-String -Pattern 'cpassword="[^"]+"' |
    Select-Object Path, LineNumber, @{n='Match';e={$_.Matches.Value}}

GPP los almacena en archivos XML concretos según el tipo de preferencia: Groups.xml (cuentas locales), Services.xml, ScheduledTasks.xml, DataSources.xml y Drives.xml son los habituales. La búsqueda anterior los detecta todos, ya que examina cada XML del árbol Policies.

Corregir

1. Para cada coincidencia, abra la GPO correspondiente en la consola de administración de directivas de grupo (GPMC) y elimine el elemento de preferencia problemático (Local Users and Groups, Scheduled Tasks, Drive Maps o Services, según corresponda) en lugar de editar el XML a mano.
2. Cambie la credencial en todos los lugares donde se usó. Eliminar el cpassword de la GPO no cambia la contraseña real en los sistemas de destino: trate cada valor descubierto como una credencial comprometida y cámbiela.
3. Confirme la eliminación:

Get-ChildItem -Path $sysvolPath -Recurse -Include *.xml -ErrorAction SilentlyContinue |
    Select-String -Pattern 'cpassword="[^"]+"' | Measure-Object

Un resultado vacío confirma que no quedan entradas cpassword. Repita esta comprobación periódicamente: una copia de seguridad restaurada o una GPO heredada reimportada puede reintroducir una sin que nadie lo note.

Permisos de SYSVOL y revisión de scripts

SYSVOL también contiene los scripts de inicio, apagado, inicio de sesión y cierre de sesión a los que hacen referencia las GPO. Cualquiera con acceso de escritura a la carpeta de scripts correspondiente puede modificar código que se ejecuta con privilegios SYSTEM (scripts de inicio y apagado) en todos los equipos de destino.

$scriptsPath = "\\$((Get-ADDomain).DNSRoot)\SYSVOL\$((Get-ADDomain).DNSRoot)\scripts"

(Get-Acl -Path $scriptsPath).Access |
    Select-Object IdentityReference, FileSystemRights, AccessControlType

La referencia esperada es Administrators (que contiene Domain Admins y Enterprise Admins), SYSTEM y CREATOR OWNER con control total, y Authenticated Users y Server Operators solo con lectura y ejecución. Cualquier permiso de escritura más amplio es un hallazgo. Compare también periódicamente los hashes de los archivos de script con una referencia conocida y válida para detectar modificaciones no autorizadas fuera de las ventanas de cambio normales.

Copia de seguridad y control de cambios de las GPO

Trate las GPO como infraestructura como código: haga una copia de seguridad antes de los cambios y compare los cambios a lo largo del tiempo en lugar de descubrirlos a posteriori.

# Copia de seguridad de todas las GPO en una carpeta con fecha
$backupPath = "D:\GPOBackups\$(Get-Date -Format yyyy-MM-dd)"
New-Item -Path $backupPath -ItemType Directory -Force | Out-Null
Backup-GPO -All -Path $backupPath

# Generar un informe completo para compararlo con la referencia anterior
Get-GPO -All | ForEach-Object {
    Get-GPOReport -Guid $_.Id -ReportType Xml -Path "$backupPath\$($_.DisplayName -replace '[\\/:*?"<>|]','_').xml"
}

Guarde las exportaciones de informes en un sistema de control de versiones para que los cambios en la configuración de las GPO, no solo en sus vínculos, aparezcan como diferencias revisables. Restaure a partir de una copia de seguridad concreta con Restore-GPO -Guid <id> -Path <backupPath> si hay que revertir un cambio.

Qué se rompe

• Restringir la delegación de edición/vinculación de GPO: cualquier grupo de soporte o de administradores de sede que hoy gestione por su cuenta los cambios de GPO de su OU pierde esa capacidad y necesita un procedimiento formal de solicitud, o una delegación muy acotada y limitada a su propia OU (nunca la OU Domain Controllers ni la raíz del dominio).
• Eliminar los elementos de GPP basados en cpassword: las cuentas locales, tareas programadas o asignaciones de unidades que dependían de ese elemento de GPP dejan de configurarse de forma centralizada; debe sustituir el mecanismo (LAPS para las contraseñas de administrador local, un despliegue de tareas programadas debidamente protegido, o asignaciones de unidades por directiva de grupo sin credenciales incrustadas) antes de eliminar la preferencia antigua, no después.
• Restringir los permisos de la carpeta de scripts de SYSVOL: rompe cualquier flujo de trabajo en el que personal no administrador deposite o edite directamente scripts de inicio de sesión o de inicio en el recurso compartido en lugar de pasar por el control de cambios.
• Limitar los derechos de gPLink solo a Domain Admins: los administradores de GPO delegados regionales o departamentales que hoy vinculan sus propias GPO necesitarán la intervención de un Domain Admin para vincularlas en adelante, aunque conserven los derechos de edición sobre sus propias GPO.

Para controles de Tier 0 adyacentes, consulte Hardening de controladores de dominio y Hardening de Kerberos.