Problema

Muchas organizaciones que migran a Azure mantienen una red de sucursales con controladores de dominio (DC) locales. Con el tiempo, el coste de operar y actualizar esos DCs supera el beneficio, y el objetivo pasa a ser centralizar la autenticación en los data‑centers y en Azure. El reto es retirar los DCs de las oficinas sin que los usuarios noten interrupciones, sin perder servicios dependientes de DNS o Kerberos y sin que la latencia de autenticación se vuelva intolerable, sobre todo en sucursales con cientos de usuarios.

Causa

Los principales factores que complican la consolidación son:

  1. Dependencias de DNS – Los clientes suelen apuntar al DC local como servidor DNS primario. Si el registro A del controlador desaparece antes de que los clientes tengan una ruta alternativa, la resolución de nombres críticos (incluido el propio dominio) falla.
  2. Kerberos y tickets de servicio – Los tickets emitidos por un DC desaparecen cuando ese DC se despromueve. Servicios que almacenan tickets en caché pueden seguir intentando validar contra el DC retirado.
  3. GPO y scripts de inicio – Algunas políticas están vinculadas a sitios de AD que incluyen solo los DCs de la sucursal. Al eliminar los controladores, la aplicación de esas GPO puede retrasarse o fallar.
  4. DHCP y opciones de red – En entornos donde el DHCP entrega la dirección del DC como DNS, la eliminación del controlador deja a los clientes sin servidor DNS válido.
  5. Aplicaciones con dependencia directa – Software de gestión de impresoras, sistemas de tickets o bases de datos a veces usan la IP del DC como endpoint de autenticación.
  6. Latencia de red – Con enlaces SD‑WAN de 500 Mbps, la latencia típica ronda los 10‑30 ms. En oficinas con 800 usuarios, la carga de autenticación simultánea puede saturar el enlace si no se planifica el tráfico adecuadamente.

Solución

1. Preparar la infraestructura central

  • Asegurar redundancia: Al menos dos DCs en cada data‑center y dos en Azure. Replicar todos los roles FSMO y habilitar la replicación de SYSVOL entre ellos.
  • DNS global: Configurar zonas de AD integradas en los DCs centrales y habilitar la zona de “Conditional Forwarders” para que los controladores de sucursal apunten a los servidores centrales antes de ser retirados.
  • Sitios y subredes: Verificar que cada bloque de IP de sucursal esté asignado al sitio correcto en AD Sites and Services. Añadir los DCs centrales como “Bridgehead Servers” para ese sitio.

2. Cambiar la configuración de clientes

  • DNS primario/alternativo: En el DHCP de la sucursal, cambiar la opción 006 (DNS Servers) para que el primer servidor sea un DC central y el segundo sea otro DC central. Mantener el antiguo DC como “fallback” durante 48 h.
  • Validar la propagación: Ejecutar ipconfig /flushdns y nslookup <nombre_del_dominio> desde varios equipos para confirmar que la resolución usa los nuevos servidores.

3. Despromover DCs de forma controlada

  1. Mover FSMO si corresponde: Si el controlador a retirar posee algún rol FSMO, transferirlo a un DC central con ntdsutil.
  2. Desactivar temporalmente: Apagar la interfaz de red del DC y observar que los clientes siguen autenticándose sin errores durante 2 h.
  3. Dempromote: Ejecutar dcpromo /unattend /ForceRemoval o usar Server Manager → Remove Roles and Features → Active Directory Domain Services. Confirmar que la replicación se completa (repadmin /replsummary).
  4. Eliminar referencias DNS: Borrar los registros A y PTR del DC retirado en la zona DNS central. Verificar que no queden “stale” con dcdiag /test:DNS.

4. Monitoreo post‑democión

  • Eventos de seguridad: Filtrar el log de eventos 4624/4625 en los DCs centrales para detectar aumentos de fallos de inicio de sesión.
  • Rendimiento de autenticación: Medir el tiempo de respuesta de Kerberos con klist y kerbtray. Un aumento superior a 150 ms en la sucursal indica congestión.
  • Revisión de GPO: Ejecutar gpresult /h reporte.html en máquinas representativas y confirmar que las políticas se aplican sin retrasos.

5. Optimizar latencia

  • Cache de autenticación: Habilitar “Read‑Only Domain Controllers” (RODC) en la sucursal si la latencia supera los 100 ms o si la carga de autenticación es alta. Un RODC local reduce la necesidad de viajes a Azure sin requerir un DC completo.
  • QoS en SD‑WAN: Priorizar tráfico de puerto 88 (Kerberos) y 389/636 (LDAP) en la política de calidad de servicio. Esto evita que la replicación de archivos o video saturen la autenticación.
  • Balanceo de carga DNS: Configurar round‑robin en la zona DNS para distribuir consultas entre los DCs centrales.

Cuándo aplicar esta solución

  • Escenarios válidos: Redes con sucursales que disponen de enlaces de al menos 100 Mbps, donde la latencia media sea <30 ms y exista al menos un DC central con replicación saludable.
  • Síntomas que indican necesidad: Incremento de tickets de “cannot locate domain controller”, fallos de GPO en máquinas de sucursal, o alta carga de CPU en los DCs locales.
  • Exclusiones: Oficinas aisladas sin conectividad constante a la red corporativa, o entornos donde aplicaciones críticas dependen de la IP fija del DC local (ej. impresoras que usan LDAP directamente). En esos casos, mantener al menos un RODC o un DC de solo DNS.

Código

# Verificar replicación antes de democión
repadmin /replsummary

# Transferir rol FSMO (ejemplo: Schema Master)
ntdsutil
roles
connections
connect to server <DC-central>
quit
transfer schema master
quit
quit

# Despromover DC de forma silenciosa
dcpromo /unattend /ForceRemoval

Verificación

  1. DNS: nslookup -type=SRV _ldap._tcp.dc._msdcs.<dominio> debe devolver solo los DCs centrales.
  2. Kerberos: klist -li 0x3e7 en una máquina cliente muestra tickets emitidos por los DCs centrales.
  3. GPO: gpresult /r muestra la última política aplicada sin errores de “The processing of Group Policy failed”.
  4. Rendimiento: En el monitor de recursos del DC central, la columna “Kerberos Authentication” no supera el 5 % de CPU bajo carga normal.

Notas adicionales

  • Backup de SYSVOL: Antes de cualquier democión, copiar la carpeta \\<DC>\SYSVOL a un share seguro. En caso de errores de replicación, restaurar es mucho más rápido que reconstruir políticas.
  • Tiempo de propagación: La replicación de AD entre sitios suele tardar 15 min por defecto, pero con enlaces de alta latencia puede alargarse. Programar la democión fuera de horarios críticos y dejar una ventana de 24 h antes de retirar el segundo DC.
  • Documentar cambios: Mantener un registro de los cambios de DNS y de los roles FSMO transferidos facilita la auditoría y la recuperación ante incidentes.
  • Pruebas de carga: Simular 200 conexiones simultáneas con loadtest.exe contra el DC central ayuda a validar que el enlace SD‑WAN no se saturará cuando la sucursal pierda su controlador local.