Cómo diseñar una estrategia 3‑2‑1 para backup y recuperación de Active Directory

Problema

Mantener una infraestructura con más de 20 controladores de dominio (DC) virtualizados y garantizar que, ante un compromiso o una falla catastrófica, el directorio activo pueda restaurarse rápidamente es un reto constante. La mayoría de los equipos intentan seguir la regla 3‑2‑1: tres copias, en dos medios diferentes, una fuera del sitio. En entornos híbridos (Hyper‑V, VMware, Azure) surge la duda sobre:

• Cuántas capas de respaldo son realmente necesarias.
• Si el software de backup debe estar unido al AD.
• Cuál es la mejor forma de almacenar copias “frías” (cold tier) sin inflar costos.
• Qué procesos de recuperación probar y con qué cuentas.

El problema no es solo técnico; es de planificación, validación y de evitar un punto único de falla que pueda colapsar toda la estrategia.

Causa

1. Dependencia de un único repositorio
   Cuando el servidor de backup (por ejemplo, Dell Avamar) está integrado al AD y el propio AD se ve comprometido, el atacante puede borrar o cifrar los respaldos.

2. Falta de separación entre copia de imagen y estado del sistema
   Respaldar solo la VM puede no capturar cambios críticos del AD (USN, SYSVOL) si la VM está apagada o en un estado inconsistente.

3. Almacenamiento “frío” mal dimensionado
   Usar Azure Blob sin una política de ciclo de vida adecuada genera costos inesperados y, a veces, latencia al recuperar datos críticos.

4. Pruebas de recuperación insuficientes
   Sin un plan de pruebas en red aislada, los equipos descubren en producción que la restauración de GPO o la reactivación del AD Recycle Bin fallan por permisos o por falta de cuentas de servicio válidas.

5. Cuentas de servicio no verificadas
   La cuenta de administrador local del DC y la cuenta de backup son a menudo la única validada; sin pruebas de otras cuentas (por ejemplo, una cuenta de servicio de replicación), la recuperación puede quedar bloqueada.

Solución

1. Arquitectura de respaldo de múltiples capas

Desacoplar el servidor de backup del AD

• Crea una cuenta de servicio local en el servidor de backup, no un dominio.
• Usa Kerberos constrained delegation o credentials stored in a vault (HashiCorp Vault, Azure Key Vault) para que el backup pueda autenticarse contra el DC sin pertenecer al dominio.
• Mantén la conectividad de red (puertos 389/636, 3268/3269) pero sin confianza directa.

Configuración de Azure Blob “cold tier”

1. Crea un contenedor con access tier = Cool.
2. Define una Lifecycle Management Policy que mueva objetos a Archive a los 30‑60 días.
3. Habilita soft delete (30 días) para proteger contra borrados accidentales.

Esto mantiene los costos bajo control: el primer GB en Cool cuesta ~ 0.01 USD/mes, mientras que Archive es ~ 0.001 USD/GB/mes.

2. Proceso de recuperación estructurado

1. Recuperación de una única GPO

   • Usa Backup-GPO y Import-GPO en un DC de pruebas.
   • Verifica que SYSVOL\Policies y la base de datos de GPO estén sincronizadas.

2. Restauración de un DC completo (Bare‑Metal)

   • Arranca la VM desde un ISO de Windows Server (modo WinPE).
   • Ejecuta wbadmin start systemstaterecover -version:<fecha> apuntando al backup de Avamar.
   • Después de la restauración, permite la replicación automática con los demás DC.

3. Recuperación del AD Recycle Bin

   • En un DC de pruebas, ejecuta Restore-ADObject -Identity <GUID> para validar que los objetos borrados pueden revivirse.

4. Validación de cuentas de servicio

   • Asegúrate de que la cuenta de backup, la cuenta de replicación y la cuenta de administrador local tengan passwords no expirados y delegación adecuada.
   • Prueba un nltest /sc_verify:<dominio> desde una máquina aislada.

3. Automatización de pruebas

• Programa una tarea semanal (PowerShell) que:

  • Realice un snapshot de una VM de DC.
  • Exporta NTDS.dit a un archivo temporal.
  • Ejecuta Test-ADReplicationPerformance y guarda resultados.
  • Envía un informe a Slack o Teams.

• Usa Azure Automation o Runbooks para lanzar la copia a Blob y validar la política de ciclo de vida.

Cuándo aplicar esta solución

• Entornos con >10 DC y virtualizados en hipervisores mixtos.
• Requisitos de cumplimiento que exigen copias fuera del sitio (ISO 27001, NIST).
• Cuando el costo de Azure sea una preocupación y se necesite un tier “frío”.
• Si el AD es crítico y la empresa no puede permitirse tiempo de inactividad mayor a 4 horas.

No aplicar si:

• Solo hay 1‑2 DC y la replicación no es un factor; una sola capa de backup puede ser suficiente.
• El presupuesto no permite Azure; en ese caso, usa un NAS con replicación off‑site.

Código

# Exportar NTDS.dit y SYSVOL a un directorio temporal
mkdir C:\ADBackup\Temp
ntdsutil "activate instance NTDS" "ifm" "create full C:\ADBackup\Temp" q q

# Copiar a Azure Blob (requires Azure CLI installed)
az storage blob upload-batch \
  --destination ad-backup \
  --source C:\ADBackup\Temp \
  --account-name mystorageaccount \
  --tier Cool

Verificación

1. Integridad del archivo: Get-FileHash -Algorithm SHA256 C:\ADBackup\Temp\... y comparar con hash almacenado en Azure (metadata).
2. Restauración de prueba: Despliega una VM de Windows Server, monta el backup y ejecuta wbadmin start systemstaterecover -version:<timestamp> -backuptarget:C:\ADBackup\Temp.
3. Reconciliación de replicación: En el DC restaurado, corre repadmin /replsummary y verifica que no haya errores.
4. Validación de GPO: Get-GPO -All | Where-Object {$_.DisplayName -like "*Test*"} | Restore-GPO -Path C:\GPOBackup.

Si todos los pasos completan sin errores, la estrategia está lista para producción.

Notas adicionales

• Rotación de contraseñas: Usa un gestor de secretos para rotar la cuenta de backup cada 90 días; evita contraseñas estáticas.
• Seguridad del canal: Asegúrate de que la transferencia a Azure use HTTPS y, si es posible, Private Link para evitar tráfico por internet.
• Documentación viva: Mantén un wiki con los pasos de recuperación y la lista de cuentas críticas; actualízalo cada trimestre.
• Monitorización: Configura alertas en Azure Monitor para notificar cuando el cool tier supera un umbral de uso o cuando una política de ciclo de vida falla.

Con una arquitectura de capas, pruebas automatizadas y una gestión cuidadosa de credenciales, la estrategia 3‑2‑1 para Active Directory se vuelve robusta, económica y verificable.