Problema

Los entornos de Active Directory que superan cientos de miles de objetos y se extienden por varios continentes presentan síntomas típicos: latencias de replicación que escalan, tickets Kerberos que superan los límites de tamaño, políticas de grupo que tardan minutos en aplicarse y configuraciones de SYSVOL que divergen entre controladores de dominio. Cuando la gestión sigue basada en consolas MMC y scripts ad‑hoc, cualquier cambio menor se vuelve una operación de alto riesgo. La raíz del problema es la ausencia de un modelo declarativo que garantice que la infraestructura de identidad se mantenga coherente, reproducible y auto‑curable a medida que crece.

Causa

  1. Configuración manual de controladores – Cada DC se construye con pasos diferentes, lo que genera drift de versiones, parches y ajustes de seguridad.
  2. Falta de orquestación de replicación – No hay monitorización centralizada ni acciones automáticas para resolver “replication stalls”.
  3. Gestión de SYSVOL fuera de control – Cambios en scripts de inicio o GPO se aplican de forma puntual y pueden quedar desincronizados.
  4. Integración parcial con servicios cloud – Cuando se añaden Azure AD/Entra ID, los objetos de sincronización pueden quedar en estados intermedios sin una política clara.
  5. Escasez de pruebas de cambios – Sin pipelines de CI/CD para AD, cualquier despliegue de esquema o de OU se ejecuta directamente en producción.

Solución

Adoptar un enfoque Identity-as-Code basado en dos capas:

1. Declaración de la infraestructura con Terraform

  • Define cada controlador de dominio como un recurso azurerm_virtual_machine (o el equivalente en on‑prem) y enlázalo a un módulo que incluya:

    • Imagen base con los parches de seguridad más recientes.
    • Variables para roles (DC, Global Catalog, Read‑Only).
    • Dependencias explícitas entre sitios de AD para controlar el orden de creación.

  • Usa terraform state como fuente única de verdad; cualquier desviación se detecta con terraform plan.

2. Configuración del sistema con PowerShell DSC

  • Crea un Configuration que aplique:

    • Parámetros de sitio y subredes.
    • Política de replicación (Set-ADReplicationSite, Set-ADReplicationConnection).
    • Estado deseado de SYSVOL (File, Script resources) para evitar drift.
    • Hardening de Tier 0 (desactivación de SMBv1, auditoría de privilegios, etc.).

  • Publica el MOF en un repositorio Git; los agentes DSC en cada DC lo consumen en cada arranque o mediante Start-DscConfiguration -Wait -Force.

3. Canal de observabilidad y auto‑remediación

  • Prometheus + Node Exporter o Azure Monitor recogen métricas de NTDS (latencia, número de objetos pendientes).
  • Configura alertas que disparen un runbook de PowerShell (o un job de Azure Automation) que:
    • Reinicie el servicio NTFRS/DFS Replication si la cola supera X objetos.
    • Re‑aplique la configuración DSC si se detecta drift en SYSVOL.

4. Pipeline CI/CD

  • En GitHub Actions o Azure Pipelines:
    • terraform fmt && terraform validate.
    • terraform plan → revisión manual.
    • terraform apply en entorno de staging.
    • Invoke-DscResource contra un DC de prueba.
    • Si todo pasa, despliegue a producción.

5. Estrategia de transición a Entra ID

  • Mantén un Azure AD Connect con filtrado de OU y sincronización de atributos críticos.
  • Usa Conditional Access y Privileged Identity Management para limitar la exposición del dominio on‑prem.
  • Documenta la hoja de ruta de migración en un backlog de Azure Boards; cada fase se modela como un módulo Terraform independiente.

Cuándo aplicar esta solución

  • Síntomas: replicación lenta, errores de Kerberos “KRB_AP_ERR_MODIFIED”, GPO que no se aplican uniformemente, drift de SYSVOL entre DCs.
  • Entorno: más de 10 000 objetos, al menos 3 sitios geográficos, presencia de controladores híbridos (on‑prem + Azure).
  • No aplicable: entornos con menos de 500 objetos y un único sitio, donde la sobrecarga de IaC supera los beneficios operacionales.

Código

# Terraform: módulo básico para un DC en Azure
module "dc_us_east" {
  source               = "./modules/dc"
  name                 = "DC-USEAST-01"
  location             = "East US"
  vm_size              = "Standard_D4s_v3"
  subnet_id            = azurerm_subnet.dc_subnet.id
  admin_username       = var.admin_user
  admin_password       = var.admin_pass
  ad_domain_name       = var.ad_domain
  site_name            = "USEAST"
  is_global_catalog    = true
}

# PowerShell DSC: configuración de un controlador
Configuration DCConfig {
    Import-DscResource -ModuleName xActiveDirectory

    Node $AllNodes.Where{ $_.Role -eq 'DC' }.NodeName {
        WindowsFeature ADDS-Domain-Controller {
            Ensure = "Present"
            Name   = "AD-Domain-Services"
        }

        xADDomainController DC {
            DomainName          = $Node.DomainName
            SiteName            = $Node.SiteName
            Credential          = $Node.Credential
            SafemodeAdministratorPassword = $Node.SafemodePassword
            DependsOn           = "[WindowsFeature]ADDS-Domain-Controller"
        }

        xADReplicationConnection Replication {
            SourceDC      = $Node.NodeName
            DestinationDC = $Node.PeerDC
            ReplicationSchedule = "24x7"
            Ensure        = "Present"
        }

        File SYSVOLSync {
            DestinationPath = "C:\\Windows\\SYSVOL\\sysvol"
            SourcePath      = "C:\\Config\\SYSVOLTemplate"
            Ensure          = "Present"
            Type            = "Directory"
            Recurse         = $true
        }
    }
}

Verificación

  1. Ejecuta terraform plan y confirma que no aparecen cambios inesperados.
  2. En cada DC, verifica que el MOF está aplicado: Get-DscConfigurationStatus.
  3. Comprueba la salud de la replicación: repadmin /replsummary.
  4. Revisa que el contenido de SYSVOL coincide con el template: robocopy /L /MIR C:\Config\SYSVOLTemplate C:\Windows\SYSVOL\sysvol.
  5. En Azure Monitor, asegura que las alertas de “Replication Queue > 1000” están activas y que el runbook se ejecuta sin errores.

Notas adicionales

  • Versionado de módulos: usa tags semánticas en Git para evitar que un terraform apply inesperado introduzca cambios no probados.
  • Seguridad de credenciales: almacena contraseñas de administrador y Safemode en Azure Key Vault; referencia los secretos en Terraform mediante azurerm_key_vault_secret.
  • Pruebas de carga: antes de escalar a nuevos sitios, simula la replicación con repadmin /showrepl y ajusta los intervalos de KCC.
  • Rollback: si una actualización de esquema falla, restaura el estado anterior con terraform state rollback y vuelve a aplicar el MOF anterior.
  • Documentación viva: genera automáticamente diagramas de topología con graphviz a partir del archivo terraform graph.

Esta metodología permite que equipos de infraestructura traten el directorio como código, reduzcan el tiempo de inactividad y mantengan la consistencia en entornos de identidad que abarcan miles de sucursales y nubes híbridas.