Cómo habilitar BitLocker en cientos de equipos Windows 11 mediante Group Policy y PowerShell

Problema

Muchas organizaciones que migraron recientemente a Windows 11 todavía gestionan los equipos de forma manual. Cuando el número de estaciones supera el centenar, habilitar BitLocker de forma individual se vuelve inviable. El reto típico es:

• Automatizar la activación y el cifrado de los discos del sistema.
• Garantizar que la clave de recuperación y el TPM se almacenen en Active Directory (AD).
• Evitar bloqueos de BitLocker provocados por actualizaciones de firmware o por la pérdida de la configuración del BIOS/CMOS.
• Mantener visibilidad de errores sin depender de herramientas de gestión de terceros.

El problema no es exclusivo de un caso concreto; cualquier entorno híbrido (on‑prem AD + equipos sin MDM) que necesite escalar la protección de datos se enfrenta a los mismos obstáculos.

Causa

1. Falta de automatización centralizada – Sin una política de grupo que invoque scripts, cada máquina requiere intervención manual para iniciar BitLocker y registrar la clave en AD.

2. Inconsistencias de TPM/Firmware – Actualizaciones de BIOS/UEFI pueden cambiar el estado del TPM (por ejemplo, desactivar la protección del arranque) y provocar que BitLocker se quede “bloqueado” al reiniciar.

3. CMOS agotada – Cuando la batería del CMOS falla, la BIOS puede resetear la configuración del TPM y del arranque seguro, lo que también genera un lockout.

4. Equipos fuera del dominio – Los dispositivos que no pueden contactar a AD no pueden publicar la clave de recuperación, lo que obliga a usar soluciones externas o a excluirlos del despliegue.

5. Políticas de cifrado incompletas – Si la política no obliga a usar TPM + PIN o a crear una clave de recuperación, el proceso puede quedar a medio camino y generar alertas en el visor de eventos.

Solución

Una estrategia reutilizable combina Group Policy, PowerShell y AD backup. Los pasos clave son:

1. Crear una GPO de arranque que ejecute dos scripts: uno que verifique el estado del cifrado y, si es necesario, inicie BitLocker; otro que compruebe que la clave está en AD y, de no ser así, la publique.

2. Configurar la política de BitLocker en la GPO:

   • Requerir TPM y, opcionalmente, PIN.
   • Habilitar el respaldo automático a AD (EnableBDE).
   • Definir el método de cifrado (XTS‑AES 256) y el porcentaje de cifrado inicial (por ejemplo, 50 % para minimizar el impacto de la primera fase).

3. Implementar scripts idempotentes. Cada script debe registrar su ejecución en el Event Viewer (ID de evento propio) y salir sin error si el estado ya está correcto. De esta forma, la GPO puede ejecutarse en cada arranque sin generar bucles.

4. Gestionar actualizaciones de firmware:

   • Desactivar temporalmente la política que fuerza el arranque seguro antes de aplicar una actualización de BIOS.
   • Reiniciar el equipo, aplicar la actualización y volver a habilitar la política.
   • Registrar el proceso en el mismo log para auditoría.

5. Monitorear la batería del CMOS:

   • Añadir una comprobación de Get-WmiObject -Class Win32_Battery (aunque la mayoría de PCs de escritorio no exponen la batería, el comando Get-WmiObject -Class Win32_BIOS permite leer el estado del CMOS).
   • Si la batería está por debajo de un umbral, crear un ticket automático o marcar el equipo para mantenimiento físico.

6. Manejar equipos fuera del dominio:

   • Usar Action1 (u otra herramienta RMM) para ejecutar el mismo script, pero almacenar la clave en un vault interno y notificar al equipo de seguridad.
   • Alternativamente, crear una OU “No‑Domain” y aplicar una GPO que solo active BitLocker sin intentar publicar en AD; la clave se exporta a un archivo cifrado y se envía por correo seguro al administrador.

Flujo de trabajo recomendado

Cuándo aplicar esta solución

Aplica cuando:

• Tienes ≥ 100 equipos con Windows 11 y AD on‑prem.
• No dispones de un MDM (Intune, Jamf, etc.) o no quieres migrar inmediatamente.
• Necesitas cumplir con normas de cifrado (PCI‑DSS, GDPR, etc.) y el backup de claves es obligatorio.
• Los equipos están bajo control de arranque (TPM presente y habilitado).

No aplica si:

• Todos los dispositivos están gestionados por un MDM que ya incluye BitLocker como política.
• La infraestructura es totalmente cloud‑only y no hay AD local para almacenar claves.
• Los equipos son laptops con BitLocker ya activado por políticas de empresa y solo requieren monitoreo.

Código

# CheckDrivesEncrypted.ps1
$logSource = "BitLockerDeploy"
if (-not (Get-EventLog -LogName Application -Source $logSource -ErrorAction SilentlyContinue)) {
    New-EventLog -LogName Application -Source $logSource
}
$drives = Get-BitLockerVolume -MountPoint C:
if ($drives.ProtectionStatus -eq 'Off') {
    Write-EventLog -LogName Application -Source $logSource -EventId 6000 -EntryType Information -Message "Iniciando BitLocker en C:"
    Enable-BitLocker -MountPoint C: -EncryptionMethod XtsAes256 -UsedSpaceOnly -TpmProtector
    # Esperar a que el cifrado alcance al menos 10%
    while ((Get-BitLockerVolume -MountPoint C:).EncryptionPercentage -lt 10) { Start-Sleep -Seconds 30 }
    Write-EventLog -LogName Application -Source $logSource -EventId 6001 -EntryType Information -Message "BitLocker iniciado, % cifrado: $((Get-BitLockerVolume -MountPoint C:).EncryptionPercentage)"
} else {
    Write-EventLog -LogName Application -Source $logSource -EventId 6002 -EntryType Information -Message "C: ya está cifrado"
}

# CheckKeys.ps1
$logSource = "BitLockerDeploy"
$adKey = Get-ADObject -Filter {ObjectClass -eq "msFVE-RecoveryInformation"} -SearchBase "CN=Computers,DC=contoso,DC=local" -Properties msFVE-RecoveryPassword | Where-Object {$_.Name -eq $env:COMPUTERNAME}
if (-not $adKey) {
    Write-EventLog -LogName Application -Source $logSource -EventId 6100 -EntryType Warning -Message "Clave de recuperación no encontrada en AD, intentando backup."
    $tpm = Get-BitLockerVolume -MountPoint C:
    $tpm | Add-BitLockerKeyProtector -RecoveryPasswordProtector
    $tpm | Backup-BitLockerKeyProtector -KeyProtectorId $tpm.KeyProtector[0].KeyProtectorId -MountPoint C: -Directory "C:\Temp\Recovery"
    # Aquí se podría invocar un script de Action1 para subir el archivo a un vault
    Write-EventLog -LogName Application -Source $logSource -EventId 6101 -EntryType Information -Message "Clave de recuperación respaldada localmente."
} else {
    Write-EventLog -LogName Application -Source $logSource -EventId 6102 -EntryType Information -Message "Clave de recuperación ya presente en AD."
}

Verificación

1. Evento de arranque – Abre el Visor de eventos → Aplicación → Filtra por Fuente: BitLockerDeploy. Deberías ver IDs 6000‑6002 y 6100‑6102 sin errores críticos.

2. Estado de cifrado – Ejecuta manage-bde -status C: en varios equipos aleatorios. Protection Status: Protection On y Percentage Encrypted ≥ 90 % indican que la fase de cifrado está completa.

3. Clave en AD – En un controlador de dominio, corre:

   dsquery * "CN=Computers,DC=contoso,DC=local" -filter "(objectClass=msFVE-RecoveryInformation)" -attr msFVE-RecoveryPassword
   

   Cada equipo debe aparecer con su clave de recuperación.

4. Firmware – Después de una actualización de BIOS, verifica que Secure Boot y TPM siguen habilitados en la BIOS y que el equipo arranca sin solicitar la clave de recuperación.

5. CMOS – Si el script de monitoreo genera alertas, revisa físicamente la batería del CMOS y reemplázala.

Notas adicionales

• Rollback de firmware – Algunas placas permiten crear una “snapshot” de la configuración del TPM antes de la actualización. Si el vendor lo soporta, úsalo para volver a un estado conocido en caso de lockout.

• Tiempo de cifrado – En redes con ancho de banda limitado, usa la opción -UsedSpaceOnly para cifrar solo el espacio ocupado inicialmente. Posteriormente, ejecuta manage-bde -resume para completar el proceso fuera de horario.

• Política de recuperación – Establece una política de retención de claves en AD (por ejemplo, 90 días) y programa una limpieza automática con Remove-ADObject.

• Auditoría – Añade una tarea programada que exporte los eventos de BitLockerDeploy a un archivo CSV y lo envíe a un SIEM. Así tendrás trazabilidad completa.

• Equipos con discos híbridos (SSD+HDD) – Ejecuta el script por separado para cada volumen (C:, D:) y verifica que el TPM solo protege el volumen del sistema; los datos en discos secundarios pueden usar -EncryptionMethod XtsAes128 para reducir tiempo.

Con este enfoque, puedes escalar la protección de datos mediante BitLocker sin depender de una solución MDM completa, manteniendo control total sobre el proceso, la visibilidad y la resiliencia frente a actualizaciones de firmware o fallos de CMOS.