Restauració i recuperació de controlador de domini local corrupte

Quan un controlador de domini es corromp o es restaura malament, l'ensurt és majúscul: els inicis de sessió fallen, les GPO deixen d'aplicar-se i la replicació es trenca sense a penes donar pistes. La bona notícia és que hi ha procediments clars per recuperar un DC físic o virtual, sempre que es respectin les formes admeses de còpia de seguretat i de restauració.

En entorns Windows Server moderns, la restauració d'un controlador de domini requereix entendre bé conceptes com estat del sistema, restauració autoritativa/no autoritativa, SYSVOL, DFSR/FRS i reversions de USN. Si aquests temes s'ataquen amb presses o eines d'imatge no compatibles, el resultat pot ser un bosc ple d'incoherències silencioses molt difícils de diagnosticar.

Per què és crític protegir i recuperar correctament un controlador de domini

Active Directory és el cor de l'autenticació i l'autorització en un domini Windows: emmagatzema usuaris, equips, grups, relacions de confiança, polítiques de grup, certificats i altres elements crítics. Aquesta informació resideix principalment a la base de dades Ntds.dit, els fitxers de registre associats i la carpeta SYSVOL, entre altres components que formen l'anomenat “estat del sistema”.

L'estat del sistema inclou, entre d'altres, fitxers de registre i dades d'Active Directory, el Registre de Windows, el volum de sistema, SYSVOL, base de dades de certificats si hi ha CA, IIS metabase, fitxers d'arrencada i components protegits del sistema operatiu. Per això qualsevol estratègia seriosa de continuïtat de negoci ha de contemplar còpies de seguretat periòdiques de l'estat del sistema de cada DC.

Quan es produeix una corrupció real de la base de dades d'AD, una fallada greu a la replicació o un problema de permisos sobre SYSVOL, el controlador de domini pot deixar de processar consultes, no arrencar els serveis de Directori Actiu o desencadenar errors en cascada a tot el bosc. En aquests casos, la recuperació ràpida i correcta marca la diferència entre una incidència seriosa i un desastre perllongat.

Abans de llançar-se a restaurar, és clau distingir entre un problema real de base de dades i altres errors més mundans. Molt sovint, la causa està en DNS, canvis de xarxa, firewalls o rutes modificades amb eines com comandament netsh, de manera que cal descartar primer aquests factors abans de tocar la base de dades d'AD.

Eines bàsiques de diagnòstic i control de replicació

Davant de símptomes de corrupció o errors de replicació, el primer pas assenyat és comprovar amb eines natives l'estat de l'entorn. DCDiag, Repadmin, ReplMon (en versions antigues) i el Visor d'esdeveniments són els teus millors aliats abans de plantejar-te restauracions agressives.

Amb DCDiag es realitza una revisió general de tots els controladors de domini, identificant problemes de replicació, DNS, serveis d'AD DS, etc. Repadmin permet veure l'estat de la replicació, els socis de replicació, les marques d'aigua d'USN i detectar objectes persistents. En versions més antigues de Windows, Replmon oferia una vista gràfica dels errors de replicació dins del domini.

A més d'aquestes eines, és essencial revisar el Visor d'esdeveniments de “Serveis de directori” i “Replicació DFS”. Esdeveniments com el 467 i el 1018 apunten a corrupció real de la base de dades, mentre que esdeveniments 1113/1115/1114/1116 es relacionen amb habilitar o deshabilitar replicació d'entrada/sortida.

Si cal aïllar temporalment un DC sospitós per evitar que propagui corrupció, podem desactivar la replicació d'entrada i sortida amb Repadmin:

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

I per restaurar la replicació a la normalitat, només caldria treure aquestes opcions:

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

Còpies de seguretat admeses de l'estat del sistema a controladors de domini

Per poder recuperar un DC amb garanties, és imprescindible comptar amb còpies de seguretat de l'estat del sistema fetes amb eines compatibles amb Active Directory. Aquestes eines utilitzen les API de còpia de seguretat i restauració de Microsoft i el Servei d'instantànies de volum (VSS) de manera suportada.

Entre les solucions més habituals hi ha Windows Server Backup, solucions de tercers integrades amb VSS (com NAKIVO, Backup Exec i altres), o utilitats més antigues com Ntbackup al Windows 2000/2003. En tots els casos, heu de respectar les API d'AD per garantir la coherència de la base de dades i les seves rèpliques després de la restauració.

Al Windows Server 2012 i posteriors apareix una novetat important: Hyper-V Generation ID (GenID). Aquest identificador permet que un DC virtual detecti que el vostre disc s'ha revertit a un punt anterior en el temps. Quan això passa, AD DS genera un nou InvocationID i tracta la situació com si s'hagués restaurat des d'una còpia de seguretat correcta, notificant als seus socis de replicació, cosa que permet reescriure amb seguretat sense caure en una reversió de USN.

És fonamental respectar la durada de la làpida (tombstone lifetime), que marca fins quan es pot fer servir una còpia de seguretat d'estat del sistema sense risc de ressuscitar objectes esborrats fa massa temps. Normalment són 180 dies en versions modernes, i es recomana fer còpies de seguretat almenys cada 90 dies per mantenir marge suficient.

Mètodes no admesos que provoquen reversions de USN

Una de les causes més perilloses d'incoherències silencioses a Active Directory és la reversió de USN (USN rollback). Aquesta situació es produeix quan es reverteix el contingut de la base de dades AD mitjançant una tècnica no suportada, sense que es restableixi l'InvocationID ni es notifiqui als socis de replicació.

L'escenari típic és arrencar un DC a partir d'una imatge de disc o snapshot de màquina virtual presa en el passat, sense utilitzar una restauració d'estat del sistema compatible. O copiar el fitxer Ntds.dit directament, fer servir programes d'imatge com Ghost, arrencar des d'un mirall de disc trencat o reaplicar una instantània d'emmagatzematge a nivell de cabina.

En aquests casos, el controlador de domini segueix usant el mateix InvocationID d'abans, però el vostre comptador de USN local retrocedeix. Els altres DC recorden haver rebut canvis fins a un USN alt, així que quan el DC revertit intenta enviar de nou USN ja reconeguts, els seus socis creuen que estan al dia i deixen d'acceptar canvis concrets.

El resultat és que determinades modificacions (per exemple, creació d'usuaris, canvis de contrasenyes, altes d'equips, canvis de membres de grups, nous registres DNS) mai no es repliquen des del DC restaurat cap a la resta, però les eines de monitorització poden no mostrar errors clars. És una fallada silenciosa extremadament perillosa.

Per detectar aquestes situacions, en controladors Windows Server 2003 SP1 i posteriors es registra el esdeveniment 2095 de Serveis de directori quan es detecta que un DC remot envia USN ja confirmats sense canvi d'InvocationID. Quan això passa, el sistema posa en quarantena el DC afectat, pausa Netlogon i evita que se segueixin originant canvis que no es podrien replicar correctament.

Com a prova forense addicional, pot consultar-se al Registre la clau HKLM\SYSTEM\CurrentControlSet\Serveis\NTDS\Parameters i el valor Dsa Not Writable. Si aquest valor està establert (per exemple, 0x4), indica que el DC va ser posat en estat de no escriptura per detecció de reversió de USN. Modificar manualment aquest valor per “arreglar-lo” és totalment no suportat i deixa la base de dades en un estat incoherent permanent.

Estratègies generals davant de corrupció o revertit d'un controlador de domini

La manera de procedir davant d'un DC corrupte o restaurat incorrectament depèn de diversos factors: nombre de controladors de domini al domini/bosc, disponibilitat de còpies vàlides de l'estat del sistema, presència d'altres rols (FSMO, CA, catàleg global) i abast temporal del problema.

Si hi ha altres DC sans al domini i no hi ha dades crítiques exclusives al controlador de domini danyat, l'opció més ràpida i neta sol ser treure aquest DC i reconstruir-lo. En canvi, si es tracta de l'únic controlador de domini, o allotja rols i dades delicades, caldrà recórrer a una restauració més curosa (autoritativa o no autoritativa).

En línies generals, les opcions són:

• Despromocionar forçosament el DC corrupte i retirar-lo del domini, seguida de neteja de metadades i, si escau, nova promoció.
• Restaurar des d'una còpia de seguretat vàlida de l'estat del sistema, ja sigui de manera autoritativa o no autoritativa.
• Reconstruir el DC a partir d'un altre mitjançant IFM (Install From Media), quan no hi ha còpia recent però sí altres DC correctes.
• Usar una instantània VHD d'un DC virtual, aplicant els passos addicionals per marcar la base de dades com a restaurada des de còpia (Base de dades restaurada a partir de la còpia de seguretat = 1) i garantir que es genera nou InvocationID.

Si se sospita clarament d'una reversió de USN (per exemple, després de restaurar una VM des de snapshot sense seguir les pràctiques recomanades) i apareix l'esdeveniment 2095, el més assenyat sol ser retirar aquest DC del servei i no intentar “apanyar-lo” in situ, tret que es pugui tornar a un backup d'estat del sistema suportat pres abans de la reversió.

Despromoció forçada i neteja de metadades

Quan un controlador de domini està tan malmès que no es pot degradar de forma normal, o s'ha restaurat incorrectament i es vol evitar que propagui problemes, és possible recórrer a una despromoció forçada.

En versions més antigues, aquesta operació es realitzava amb dcpromo /forceremoval, El que elimina el rol d'AD DS sense intentar replicar els canvis a la resta del bosc. En entorns moderns l'assistent ha canviat, però el concepte és el mateix: treure el DC problemàtic de la topologia d'AD sense que hi participi més replicacions.

Després de degradar forçosament, és obligatori executar des d'un DC sa una neteja de metadades mitjançant l'eina Ntdsutil. Aquest procés elimina de la base de dades AD totes les referències al DC eliminat (objectes de NTDS Settings, referències DNS, etc.), de manera que no quedin restes “fantasma” que confonguin la replicació.

Si el controlador degradat tenia rols FSMO (PDC Emulator, RID Master, Schema Master, etc.), caldrà transferir o seizes aquests rols a un altre DC abans o després de la degradació, segons el cas. Posteriorment es pot reinstal·lar el sistema operatiu en aquest servidor i promocionar-lo de nou com a DC, ja net.

Restauració no autoritativa vs autoritativa a Active Directory

Quan disposeu d'una còpia vàlida de l'estat del sistema, la recuperació d'AD es pot fer en dos sabors: no autoritativa i autoritativa. Entendre la diferència és clau per no perdre canvis recents ni replicar dades obsoletes.

En una restauració no autoritativa, es torna el DC a un punt anterior, però una vegada que arrenca, els altres controladors de domini es consideren la referència. És a dir, després de l'arrencada, el DC restaurat sol·licita replicació entrant i actualitza la base de dades amb els canvis que faltin des de la resta de DC. Aquesta opció és ideal quan hi ha altres controladors sans i volem que el restaurat es posi al dia amb ells.

En una restauració autoritativa, en canvi, s'indica explícitament que les dades restaurades són les que han de prevaldre sobre allò que tinguin els altres DC. Això implica que, després de la restauració, els objectes recuperats portaran un nombre de versió més gran per forçar que es repliquin des d'aquest DC cap a la resta del domini. És lelecció adequada quan hem esborrat objectes o OU per error, o volem tornar el contingut de SYSVOL i GPO a un estat anterior i que es repliqui.

Un detall important és que la restauració autoritativa no ha de ser de tota la base de dades. Amb la utilitat Ntdsutil es poden marcar com a autoritatius objectes individuals, subarbres (per exemple, una OU) o el domini complet. Això ofereix molta flexibilitat per, per exemple, recuperar només un usuari, un grup, una OU o el subarbre dc=la meva empresa,dc=local.

Procediment general de restauració de l'estat del sistema a un DC

L'esquema bàsic per restaurar l'estat del sistema d'un DC (tant si és físic com virtual) amb eines compatibles és sempre similar: arrencada a Mode de restauració de serveis de directori (DSRM), restauració amb l'eina de backup i reinici.

De manera resumida, els passos típics per a un controlador de domini virtual serien:

1. Arrancar la màquina virtual a l'Administrador d'arrencada de Windows (normalment prement F5/F8 durant l'inici). Si la VM està gestionada per un hipervisor, és possible que calgui pausar la màquina per aconseguir capturar la pulsació.
2. A les opcions d'arrencada avançades, seleccioneu Mode de restauració de serveis de directori (Directory Services Restore Mode). Aquest mode arrenca el servidor sense muntar la base de dades d'AD de manera funcional.
3. Inicieu sessió amb el compte d'administrador del DSRM definida durant la promoció original del DC (no amb un compte d'administrador de domini estàndard).
4. Executar l'eina de còpia de seguretat utilitzada (Windows Server Backup, NAKIVO o una altra compatible) i triar la restauració de l'estat del sistema per al punt de còpia desitjat.
5. Completar l'assistent de restauració i reiniciar el DC en mode normal. En restauració no autoritativa, el servidor iniciarà la replicació per posar-se al dia amb els altres DC.

Quan parlem de productes de backup de tercers, com Còpia de seguretat i replicació de NAKIVO, la seva manera “app-aware” és capaç de reconèixer que la màquina que s'està recuperant és un DC i ajustar automàticament el procés per preservar coherència d'AD. A la majoria d'escenaris amb diversos controladors, una recuperació completa en mode no autoritatiu és suficient.

Restauració autoritativa amb Ntdsutil

Si voleu que els canvis del controlador de domini restaurat tinguin prioritat sobre la resta, cal afegir un pas extra després de la restauració no autoritativa: utilitzar Ntdsutil per marcar objectes com a autoritatius.

El flux simplificat seria:

1. Restaurar l'estat del sistema de forma estàndard i deixar el servidor encara a mode DSRM (no reinicieu encara en mode normal).
2. Obrir un símbol del sistema amb privilegis elevats i executar ntdsutil.
3. Activar la instància d'AD amb activar instància ntds.
4. Entrar en el context de restauració autoritativa amb authoritative restore.
5. Usar ordres com restore object <DN_objeto> o restore subtree <DN_subarbol>, on DN és el nom distingit de l'objecte o subarbre a restaurar de manera autoritativa.
6. Confirmeu l'operació i, un cop finalitzada, reiniciar el DC en mode normal perquè els objectes marcats es repliquin amb prioritat a la resta del domini.

Aquest tipus de restauració requereix molta cautela. Si es restaura autoritativament tot el domini i la còpia és antiga, es corre el risc de perdre canvis legítims realitzats després del backup (per exemple, altes d'usuaris, canvis de contrasenya o modificacions de grups). Per això, és habitual limitar la restauració autoritativa als objectes o arbres estrictament necessaris.

Restauració i recuperació de SYSVOL (FRS vs DFSR)

SYSVOL és una peça clau del controlador de domini: emmagatzema scripts d'inici, polítiques de grup, plantilles de seguretat i altres recursos compartits essencials. Un error en els seus permisos, corrupció dels fitxers o problemes de replicació poden deixar inservibles les GPO o provocar comportaments erràtics en els clients.

Depenent de la versió del Windows Server i de l'estat de la migració, SYSVOL pot estar replicat per FRS (File Replication Service) o per DFSR (Distributed File System Replication). El procediment per a una restauració autoritativa de SYSVOL varia segons quin dels dos estigui en ús.

Per determinar-ho es pot comprovar al Registre la clau HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalState. Si aquesta subclau existeix i el valor és 3 (ELIMINAT), s'està utilitzant DFSR. Si no existeix o el seu valor és diferent, estem davant d'un entorn que encara fa servir FRS.

En entorns amb FRS, la recuperació autoritativa de SYSVOL sol implicar ajustar el valor Burflags en HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process a un valor concret (per exemple, 212 decimal/0xD4 hex) per indicar que aquest DC és l'origen autoritatiu.

Si SYSVOL està replicat per DFSR, el procés és una mica més elaborat: implica utilitzar ADSIEdit per modificar els objectes de subscripció de SYSVOL (atributs msDFSR-Enabled y msDFSR-Options) al DC autoritatiu i als altres, forçar replicació d'AD, executar dfsrdiag pollastre i confirmar al registre d'esdeveniments l'aparició de esdeveniments 4114, 4602, 4614 i 4604 que certifiquen que SYSVOL ha estat inicialitzat i replicat correctament.

Recuperació de controladors de domini virtuals des de VHD

En entorns virtualitzats és molt freqüent disposar de fitxers VHD/VHDX de controladors de domini. Si no es compta amb una còpia de seguretat d'estat del sistema però sí amb un VHD “antic” funcional, és possible muntar un nou DC a partir del disc, encara que cal fer-ho amb molt de compte per no provocar una reversió de USN.

La recomanació és no iniciar directament aquesta VM en mode normal. En el seu lloc, cal arrencar amb el VHD anterior a DSRM, obrir l'Editor del Registre i navegar fins HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters. Allí, és convenient revisar el valor Recompte de restauracions anteriors de DSA (si existeix) i, sobretot, crear un nou valor DWORD (32 bits) anomenat Base de dades restaurada a partir de la còpia de seguretat amb valor 1.

En marcar aquest valor, s'indica a Active Directory que la base de dades s'ha restaurat des d'un backup, cosa que força generar un nou InvocationID en arrencar en mode normal. D'aquesta manera, els altres DC interpreten que es tracta d'una instància nova i ajusten correctament les marques d'aigua de replicació, evitant l'USN rollback.

Després de reiniciar el DC en mode normal, convé revisar el Visor d'esdeveniments, al registre de Serveis de directori, buscant el esdeveniment 1109. Aquest esdeveniment confirma que l'atribut InvocationID del servidor s'ha canviat i mostra l'antic i el nou valor, així com l'USN més alt en el moment de la còpia de seguretat. A més, el valor de Recompte de restauracions anteriors de DSA s'hauria d'haver incrementat en un.

Si no apareixen aquests esdeveniments, o el recompte no s'incrementa, cal comprovar versions i Service Packs del sistema operatiu, ja que certs comportaments de restauració depenen de pegats concrets. En qualsevol cas, sempre és aconsellable treballar sobre una còpia del VHD original, mantenint una versió intacta per si cal repetir el procés.

Escenaris pràctics i recomanacions addicionals

A la pràctica, els problemes de corrupció o restauracions incorrectes solen aparèixer en escenaris del dia a dia: modificacions manuals de permisos a SYSVOL, intents d'actualitzar plantilles ADMX/ADML, canvis en GPO que no es repliquen, etc. És relativament fàcil provocar inconsistències si es toquen a mà carpetes compartides com SYSVOL\Policies sense respectar la replicació.

Davant d'un DC principal amb replicació trencada (tant de dades d'AD com de SYSVOL) i missatges de monitorització del tipus “S'ha restaurat la base de dades utilitzant un procediment no admès. Possible causa: reversió de USN”, el prudent és:

• Verificar amb dcdiag y repadmin l'abast dels errors i si hi ha “objectes persistents”.
• Comprovar esdeveniments 2095 i el valor Dsa Not Writable al Registre.
• Valorar si és possible retirar aquest DC i reconstruir-lo (si hi ha altres tres o més DC sans sol ser la millor opció).
• Si és l'únic DC o crític, plantejar-ne una restauració d'estat del sistema des de backup compatible, idealment recent i dins del període de tombstone.

En dominis amb diversos controladors, és molt recomanable que els DC siguin el més “purs” possible: sense rols addicionals ni dades d'usuari locals. D'aquesta manera, si un cau o es corromp, es pot formatar i promocionar-ne un de nou basant-se en un altre DC o mitjançant IFM, reduint molt la complexitat de la recuperació.

A més, convé recordar limitacions com que les còpies d'estat del sistema només són vàlides durant el període de tombstone (60, 90, 180 dies segons configuració) per evitar ressuscitar objectes esborrats, i que les claus dequip NTLM canvien cada 7 dies. En restauracions molt antigues, és possible que calgui restablir els comptes d'equip problemàtiques des d'“Usuaris i Equips d'Active Directory” o fins i tot treure-les i tornar-les a unir al domini.

Comptar amb procediments de còpia de seguretat periòdica de l'estat del sistema, documentar clarament els rols FSMO, catàleg global i topologia de replicació, i provar alguna vegada els passos de restauració en un entorn de laboratori, són inversions de temps que estalvien molts maldecaps quan arriba el dia que un controlador de domini es corromp o algú aplica una instantània sense pensar.