Restauración y recuperación de un controlador de dominio local corrupto

Cuando un controlador de dominio se corrompe o se restaura mal, el susto es mayúsculo: los inicios de sesión fallan, las GPO dejan de aplicarse y la replicación se rompe sin dar apenas pistas. La buena noticia es que hay procedimientos claros para recuperar un DC físico o virtual, siempre que se respeten las formas admitidas de copia de seguridad y restauración.

En entornos Windows Server modernos, la restauración de un controlador de dominio requiere entender bien conceptos como estado del sistema, restauración autoritativa/no autoritativa, SYSVOL, DFSR/FRS y reversiones de USN. Si estos temas se atacan con prisas o con herramientas de imagen no compatibles, el resultado puede ser un bosque lleno de incoherencias silenciosas muy difíciles de diagnosticar.

Por qué es crítico proteger y recuperar correctamente un controlador de dominio

Active Directory es el corazón de la autenticación y autorización en un dominio Windows: almacena usuarios, equipos, grupos, relaciones de confianza, políticas de grupo, certificados y otros elementos críticos. Esta información reside principalmente en la base de datos Ntds.dit, los archivos de registro asociados y la carpeta SYSVOL, entre otros componentes que forman el llamado “estado del sistema”.

El estado del sistema incluye, entre otros, archivos de registro y datos de Active Directory, el Registro de Windows, el volumen de sistema, SYSVOL, base de datos de certificados si existe CA, IIS metabase, archivos de arranque y componentes protegidos del sistema operativo. Por eso, cualquier estrategia seria de continuidad de negocio debe contemplar copias de seguridad periódicas del estado del sistema de cada DC.

Cuando se produce una corrupción real de la base de datos de AD, un fallo grave en la replicación o un problema de permisos sobre SYSVOL, el controlador de dominio puede dejar de procesar consultas, no arrancar los servicios de Directorio Activo o desencadenar errores en cascada en todo el bosque. En estos casos, la recuperación rápida y correcta marca la diferencia entre una incidencia seria y un desastre prolongado.

Antes de lanzarse a restaurar, es clave distinguir entre un problema real de base de datos y otros fallos más mundanos. Muy a menudo, la causa está en DNS, cambios de red, firewalls o rutas modificadas con herramientas como comando netsh, de modo que conviene descartar primero estos factores antes de tocar la base de datos de AD.

Herramientas básicas de diagnóstico y control de replicación

Ante síntomas de corrupción o fallos de replicación, el primer paso sensato es comprobar con herramientas nativas el estado del entorno. DCDiag, Repadmin, ReplMon (en versiones antiguas) y el Visor de eventos son tus mejores aliados antes de plantearte restauraciones agresivas.

Con DCDiag se realiza un chequeo general de todos los controladores de dominio, identificando problemas de replicación, DNS, servicios de AD DS, etc. Repadmin permite ver el estado de la replicación, los socios de replicación, marcas de agua de USN y detectar objetos persistentes. En versiones más antiguas de Windows, ReplMon ofrecía una vista gráfica de los errores de replicación dentro del dominio.

Además de estas herramientas, es esencial revisar el Visor de eventos de “Servicios de directorio” y “Replicación DFS”. Eventos como el 467 y 1018 apuntan a corrupción real de la base de datos, mientras que eventos 1113/1115/1114/1116 se relacionan con habilitar o deshabilitar replicación de entrada/salida.

Si se requiere aislar temporalmente un DC sospechoso para evitar que propague corrupción, podemos deshabilitar replicación de entrada y salida con Repadmin:

repadmin /options DCNAME +DISABLE_INBOUND_REPL
repadmin /options DCNAME +DISABLE_OUTBOUND_REPL

Y para restaurar la replicación a la normalidad, bastaría con quitar esas opciones:

repadmin /options DCNAME -DISABLE_INBOUND_REPL
repadmin /options DCNAME -DISABLE_OUTBOUND_REPL

Copias de seguridad admitidas del estado del sistema en controladores de dominio

Para poder recuperar un DC con garantías, es imprescindible contar con copias de seguridad del estado del sistema realizadas con herramientas compatibles con Active Directory. Estas herramientas utilizan las API de copia de seguridad y restauración de Microsoft y el Servicio de instantáneas de volumen (VSS) de forma soportada.

Entre las soluciones más habituales están Windows Server Backup, soluciones de terceros integradas con VSS (como NAKIVO, Backup Exec y otras), o utilidades más antiguas como Ntbackup en Windows 2000/2003. En todos los casos, deben respetar las API de AD para garantizar la coherencia de la base de datos y sus réplicas tras la restauración.

En Windows Server 2012 y posteriores aparece una novedad importante: Hyper-V Generation ID (GenID). Este identificador permite que un DC virtual detecte que su disco se ha revertido a un punto anterior en el tiempo. Cuando esto ocurre, AD DS genera un nuevo InvocationID y trata la situación como si se hubiera restaurado desde una copia de seguridad correcta, notificando a sus socios de replicación, lo que permite reescribir con seguridad sin caer en una reversión de USN.

Es fundamental respetar la duración de la lápida (tombstone lifetime), que marca hasta cuándo se puede usar una copia de seguridad de estado del sistema sin riesgo de resucitar objetos borrados hace demasiado tiempo. Normalmente son 180 días en versiones modernas, y se recomienda hacer copias de seguridad al menos cada 90 días para mantener margen suficiente.

Métodos no admitidos que provocan reversiones de USN

Una de las causas más peligrosas de incoherencias silenciosas en Active Directory es la reversión de USN (USN rollback). Esta situación se produce cuando se revierte el contenido de la base de datos de AD mediante una técnica no soportada, sin que se restablezca el InvocationID ni se notifique a los socios de replicación.

El escenario típico es arrancar un DC a partir de una imagen de disco o snapshot de máquina virtual tomada en el pasado, sin usar una restauración de estado del sistema compatible. O copiar el archivo Ntds.dit directamente, usar programas de imagen como Ghost, arrancar desde un espejo de disco roto o reaplicar una instantánea de almacenamiento a nivel de cabina.

En estos casos, el controlador de dominio sigue usando el mismo InvocationID de antes, pero su contador de USN local retrocede. Los demás DC recuerdan haber recibido cambios hasta un USN alto, así que cuando el DC revertido intenta enviar de nuevo USN ya reconocidos, sus socios creen estar al día y dejan de aceptar cambios concretos.

El resultado es que determinadas modificaciones (por ejemplo, creación de usuarios, cambios de contraseñas, altas de equipos, cambios de membresía de grupos, nuevos registros DNS) nunca se replican desde el DC restaurado hacia el resto, pero las herramientas de monitorización pueden no mostrar errores claros. Es un fallo silencioso extremadamente peligroso.

Para detectar estas situaciones, en controladores Windows Server 2003 SP1 y posteriores se registra el evento 2095 de Servicios de directorio cuando se detecta que un DC remoto envía USN ya confirmados sin cambio de InvocationID. Cuando esto sucede, el sistema pone en cuarentena al DC afectado, pausa Netlogon y evita que se sigan originando cambios que no podrían replicarse correctamente.

Como prueba forense adicional, puede consultarse en el Registro la clave HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters y el valor Dsa Not Writable. Si este valor está establecido (por ejemplo, 0x4), indica que el DC fue puesto en estado de no escritura por detección de reversión de USN. Modificar manualmente este valor para “arreglarlo” es totalmente no soportado y deja la base de datos en un estado incoherente permanente.

Estrategias generales ante corrupción o revertido de un controlador de dominio

La forma de proceder ante un DC corrupto o restaurado incorrectamente depende de varios factores: número de controladores de dominio en el dominio/bosque, disponibilidad de copias válidas del estado del sistema, presencia de otros roles (FSMO, CA, catálogo global) y alcance temporal del problema.

Si existen otros DC sanos en el dominio y no hay datos críticos exclusivos en el controlador de dominio dañado, la opción más rápida y limpia suele ser quitar ese DC y reconstruirlo. En cambio, si se trata del único controlador de dominio, o alberga roles y datos delicados, será necesario recurrir a una restauración más cuidadosa (autoritativa o no autoritativa).

En líneas generales, las opciones son:

• Despromocionar forzosamente el DC corrupto y retirarlo del dominio, seguida de limpieza de metadatos y, si procede, nueva promoción.
• Restaurar desde una copia de seguridad válida del estado del sistema, ya sea en modo autoritativo o no autoritativa.
• Reconstruir el DC a partir de otro mediante IFM (Install From Media), cuando no hay copia reciente pero sí otros DC correctos.
• Usar una instantánea VHD de un DC virtual, aplicando los pasos adicionales para marcar la base de datos como restaurada desde copia (Base de datos restaurada a partir de la copia de seguridad = 1) y garantizar que se genera nuevo InvocationID.

Si se sospecha claramente de una reversión de USN (por ejemplo, tras restaurar una VM desde snapshot sin seguir las prácticas recomendadas) y aparece el evento 2095, lo más sensato suele ser retirar ese DC del servicio y no intentar “apañarlo” in situ, salvo que se pueda volver a un backup de estado del sistema soportado tomado antes de la reversión.

Despromoción forzada y limpieza de metadatos

Cuando un controlador de dominio está tan dañado que no puede degradarse de forma normal, o se ha restaurado incorrectamente y se quiere evitar que propague problemas, es posible recurrir a una despromoción forzada.

En versiones más antiguas, esta operación se realizaba con dcpromo /forceremoval, lo que elimina el rol de AD DS sin intentar replicar los cambios al resto del bosque. En entornos modernos el asistente ha cambiado, pero el concepto es el mismo: sacar al DC problemático de la topología de AD sin que participe en más replicaciones.

Tras degradar forzosamente, es obligatorio ejecutar desde un DC sano una limpieza de metadatos mediante la herramienta Ntdsutil. Este proceso elimina de la base de datos de AD todas las referencias al DC eliminado (objetos de NTDS Settings, referencias DNS, etc.), de modo que no queden restos “fantasma” que confundan la replicación.

Si el controlador degradado tenía roles FSMO (PDC Emulator, RID Master, Schema Master, etc.), habrá que transferir o seizes esos roles a otro DC antes o después de la degradación, según el caso. Posteriormente se puede reinstalar el sistema operativo en ese servidor y promocionarlo de nuevo como DC, ya limpio.

Restauración no autoritativa vs autoritativa en Active Directory

Cuando se dispone de una copia válida del estado del sistema, la recuperación de AD puede hacerse en dos sabores: no autoritativa y autoritativa. Entender la diferencia es clave para no perder cambios recientes ni replicar datos obsoletos.

En una restauración no autoritativa, se devuelve el DC a un punto anterior, pero una vez que arranca, los demás controladores de dominio se consideran la referencia. Es decir, tras el arranque, el DC restaurado solicita replicación entrante y actualiza su base de datos con los cambios que falten desde el resto de DC. Esta opción es ideal cuando hay otros controladores sanos y queremos que el restaurado se ponga al día con ellos.

En una restauración autoritativa, en cambio, se indica explícitamente que los datos restaurados son los que deben prevalecer sobre lo que tengan los demás DC. Esto implica que, tras la restauración, los objetos recuperados llevarán un número de versión mayor para forzar que se repliquen desde ese DC hacia el resto del dominio. Es la elección adecuada cuando hemos borrado objetos u OU por error, o queremos devolver el contenido de SYSVOL y GPO a un estado anterior y que se replique.

Un detalle importante es que la restauración autoritativa no tiene por qué ser de toda la base de datos. Con la utilidad Ntdsutil se pueden marcar como autoritativos objetos individuales, subárboles (por ejemplo, una OU) o el dominio completo. Esto ofrece mucha flexibilidad para, por ejemplo, recuperar sólo un usuario, un grupo, una OU o el subárbol dc=miempresa,dc=local.

Procedimiento general de restauración del estado del sistema en un DC

El esquema básico para restaurar el estado del sistema de un DC (ya sea físico o virtual) con herramientas compatibles es siempre similar: arranque en Modo de restauración de servicios de directorio (DSRM), restauración con la herramienta de backup y reinicio.

De forma resumida, los pasos típicos para un controlador de dominio virtual serían:

1. Arrancar la máquina virtual en el Administrador de arranque de Windows (normalmente pulsando F5/F8 durante el inicio). Si la VM está gestionada por un hipervisor, puede que sea necesario pausar la máquina para lograr capturar la pulsación.
2. En las opciones de arranque avanzadas, seleccionar Modo de restauración de servicios de directorio (Directory Services Restore Mode). Este modo arranca el servidor sin montar la base de datos de AD de forma funcional.
3. Iniciar sesión con la cuenta de administrador de DSRM definida durante la promoción original del DC (no con una cuenta de administrador de dominio estándar).
4. Ejecutar la herramienta de copia de seguridad utilizada (Windows Server Backup, NAKIVO u otra compatible) y elegir la restauración del estado del sistema para el punto de copia deseado.
5. Completar el asistente de restauración y reiniciar el DC en modo normal. En restauración no autoritativa, el servidor iniciará la replicación para ponerse al día con los demás DC.

Cuando hablamos de productos de backup de terceros, como NAKIVO Backup & Replication, su modo “app-aware” es capaz de reconocer que la máquina que se está recuperando es un DC y ajustar automáticamente el proceso para preservar coherencia de AD. En la mayoría de escenarios con varios controladores, una recuperación completa en modo no autoritativo es suficiente.

Restauración autoritativa con Ntdsutil

Si se desea que los cambios del controlador de dominio restaurado tengan prioridad sobre el resto, es necesario añadir un paso extra tras la restauración no autoritativa: usar Ntdsutil para marcar objetos como autoritativos.

El flujo simplificado sería:

1. Restaurar el estado del sistema de forma estándar y dejar el servidor aún en modo DSRM (no reiniciar todavía en modo normal).
2. Abrir un símbolo del sistema con privilegios elevados y ejecutar ntdsutil.
3. Activar la instancia de AD con activate instance ntds.
4. Entrar en el contexto de restauración autoritativa con authoritative restore.
5. Usar comandos como restore object <DN_objeto> o restore subtree <DN_subarbol>, donde DN es el nombre distinguido del objeto o subárbol a restaurar de forma autoritativa.
6. Confirmar la operación y, una vez finalizada, reiniciar el DC en modo normal para que los objetos marcados se repliquen con prioridad al resto del dominio.

Este tipo de restauración requiere mucha cautela. Si se restaura autoritativamente todo el dominio y la copia es antigua, se corre el riesgo de perder cambios legítimos realizados después del backup (por ejemplo, altas de usuarios, cambios de contraseña o modificaciones de grupos). Por eso, es habitual limitar la restauración autoritativa a los objetos o árboles estrictamente necesarios.

Restauración y recuperación de SYSVOL (FRS vs DFSR)

SYSVOL es una pieza clave del controlador de dominio: almacena scripts de inicio, políticas de grupo, plantillas de seguridad y otros recursos compartidos esenciales. Un fallo en sus permisos, corrupción de los archivos o problemas de replicación pueden dejar inservibles las GPO o provocar comportamientos erráticos en los clientes.

Dependiendo de la versión de Windows Server y del estado de la migración, SYSVOL puede estar replicado por FRS (File Replication Service) o por DFSR (Distributed File System Replication). El procedimiento para una restauración autoritativa de SYSVOL varía según cuál de los dos esté en uso.

Para determinarlo se puede comprobar en el Registro la clave HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalState. Si esta subclave existe y su valor es 3 (ELIMINADO), se está utilizando DFSR. Si no existe o su valor es distinto, estamos frente a un entorno que aún utiliza FRS.

En entornos con FRS, la recuperación autoritativa de SYSVOL suele implicar ajustar el valor Burflags en HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process a un valor concreto (por ejemplo, 212 decimal / 0xD4 hex) para indicar que ese DC es el origen autoritativo.

Si SYSVOL está replicado por DFSR, el proceso es algo más elaborado: implica usar ADSIEdit para modificar los objetos de suscripción de SYSVOL (atributos msDFSR-Enabled y msDFSR-Options) en el DC autoritativo y en los demás, forzar replicación de AD, ejecutar dfsrdiag pollad y confirmar en el registro de eventos la aparición de eventos 4114, 4602, 4614 y 4604 que certifican que SYSVOL ha sido inicializado y replicado correctamente.

Recuperación de controladores de dominio virtuales desde VHD

En entornos virtualizados es muy frecuente disponer de archivos VHD/VHDX de controladores de dominio. Si no se cuenta con una copia de seguridad de estado del sistema pero sí con un VHD “antiguo” funcional, es posible montar un nuevo DC a partir de dicho disco, aunque hay que hacerlo con mucho cuidado para no provocar una reversión de USN.

La recomendación es no iniciar directamente esa VM en modo normal. En su lugar, se debe arrancar con el VHD anterior en DSRM, abrir el Editor del Registro y navegar hasta HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters. Allí, es conveniente revisar el valor Recuento de restauraciones anteriores de DSA (si existe) y, sobre todo, crear un nuevo valor DWORD (32 bits) llamado Base de datos restaurada a partir de la copia de seguridad con valor 1.

Al marcar este valor, se indica a Active Directory que la base de datos se ha restaurado desde un backup, lo que fuerza la generación de un nuevo InvocationID al arrancar en modo normal. De este modo, los demás DC interpretan que se trata de una nueva instancia y ajustan correctamente sus marcas de agua de replicación, evitando el USN rollback.

Tras reiniciar el DC en modo normal, conviene revisar el Visor de eventos, en el registro de Servicios de directorio, buscando el evento 1109. Este evento confirma que se ha cambiado el atributo InvocationID del servidor y muestra el antiguo y el nuevo valor, así como el USN más alto en el momento de la copia de seguridad. Además, el valor de Recuento de restauraciones anteriores de DSA debería haberse incrementado en uno.

Si no aparecen estos eventos, o el recuento no se incrementa, hay que comprobar versiones y Service Packs del sistema operativo, ya que ciertos comportamientos de restauración dependen de parches concretos. En cualquier caso, siempre es aconsejable trabajar sobre una copia del VHD original, manteniendo una versión intacta por si hay que repetir el proceso.

Escenarios prácticos y recomendaciones adicionales

En la práctica, los problemas de corrupción o restauraciones incorrectas suelen aparecer en escenarios del día a día: modificaciones manuales de permisos en SYSVOL, intentos de actualizar plantillas ADMX/ADML, cambios en GPO que no se replican, etc. Es relativamente fácil provocar inconsistencias si se tocan a mano carpetas compartidas como SYSVOL\Policies sin respetar la replicación.

Ante un DC principal con replicación rota (tanto de datos de AD como de SYSVOL) y mensajes de monitorización del tipo “La base de datos se ha restaurado utilizando un procedimiento no admitido. Posible causa: reversión de USN”, lo prudente es:

• Verificar con dcdiag y repadmin el alcance de los errores y si hay “objetos persistentes”.
• Comprobar eventos 2095 y el valor Dsa Not Writable en el Registro.
• Valorar si es posible retirar ese DC y reconstruirlo (si hay otros tres o más DC sanos suele ser la mejor opción).
• Si es el único DC o crítico, plantear una restauración de estado del sistema desde backup compatible, idealmente reciente y dentro del periodo de tombstone.

En dominios con varios controladores, es muy recomendable que los DC sean lo más “puros” posible: sin roles adicionales ni datos de usuario locales. De este modo, si uno cae o se corrompe, se puede formatear y promocionar uno nuevo basándose en otro DC o mediante IFM, reduciendo mucho la complejidad de la recuperación.

Además, conviene recordar limitaciones como que las copias de estado del sistema sólo son válidas durante el periodo de tombstone (60, 90, 180 días según configuración) para evitar resucitar objetos borrados, y que las claves de equipo NTLM cambian cada 7 días. En restauraciones muy antiguas, es posible que haya que restablecer las cuentas de equipo problemáticas desde “Usuarios y Equipos de Active Directory” o incluso sacarlas y volver a unirlas al dominio.

Contar con procedimientos de copia de seguridad periódica del estado del sistema, documentar claramente los roles FSMO, catálogo global y topología de replicación, y probar alguna vez los pasos de restauración en un entorno de laboratorio, son inversiones de tiempo que ahorran muchos dolores de cabeza cuando llega el día en que un controlador de dominio se corrompe o alguien aplica una instantánea sin pensar.