ALERTA CRÍTICA: Tu Active Directory en colapso por restaurar un DC desde snapshot.

El escenario que todo administrador teme
Has perdido un controlador de dominio. Alguien dice:
Tenemos una snapshot de hace unos días, ¿por qué no restaurarla y listo?

Y ahí comienza el verdadero desastre.

En menos de 24 horas, los problemas aparecen:

• Usuarios que no pueden iniciar sesión.
• Errores de Kerberos inexplicables.
• Replicación completamente colapsada.
• La confianza del dominio empieza a fallar.
• Los administradores entran en pánico.
  
  La autopsia del desastre: ¿Qué ocurrió realmente?
  
  Como dice mi colega AMT, este es un «evento conocido» pero sorprendentemente común:
  
  Se pierde un controlador de dominio por fallo de hardware, corrupción, etc.
• Un administrador bien intencionado (pero mal informado) restaura una snapshot o backup antiguo.
  
  
• El Active Directory entra en conflicto severo:
  
  • Dos objetos de DC con idéntico nombre.
  • Mismo objectGUID, pero diferentes USN (números de secuencia de actualización).
  • Inconsistencia en DRS (Directory Replication Service).
  • El servicio KDC se vuelve inestable.
  • Se produce una «divergencia de base de datos» irreparable.
    
    
• La verdadera raíz del problema
  No se trata de un error técnico, sino de un error de procedimiento crucial: La metadata del controlador de dominio fallido nunca fue limpiada antes de la «restauración».
  Esto es equivalente a intentar reinjertar un órgano muerto en un cuerpo: el rechazo es inevitable.
  
  
• El procedimiento correcto que DEBES seguir
• Cuando un DC muere, sigue estos pasos en orden estricto:
  
  
• 1. Declaración formal de muerte
• Asume que está muerto. Sin excepciones.
• Aísla el servidor fallido de la red inmediatamente.
• No permitas que nadie lo encienda «para ver si funciona».
  
  
• 2. Limpieza forense obligatoria
• Conecta a un DC funcional y ejecuta:
• ntdsutil
• ejecuta el procedimiento conocido de ntdsutil 
•  
• 3. Limpieza completa del ecosistema AD
• Elimina el objeto del DC caído en «Active Directory Sites & Services».
• Elimina su cuenta de equipo del contenedor «Domain Controllers».
• Verifica que no queden referencias en DNS (registros A, SRV).
• Comprueba que los roles FSMO se han trasladado correctamente.
  
  
• 4. Verificación del estado de replicación
• Antes de cualquier nueva acción:
• repadmin /replsummary
• repadmin /showrepl * /csv > repl-status.csv
• Get-ADReplicationPartnerMetadata -Target * -Scope Domain | Format-Table.
  
  
• 5. Solo entonces:
• Promueve un nuevo DC con nombre DIFERENTE
• O restaura el DC mediante los mecanismos nativos de AD DS que gestionan el USN rollback.
  
  
• Regla de oro:
• Nunca restaures una snapshot de un DC como si fuera un servidor de archivos normal.
• Active Directory no es una simple base de datos, es un sistema distribuido con:
• Relojes lógicos USN para controlar la replicación.
• Números de versión incrementales para cada objeto.
• Marcas de tiempo de modificación de alta precisión.
• Servicio de notificación de cambios (DirSync).
  
  
• Consejo de profesional:
• Documenta un runbook de «declaración de muerte y limpieza de DC» y ensáyalo en tu laboratorio. Cuando ocurra la emergencia, no improvisarás.
• «La restauración sin limpieza previa no es un rescate, es plantar una bomba de tiempo en tu directorio».
  
  
• ¿Qué experiencias has tenido?
• ¿Has sufrido un caos similar por no limpiar metadata tras perder un DC?
• ¿Utilizas ntdsutil como parte de tus procedimientos estándar?
• ¿Qué otros escenarios de recuperación de AD te han dado dolores de cabeza?
• Comparte tu experiencia en los comentarios.