Restaurarea și recuperarea unui controler de domeniu local corupt

Când un controler de domeniu devine corupt sau este restaurat incorect, spaima este enormă: Autentificările eșuează, GPO-urile nu se mai aplică, iar replicarea se întrerupe aproape fără niciun indiciu.Vestea bună este că există proceduri clare pentru recuperarea unui controler de domeniu fizic sau virtual, cu condiția să fie respectate metodele de backup și restaurare acceptate.

În mediile Windows Server moderne, restaurarea unui controler de domeniu necesită o bună înțelegere a unor concepte precum starea sistemului, restaurare autoritativă/neautoritară, reveniri la setări SYSVOL, DFSR/FRS și USNDacă aceste probleme sunt abordate în grabă sau cu instrumente de imagistică incompatibile, rezultatul poate fi o pădure plină de inconsecvențe silențioase, foarte dificil de diagnosticat.

De ce este esențial să se protejeze și să se recupereze corespunzător un controler de domeniu

Active Directory este inima autentificării și autorizării într-un domeniu WindowsStochează utilizatori, computere, grupuri, relații de încredere, politici de grup, certificate și alte elemente critice. Aceste informații se află în principal în baza de date. Ntds.dit, fișierele jurnal și folderul asociate SYSVOL, printre alte componente care alcătuiesc așa-numita „stare a sistemului”.

Starea sistemului include, printre altele, Fișierele jurnal și datele Active Directory, Registrul Windows, volumul de sistem, SYSVOL, baza de date cu certificate (dacă există un CA), metabaza IIS, fișierele de boot și componentele protejate ale sistemului de operarePrin urmare, orice strategie serioasă de continuitate a afacerii trebuie să includă copii de rezervă regulate ale stării sistemului fiecărui centru de date.

Când are loc o corupere reală a bazei de date Active Directory, o eroare gravă de replicare sau o problemă cu permisiuni activate SYSVOLControlerul de domeniu poate opri procesarea interogărilor, poate eșua să pornească serviciile Active Directory sau poate declanșa erori în cascadă în întreaga pădure. În aceste cazuri, O recuperare rapidă și adecvată face diferența dintre un incident grav și un dezastru prelungit..

Înainte de a încerca o restaurare, este esențial să se facă distincția între o problemă reală a bazei de date și erorile mai banale. Foarte des, Cauza constă în DNS, modificări de rețea, firewall-uri sau rute modificate cu instrumente precum comanda netshPrin urmare, este recomandabil să excludeți mai întâi acești factori înainte de a accesa baza de date AD.

Instrumente de bază pentru diagnosticare și controlul replicării

În cazul apariției simptomelor de corupție sau a eșecurilor de replicare, primul pas sensibil este verificarea stării mediului folosind instrumente native. DCDiag, Repadmin, ReplMon (în versiunile mai vechi) și Vizualizatorul de evenimente Ei sunt cei mai buni aliați ai tăi înainte de a lua în considerare restaurări agresive.

cu DCDiag Se efectuează o verificare generală a tuturor controlerelor de domeniu, identificând problemele legate de replicare, DNS, servicii AD DS etc. Readministrator Vă permite să vizualizați starea replicării, partenerii de replicare, filigranele USN și să detectați obiecte persistente. În versiunile mai vechi de Windows, ReplMon A oferit o vizualizare grafică a erorilor de replicare din domeniu.

Pe lângă aceste instrumente, este esențial să consultați Vizualizatorul de evenimente pentru „Servicii de director” și „Replicare DFS”. Evenimente precum 467 și 1018 indică o corupție reală a bazei de date, în timp ce evenimentele 1113/1115/1114/1116 se referă la activarea sau dezactivarea replicării intrării/ieșirii.

Dacă un DC suspectat trebuie izolat temporar pentru a preveni răspândirea corupției, putem Dezactivați replicările de intrare și ieșire cu Repadmin:

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

Și pentru a restaura replicarea la normal, pur și simplu eliminați acele opțiuni:

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

Copii de rezervă ale stării sistemului acceptate pe controlerele de domeniu

Pentru a putea recupera un DC cu garanții, este esențial să aveți Copii de rezervă ale stării sistemului efectuate folosind instrumente compatibile cu Active DirectoryAceste instrumente utilizează API-urile de backup și restaurare de la Microsoft și Volume Shadow Copy Service (VSS) într-un mod acceptat.

Printre cele mai comune soluții se numără Copiere de rezervă Windows Server, soluții terțe integrate cu VSS (cum ar fi NAKIVO, Backup Exec și altele)sau utilități mai vechi, cum ar fi Ntbackup în Windows 2000/2003. În toate cazurile, acestea trebuie să respecte API-urile AD pentru a asigura consistența bazei de date și a replicilor acesteia după restaurare.

Windows Server 2012 și versiunile ulterioare prezintă o adăugire importantă: ID-ul generației Hyper-V (GenID)Acest identificator permite unui controler de domeniu virtual să detecteze că discul său a fost revenit la un moment anterior. Când se întâmplă acest lucru, AD DS generează un nou InvocationID și tratează situația ca și cum ar fi fost restaurată dintr-o copie de rezervă reușită.notificând partenerii săi de replicare, permițând astfel rescrierea în siguranță fără a suporta o revenire la USN.

Este esențial să se respecte durata de viață a pietrei funerareAceasta indică durata de utilizare a unei copii de rezervă a stării sistemului fără riscul reintroducerii obiectelor șterse cu mult timp în urmă. De obicei, este de 180 de zile în versiunile moderne și se recomandă efectuarea copiilor de rezervă cel puțin la fiecare 90 de zile pentru a menține o marjă de siguranță suficientă.

Metode neautorizate care provoacă inversări USN

Una dintre cele mai periculoase cauze ale inconsistențelor silențioase din Active Directory este Revenire la USNAceastă situație apare atunci când conținutul bazei de date AD este anulat utilizând o tehnică neacceptată, fără ca InvocationID-ul să fie restaurat sau partenerii de replicare să fie notificați.

Scenariul tipic este pornirea unui controler de domeniu de la un imaginea discului sau o instantanee a unei mașini virtuale realizată în trecutfără a utiliza o restaurare a sistemului compatibilă. Sau copiați direct fișierul Ntds.dit, utilizați programe de imagistică precum Ghost, porniți de pe o oglindă de disc defectă sau reaplicați o instantanee de stocare la nivel de matrice.

În aceste cazuri, controlerul de domeniu continuă să utilizeze același InvocationID ca înainte, dar Contorul local al USN merge înapoiCelelalte controlere de domeniu (DC) își amintesc că au primit modificări până la un USN ridicat, așa că atunci când controlerul de domeniu revenit încearcă să trimită înapoi USN-uri deja recunoscute, Partenerii lor cred că sunt la curent și nu mai acceptă schimbări concrete..

Rezultatul este că anumite modificări (de exemplu, creare utilizator, modificări parolă, înregistrare dispozitiv, modificări apartenență grup, înregistrări DNS noiAceste erori nu sunt niciodată reproduse de la controlerul de domeniu restaurat la restul rețelei, dar instrumentele de monitorizare pot să nu afișeze erori clare. Aceasta este o eroare silențioasă extrem de periculoasă.

Pentru a detecta aceste situații, driverele Windows Server 2003 SP1 și versiunile ulterioare înregistrează în jurnal Evenimentul 2095 al serviciilor de director Când se detectează un controler de domeniu la distanță care trimite USN-uri deja confirmate fără o modificare a InvocationID, sistemul Acesta pune în carantină controlerul de domeniu afectat, întrerupe Netlogon și împiedică apariția unor modificări ulterioare. care nu a putut fi reprodusă corect.

Ca probă criminalistică suplimentară, poate a fi consultat în Registru cheia HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters și valoarea DSA nu este inscriptibilDacă această valoare este setată (de exemplu, 0x4), indică faptul că DC-ul a fost pus într-o stare fără scriere prin detectarea inversării USN. Modificarea manuală a acestei valori pentru a o „remedia” este complet neacceptată. și lasă baza de date într-o stare permanent inconsistentă.

Strategii generale în cazul coruperii sau inversării unui controler de domeniu

Procedura de urmat atunci când se lucrează cu un DC corupt sau restaurat incorect depinde de mai mulți factori: Numărul de controlere de domeniu din domeniu/pădure, disponibilitatea copiilor valide ale stării sistemului, prezența altor roluri (FSMO, CA, catalog global) și domeniul de aplicare temporal al problemei.

Dacă există și alte DC-uri sănătoase în domeniu și Nu există date critice unice despre controlerul de domeniu deterioratCea mai rapidă și mai curată opțiune este de obicei eliminarea acelui controler de domeniu și reconstruirea lui. Totuși, dacă este singurul controler de domeniu sau dacă găzduiește roluri și date sensibile, va fi necesară o restaurare mai atentă (cu autoritate sau fără autoritate).

În termeni generali, opțiunile sunt:

• Retrogradarea forțată a controlerului de domeniu corupt și eliminarea acestuia din domeniu, urmată de curățarea metadatelor și, dacă este cazul, de o nouă promovare.
• Restaurare dintr-o copie de rezervă validă a stării sistemului, fie în mod autoritar, fie neautoritar.
• Reconstruiți controlerul de domeniu de la altul folosind IFM (Instalare de pe suport), când nu există o copie recentă, dar există alte DC-uri corecte.
• Utilizarea unui instantaneu VHD al unui controler de domeniu virtual, aplicând pașii suplimentari pentru a marca baza de date ca restaurată din copie de rezervă (Bază de date restaurată din copie de rezervă = 1) și pentru a vă asigura că este generat un nou InvocationID.

Dacă se suspectează în mod clar o revenire la un nou server (USN) (de exemplu, după restaurarea unei mașini virtuale dintr-un snapshot fără a urma cele mai bune practici) și apare evenimentul 2095, cea mai sensibilă acțiune este de obicei să Scoateți acel DC din funcțiune și nu încercați să-l „reparați” la fața locului., cu excepția cazului în care este posibil să reveniți la o copie de rezervă a stării sistemului acceptat, efectuată înainte de revenire.

Retrogradare forțată și curățare metadate

Când un controler de domeniu este atât de deteriorat încât nu poate fi retrogradat în mod normal sau a fost restaurat incorect și doriți să împiedicați răspândirea problemelor, puteți recurge la o retrogradare forțată.

În versiunile mai vechi, această operație era efectuată cu dcpromo /forțareeliminare, ce Eliminați rolul AD DS fără a încerca să reproduceți modificările în restul pădurii.În mediile moderne, expertul s-a schimbat, dar conceptul este același: eliminarea controlerului de domeniu problematic din topologia AD fără ca acesta să participe la replicarea ulterioară.

După o retrogradare forțată, este obligatorie executarea unei comenzi de pe un controler de domeniu sănătos. curățarea metadatelor folosind instrumentul NtdsutilAcest proces elimină toate referințele la controlerul de domeniu șters (obiectele Setări NTDS, referințele DNS etc.) din baza de date AD, astfel încât nu rămân rămășițe „fantomă” care să confunde replicarea.

Dacă controlerul degradat avea roluri FSMO (PDC Emulator, RID Master, Schema Master etc.), va fi necesar să transferă sau preia acele roluri la un alt controler de domeniu (DC) înainte sau după retrogradare, în funcție de situație. Ulterior, sistemul de operare poate fi reinstalat pe serverul respectiv și acesta poate fi promovat înapoi la un DC curat.

Restaurare neautoritară vs. restaurare autoritară în Active Directory

Când este disponibilă o copie validă a stării sistemului, recuperarea AD se poate face în două moduri: neautoritar și autoritarÎnțelegerea diferenței este esențială pentru a nu rata modificările recente sau a replica date învechite.

Într-o restaurare neautorizatăDC-ul este returnat la un punct anterior, dar odată ce pornește, Celelalte controlere de domeniu sunt considerate referințăCu alte cuvinte, după pornire, controlerul de domeniu restaurat solicită replicarea la intrare și își actualizează baza de date cu orice modificări lipsă de la celelalte controlere de domeniu. Această opțiune este ideală atunci când Există și alte controlere sănătoase și vrem ca cel restaurat să le ajungă din urmă..

Într-o restaurare autoritarăTotuși, se precizează în mod explicit că Datele restaurate sunt cele care ar trebui să prevaleze. peste ceea ce au celelalte DC-uri. Aceasta înseamnă că, după restaurare, obiectele recuperate vor avea un număr de versiune mai mare pentru a le forța să fie replicate de pe acel DC în restul domeniului. Este alegerea potrivită atunci când Am șters accidental obiecte sau OU-uri sau dorim să readucem conținutul SYSVOL și GPO la o stare anterioară și să îl reproducem..

Un detaliu important este că restaurarea autoritară nu trebuie neapărat să fie pentru întreaga bază de date. Cu utilitarul Ntdsutil Obiecte individuale, subarbori (de exemplu, o unitate organizațională) sau întregul domeniu pot fi marcate ca autoritare. Acest lucru oferă o flexibilitate considerabilă, de exemplu, pentru preia doar un utilizator, un grup, o unitate organizațională sau subarborele dc=mycompany,dc=local.

Procedură generală pentru restaurarea stării sistemului într-un DC

Schema de bază pentru restaurarea stării sistemului unui DC (fie fizic, fie virtual) cu instrumente compatibile este întotdeauna similară: Porniți în modul de restaurare a serviciilor directory (DSRM), restaurați folosind instrumentul de backup și reporniți.

În rezumat, pașii tipici pentru un controler de domeniu virtual ar fi:

1. Porniți mașina virtuală în Windows Boot Manager (de obicei prin apăsarea tastelor F5/F8 în timpul pornirii). Dacă mașina virtuală este gestionată de un hipervizor, poate fi necesară întreruperea funcției pentru a captura apăsarea tastei.
2. În opțiunile avansate de bootare, selectați Mod de restaurare a serviciilor de director (Modul de restaurare a serviciilor director). Acest mod pornește serverul fără a monta baza de date Active Directory într-un mod funcțional.
3. Conectați-vă cu contul de administrator DSRM definit în timpul promovării inițiale a DC-ului (nu cu un cont standard de administrator de domeniu).
4. Rulați instrumentul de backup utilizat (Windows Server Backup, NAKIVO sau alte componente compatibile) și alegeți să restaurați starea sistemului la punctul de backup dorit.
5. Finalizați expertul de restaurare și Reporniți DC-ul în modul normalÎntr-o restaurare neautorizată, serverul va iniția replicarea pentru a ajunge din urmă la celelalte controlere de domeniu.

Când vorbim despre produse de backup de la terți, cum ar fi Backup și replicare NAKIVOModul său „aplicație-relevant” este capabil să recunoască faptul că mașina recuperată este un controler de domeniu și ajustează automat procesul pentru a păstra consecvența ADÎn majoritatea scenariilor cu mai multe controlere, o recuperare completă în modul neautoritar este suficientă.

Restaurare autorizată cu Ntdsutil

Dacă doriți ca modificările aduse controlerului de domeniu restaurat să aibă prioritate față de restul, trebuie să adăugați un pas suplimentar după restaurarea neautorizată: utilizați Ntdsutil pentru a marca obiectele ca fiind autoritative.

Fluxul simplificat ar fi:

1. Restaurați starea sistemului în mod standard și lăsați serverul în continuare în Mod DSRM (Nu reporniți încă în modul normal).
2. Deschideți a prompt de comandă cu privilegii sporite și fugi ntdsutil.
3. Activați instanța AD cu activați instanța ntds.
4. Intrarea în contextul restaurării autoritare cu restaurare autoritară.
5. Utilizați comenzi precum restore object <DN_objeto> o restore subtree <DN_subarbol>, unde DN este numele distinctiv al obiectului sau subarborelei care va fi restaurat cu autoritate.
6. Confirmați tranzacția și, odată finalizată, Reporniți DC-ul în modul normal astfel încât obiectele marcate să fie replicate cu prioritate față de restul domeniului.

Acest tip de restaurare necesită mare prudență. Dacă întregul domeniu este restaurat cu autoritate și copia de rezervă este vecheExistă riscul de a pierde modificările legitime efectuate după copierea de rezervă (de exemplu, crearea de utilizatori, modificări ale parolei sau modificări ale grupurilor). Prin urmare, este o practică obișnuită limitarea restaurărilor autoritative doar la obiectele sau arborii strict necesari.

Restaurare și recuperare SYSVOL (FRS vs DFSR)

SYSVOL este o componentă cheie a controlerului de domeniu: Stochează scripturi de pornire, politici de grup, șabloane de securitate și alte resurse partajate esențiale.O eroare a permisiunilor, coruperea fișierelor sau probleme de replicare pot face ca obiectele GPO să devină inutilizabile sau pot provoca un comportament neregulat la clienți.

În funcție de versiunea Windows Server și de starea migrării, SYSVOL poate fi reprodus de FRS (Serviciu de replicare a fișierelor) sau prin DFSR (Replicare Distribuită a Sistemului de Fișiere)Procedura pentru o restaurare autoritară a SYSVOL variază în funcție de care dintre cele două este utilizată.

Pentru a determina acest lucru, puteți verifica cheia din Registru. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrarea Sysvol-urilor\LocalStateDacă această subcheie există și valoarea sa este 3 (ȘTERS), se utilizează DFSR. Dacă nu există sau valoarea sa este diferită, avem de-a face cu un mediu care utilizează în continuare FRS.

În mediile cu FRS, recuperarea autoritară a SYSVOL implică de obicei ajustarea valorii Burflags en HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process la o valoare specifică (de exemplu, 212 zecimal / 0xD4 hexadecimal) pentru a indica faptul că acest controler de domeniu este sursa autorizată.

Dacă SYSVOL este replicat de DFSR, procesul este ceva mai elaborat: implică utilizarea ADSIEdit pentru a modifica obiectele de abonament SYSVOL (atribute) msDFSR-activat y Opțiuni msDFSR) pe DC-ul autoritar și pe celelalte, forțați replicarea AD, executați dfsrdiag pollad și confirmați în jurnalul de evenimente apariția evenimentele 4114, 4602, 4614 și 4604 care certifică faptul că SYSVOL a fost inițializat și replicat corect.

Recuperarea controlerelor de domeniu virtuale de pe VHD

În mediile virtualizate este foarte frecvent să existe Fișiere VHD/VHDX ale controlerelor de domeniuDacă nu aveți o copie de rezervă a stării sistemului, dar aveți un VHD „vechi” funcțional, puteți monta un nou controler de domeniu de pe acel disc, deși trebuie să faceți acest lucru foarte atent pentru a evita provocarea unei reveniri la serverul USN.

Recomandarea este Nu porniți acea mașină virtuală direct în modul normalÎn schimb, ar trebui să bootați de pe VHD-ul anterior în DSRMDeschideți Editorul de Registry și navigați la HKLM\SYSTEM\CurrentControlSet\Services\NTDS\ParametersAcolo, este recomandabil să verificați valoarea Numărul restaurărilor DSA anterioare (dacă există) și, mai presus de toate, creați o nouă valoare DWORD (32 biți) numită Baza de date restaurată din backup cu valoarea 1.

Prin selectarea acestei valori, Active Directory este informat că baza de date a fost restaurată dintr-o copie de rezervă, ceea ce forțează generarea unui nou InvocationID la pornirea în modul normalÎn acest fel, celelalte controlere de domeniu o interpretează ca o instanță nouă și își ajustează corect filigranele de replicare, împiedicând revenirea la USN.

După repornirea DC-ului în modul normal, este recomandabil să verificați Vizualizatorul de evenimente, în special jurnalul de evenimente. Servicii de director, căutând evenimentul 1109Acest eveniment confirmă faptul că atributul InvocationID al serverului s-a modificat și afișează valorile vechi și noi, precum și cel mai mare USN la momentul copierii de rezervă. În plus, valoarea lui Numărul restaurărilor DSA anterioare Ar fi trebuit să fie mărit cu unu.

Dacă aceste evenimente nu apar sau numărul nu crește, ar trebui să verificați versiunile sistemului de operare și Service Pack-urile, deoarece Anumite comportamente de restaurare depind de anumite patch-uriÎn orice caz, este întotdeauna recomandabil să lucrați la o copie a VHD-ului original, păstrând o versiune intactă în cazul în care procesul trebuie repetat.

Scenarii practice și recomandări suplimentare

În practică, problemele de corupție sau restaurări necorespunzătoare apar adesea în scenariile de zi cu zi: Modificări manuale ale permisiunilor în SYSVOL, încercări de actualizare a șabloanelor ADMX/ADML, modificări GPO care nu sunt reproduseetc. Este relativ ușor să se creeze inconsecvențe dacă folderele partajate sunt modificate manual, cum ar fi SYSVOL\Policies fără a respecta replicarea.

În cazul unui controler de domeniu principal cu replicare întreruptă (atât date AD, cât și SYSVOL) și mesaje de monitorizare de tipul „Baza de date a fost restaurată folosind o procedură neacceptată. Cauză posibilă: Revenire la USN„”, lucrul prudent de făcut este:

• Verifica cu dcdiag y repadmin amploarea erorilor și dacă există „obiecte persistente”.
• Verificați evenimentul 2095 și valoarea DSA nu este inscriptibil în Registru.
• Evaluați dacă este posibil scoate acel DC și reconstruiește-l (Dacă există trei sau mai multe alte DC-uri sănătoase, aceasta este de obicei cea mai bună opțiune).
• Dacă este singurul DC sau critic, ridică o întrebare. restaurarea stării sistemului dintr-o copie de rezervă compatibilă, ideal recentă și din perioada de înregistrare a datelor.

În domeniile cu mai multe controlere, este recomandat ca DC-urile să fie cât mai „pure” posibil: fără roluri suplimentare sau date locale despre utilizatoriÎn acest fel, dacă unul eșuează sau se corupe, unul nou poate fi formatat și promovat pe baza unui alt controler de domeniu sau prin IFM, reducând considerabil complexitatea recuperării.

În plus, merită să ne amintim limitări precum cea Copiile stării sistemului sunt valide numai în perioada de delimitare a datelor. (60, 90, 180 de zile, în funcție de configurație) pentru a evita reactivarea obiectelor șterse și că cheile mașinii NTLM se schimbă la fiecare 7 zile. În cazul restaurărilor foarte vechi, poate fi necesar să resetează conturile echipei probleme din „Utilizatori și computere Active Directory” sau chiar eliminarea lor și reconectarea lor la domeniu.

Existența unor proceduri pentru realizarea regulată a unor copii de rezervă ale stării sistemului, Documentați clar rolurile FSMO, catalogul global și topologia de replicareIar testarea pașilor de restaurare într-un mediu de laborator reprezintă o investiție de timp care scutește de multe dureri de cap atunci când vine ziua în care un controler de domeniu devine corupt sau cineva aplică un snapshot fără să se gândească.