Vraćanje i oporavak oštećenog lokalnog kontrolera domene

Kada kontroler domene postane oštećen ili se nepravilno vrati u prethodno stanje, strah je ogroman: Prijave ne uspijevaju, GPO-i prestaju s primjenom, a replikacija se prekida gotovo bez ikakvih tragova.Dobra vijest je da postoje jasne procedure za oporavak fizičkog ili virtualnog DC-a, pod uvjetom da se poštuju prihvaćene metode sigurnosnog kopiranja i vraćanja podataka.

U modernim Windows Server okruženjima, vraćanje kontrolera domene zahtijeva dobro razumijevanje koncepata kao što su status sistema, autoritativno/neautoritativno vraćanje, vraćanje na prethodna stanja (SYSVOL), DFSR/FRS i USNAko se ovi problemi rješavaju na brzinu ili nekompatibilnim alatima za snimanje, rezultat može biti šuma puna tihih nedosljednosti koje je vrlo teško dijagnosticirati.

Zašto je ključno pravilno zaštititi i oporaviti kontroler domene

Active Directory je srž autentifikacije i autorizacije u Windows domenu.Pohranjuje korisnike, računare, grupe, odnose povjerenja, grupne politike, certifikate i druge ključne elemente. Ove informacije se prvenstveno nalaze u bazi podataka. Ntds.dit, povezane datoteke dnevnika i mapa SYSVOL, između ostalih komponenti koje čine takozvano „stanje sistema“.

Status sistema uključuje, između ostalog, Datoteke i podaci dnevnika Active Directoryja, Windows registar, sistemski volumen, SYSVOL, baza podataka certifikata (ako postoji CA), IIS metabaza, datoteke za pokretanje i zaštićene komponente operativnog sistemaStoga, svaka ozbiljna strategija kontinuiteta poslovanja mora uključivati ​​redovne sigurnosne kopije stanja sistema svakog podatkovnog centra.

Kada dođe do stvarnog oštećenja baze podataka Active Directory, ozbiljnog kvara replikacije ili problema sa dozvole uključene SYSVOLKontroler domene može prestati obrađivati ​​upite, ne pokrenuti usluge Active Directory ili izazvati kaskadne greške u cijeloj šumi. U tim slučajevima, Brz i pravilan oporavak čini razliku između ozbiljnog incidenta i dugotrajne katastrofe..

Prije pokušaja vraćanja baze podataka, ključno je razlikovati stvarni problem s bazom podataka od uobičajenijih kvarova. Vrlo često, Uzrok leži u DNS-u, promjenama na mreži, zaštitnim zidovima ili rutama modificiranim alatima kao što su naredba netshStoga je preporučljivo prvo isključiti ove faktore prije nego što se pristupi AD bazi podataka.

Osnovni alati za dijagnostiku i kontrolu replikacije

U slučaju simptoma korupcije ili neuspjeha replikacije, prvi razuman korak je provjera stanja okruženja korištenjem izvornih alata. DCDiag, Repadmin, ReplMon (u starijim verzijama) i Preglednik događaja Oni su vaši najbolji saveznici prije nego što razmislite o agresivnim restauracijama.

con DC Diag Vrši se opšta provjera svih kontrolera domena, identifikujući probleme sa replikacijom, DNS-om, AD DS servisima itd. Repadmin Omogućava vam pregled statusa replikacije, partnera za replikaciju, USN vodenih žigova i otkrivanje trajnih objekata. U starijim verzijama Windowsa, ReplMon Nudio je grafički prikaz grešaka replikacije unutar domene.

Pored ovih alata, bitno je pregledati Preglednik događaja za "Usluge direktorija" i "Replikaciju DFS-a". Događaji poput 467 i 1018 ukazuju na stvarnu korupciju baze podataka., dok se događaji 1113/1115/1114/1116 odnose na omogućavanje ili onemogućavanje replikacije ulaza/izlaza.

Ako je potrebno privremeno izolovati sumnjivi kontroler domena kako bismo spriječili širenje korupcije, možemo Onemogućite dolaznu i odlaznu replikaciju pomoću Repadmina:

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

A da biste vratili replikaciju u normalu, jednostavno uklonite te opcije:

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

Podržane sigurnosne kopije stanja sistema na kontrolerima domena

Da biste mogli oporaviti DC sa garancijama, neophodno je imati Sigurnosne kopije stanja sistema napravljene korištenjem alata kompatibilnih s Active DirectoryjemOvi alati koriste Microsoftove API-je za sigurnosno kopiranje i vraćanje podataka i uslugu Volume Shadow Copy (VSS) na podržani način.

Među najčešćim rješenjima su Windows Server Backup, rješenja trećih strana integrirana s VSS-om (kao što su NAKIVO, Backup Exec i druga)ili starije uslužne programe kao što su Ntbackup u Windowsu 2000/2003. U svim slučajevima, moraju poštovati AD API-je kako bi se osigurala konzistentnost baze podataka i njenih replika nakon restauracije.

Windows Server 2012 i novije verzije imaju važan novi dodatak: Hyper-V generacijski ID (GenID)Ovaj identifikator omogućava kontroleru virtuelne domene da otkrije da je njegov disk vraćen na prethodnu vremensku tačku. Kada se to dogodi, AD DS generira novi InvocationID i tretira situaciju kao da je vraćena iz uspješne sigurnosne kopije.obavještavajući svoje partnere za replikaciju, omogućavajući tako sigurno prepisivanje bez izvođenja USN vraćanja na prethodnu verziju.

Neophodno je poštovati životni vijek nadgrobnog spomenikaOvo pokazuje koliko dugo se sigurnosna kopija stanja sistema može koristiti bez rizika ponovnog uvođenja objekata koji su davno izbrisani. U modernim verzijama to je obično 180 dana, a preporučuje se izrada sigurnosnih kopija najmanje svakih 90 dana kako bi se održala dovoljna sigurnosna margina.

Neovlaštene metode koje uzrokuju poništavanje USN-a

Jedan od najopasnijih uzroka tihih nedosljednosti u Active Directoryju je... Povlačenje USN-aDo ove situacije dolazi kada se sadržaj AD baze podataka vrati na prethodnu vrijednost korištenjem nepodržane tehnike, bez vraćanja InvocationID-a ili obavještavanja partnera za replikaciju.

Tipičan scenario je pokretanje DC-a sa slika diska ili snimak virtuelne mašine napravljen u prošlostibez korištenja kompatibilnog programa za vraćanje sistema. Ili direktno kopirajte datoteku Ntds.dit, koristite programe za izradu slika poput Ghost-a, pokrenite sistem sa neispravnog mirror-a diska ili ponovo primijenite snimak memorije na nivou niza.

U ovim slučajevima, kontroler domene nastavlja koristiti isti InvocationID kao i prije, ali njegov Lokalni USN šalter ide unazadOstali DC-ovi pamte prijem promjena do visokog USN-a, tako da kada vraćeni DC pokuša poslati nazad već prepoznate USN-ove, Njihovi partneri vjeruju da su u toku s novostima i prestaju prihvatati konkretne promjene..

Rezultat toga je da određene modifikacije (na primjer, kreiranje korisnika, promjena lozinke, registracija uređaja, promjene članstva u grupama, novi DNS zapisiOve greške se nikada ne repliciraju sa obnovljenog kontrolera domena na ostatak mreže, ali alati za praćenje možda neće prikazati jasne greške. Ovo je izuzetno opasan tihi kvar.

Da bi otkrili ove situacije, upravljački programi za Windows Server 2003 SP1 i novije verzije prijavljuju Događaj usluga direktorija 2095 Kada se otkrije da udaljeni kontroler domena šalje već potvrđene USN-ove bez promjene u InvocationID-u, sistem Stavlja pogođeni DC u karantin, pauzira Netlogon i sprječava daljnje promjene. koji se nije mogao pravilno replicirati.

Kao dodatni forenzički dokaz, može konsultovati u Registru ključ HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters i vrijednost DSA nije moguće pisatiAko je ova vrijednost postavljena (npr. 0x4), to ukazuje na to da je DC stavljen u stanje zabrane pisanja detekcijom obrnutog USN-a. Ručno mijenjanje ove vrijednosti radi njenog "popravljanja" je potpuno nepodržano. i ostavlja bazu podataka u trajno nekonzistentnom stanju.

Opće strategije u slučaju oštećenja ili vraćanja kontrolera domene na prethodno stanje

Postupak koji treba slijediti prilikom rješavanja problema s oštećenim ili nepravilno obnovljenim DC-om ovisi o nekoliko faktora: Broj kontrolera domena u domenu/šumi, dostupnost važećih kopija stanja sistema, prisustvo drugih uloga (FSMO, CA, globalni katalog) i vremenski opseg problema.

Ako postoje drugi ispravni kontroleri domena u domenu i Ne postoje jedinstveni kritični podaci o oštećenom kontroleru domeneNajbrža i najčišća opcija je obično uklanjanje tog kontrolera domene i njegova ponovna izgradnja. Međutim, ako je to jedini kontroler domene ili ako sadrži osjetljive uloge i podatke, bit će potrebna pažljivija restauracija (autoritativna ili neautoritativna).

Uopšteno govoreći, opcije su:

• Prisilno snizite nivo oštećenog kontrolera domena i uklonite ga iz domene, nakon čega slijedi čišćenje metapodataka i, ako je primjenjivo, nova promocija.
• Vraćanje iz važeće sigurnosne kopije stanja sistema, bilo u autoritativnom ili neautoritativnom režimu.
• Ponovo izgradite DC iz drugog koristeći IFM (Instalacija sa medija), kada ne postoji nedavna kopija, ali postoje drugi ispravni kontroleri domena.
• Korištenje VHD snimka virtualnog DC-a, primjenjujući dodatne korake za označavanje baze podataka kao obnovljene iz sigurnosne kopije (Baza podataka obnovljena iz sigurnosne kopije = 1) i osiguravajući da je generiran novi InvocationID.

Ako postoji jasna sumnja na vraćanje USN-a (na primjer, nakon vraćanja virtuelne mašine sa snimka stanja bez pridržavanja najboljih praksi) i pojavi se događaj 2095, najrazumniji postupak je obično Uklonite taj DC iz upotrebe i ne pokušavajte ga "popraviti" na licu mjesta., osim ako nije moguće vratiti se na sigurnosnu kopiju podržanog stanja sistema napravljenu prije vraćanja na prethodno stanje.

Prisilno snižavanje ranga i čišćenje metapodataka

Kada je kontroler domene toliko oštećen da se ne može normalno degradirati ili je nepravilno vraćen u prethodno stanje, a želite spriječiti širenje problema, možete pribjeći prisilno snižavanje čina.

U starijim verzijama, ova operacija se izvodila sa dcpromo /prisilno uklanjanje, šta Uklonite AD DS ulogu bez pokušaja repliciranja promjena na ostatak šume.U modernim okruženjima čarobnjak se promijenio, ali koncept je isti: ukloniti problematični DC iz AD topologije bez njegovog učešća u daljnjoj replikaciji.

Nakon prisilnog snižavanja verzije, obavezno je izvršiti naredbu sa ispravnog DC-a. čišćenje metapodataka pomoću alata NtdsutilOvaj proces uklanja sve reference na izbrisani kontroler domena (objekti NTDS postavki, DNS reference itd.) iz AD baze podataka, tako da ne ostaju ostaci "fantoma" koji bi zbunili replikaciju.

Ako je degradirani kontroler imao FSMO uloge (PDC emulator, RID Master, Schema Master, itd.), bit će potrebno premješta ili preuzima te uloge na drugi DC prije ili poslije snižavanja nivoa, ovisno o situaciji. Kasnije se operativni sistem može ponovo instalirati na tom serveru i on se može vratiti na čisti DC.

Neautoritativna naspram autoritativne restauracije u Active Directoryju

Kada je dostupna važeća kopija stanja sistema, oporavak AD-a se može izvršiti na dva načina: neautoritativni i autoritativniRazumijevanje razlike je ključno kako ne biste propustili nedavne promjene ili replicirali zastarjele podatke.

U a neautoritativna restauracijaDC se vraća na prethodnu tačku, ali kada se jednom pokrene, Ostali kontroleri domena smatraju se referencomDrugim riječima, nakon pokretanja, obnovljeni DC zahtijeva dolaznu replikaciju i ažurira svoju bazu podataka sa svim nedostajućim promjenama iz ostalih DC-ova. Ova opcija je idealna kada Postoje i drugi zdravi kontroleri, i želimo da ih onaj koji je obnovljen sustigne..

U a autoritarna restauracijaMeđutim, eksplicitno je navedeno da Obnovljeni podaci su ono što bi trebalo da prevlada. u odnosu na ono što imaju drugi DC-ovi. To znači da će, nakon vraćanja u prethodno stanje, oporavljeni objekti imati viši broj verzije kako bi se prisilno replicirali s tog DC-a na ostatak domene. To je odgovarajući izbor kada Slučajno smo izbrisali objekte ili organizacijske jedinice (OU) ili želimo vratiti sadržaj SYSVOL-a i GPO-a u prethodno stanje i replicirati ga..

Važan detalj je da autoritativna restauracija ne mora nužno biti za cijelu bazu podataka. Pomoću uslužnog programa Ntdsutil Pojedinačni objekti, podstabla (npr. OU) ili cijeli domen mogu biti označeni kao autoritativni. Ovo nudi značajnu fleksibilnost za, na primjer, dohvati samo korisnika, grupu, organizacijsku jedinicu ili podstablo dc=mycompany,dc=local.

Opšti postupak za vraćanje statusa sistema u kontroler domena

Osnovna shema za vraćanje stanja sistema DC-a (bilo fizičkog ili virtualnog) s kompatibilnim alatima je uvijek slična: Pokrenite računar u načinu rada za vraćanje usluga direktorija (DSRM), vratite računar pomoću alata za sigurnosno kopiranje i ponovo pokrenite računar..

Ukratko, tipični koraci za virtualni kontroler domene bili bi:

1. Pokrenite virtuelnu mašinu u Windows Boot Manageru (obično pritiskom na F5/F8 tokom pokretanja). Ako VM-om upravlja hipervizor, možda će biti potrebno pauzirati mašinu kako bi se snimio pritisak tipke.
2. U naprednim opcijama pokretanja odaberite Način vraćanja usluga direktorija (Način vraćanja usluga direktorija). Ovaj način rada pokreće server bez montiranja baze podataka Active Directory na funkcionalan način.
3. Prijavite se s administratorskim računom DSRM-a definirano tokom originalne promocije kontrolera domena (ne sa standardnim računom administratora domene).
4. Pokrenite alat za pravljenje sigurnosnih kopija koristi se (Windows Server Backup, NAKIVO ili drugi kompatibilni) i odaberite vraćanje stanja sistema na željenu tačku sigurnosne kopije.
5. Završite čarobnjaka za restauraciju i Ponovo pokrenite DC u normalnom režimuU neautoritativnom vraćanju, server će pokrenuti replikaciju kako bi sustigao ostale kontrolere domena.

Kada govorimo o proizvodima za pravljenje sigurnosnih kopija trećih strana, kao što su NAKIVO Backup & ReplicationNjegov "app-aware" način rada može prepoznati da je mašina koja se oporavlja DC i automatski prilagoditi proces kako bi se očuvala konzistentnost AD-aU većini scenarija s više kontrolera, dovoljan je potpuni oporavak u neautoritativnom načinu rada.

Autoritativna restauracija pomoću Ntdsutilu

Ako želite da promjene na vraćenom kontroleru domene imaju prednost nad ostalima, potrebno je dodati dodatni korak nakon neautoritativnog vraćanja: Koristite Ntdsutil za označavanje objekata kao autoritativnih.

Pojednostavljeni tok bi bio:

1. Vratite stanje sistema na standardni način i ostavite server i dalje uključen DSRM način rada (Nemojte još ponovo pokretati u normalnom režimu).
2. Otvorite a komandni redak s povišenim privilegijama i trči ntdsutil.
3. Aktivirajte AD instancu sa aktiviraj instancu ntds.
4. Ulazak u kontekst autoritativne restauracije sa autoritativno vraćanje.
5. Koristite komande poput restore object <DN_objeto> o restore subtree <DN_subarbol>, gdje je DN prepoznatljivo ime objekta ili podstabla koje treba autoritativno obnoviti.
6. Potvrdite transakciju i, nakon što je završena, Ponovo pokrenite DC u normalnom režimu tako da se označeni objekti repliciraju s prioritetom na ostatak domene.

Ova vrsta restauracije zahtijeva veliki oprez. Ako je cijela domena autoritativno obnovljena, a sigurnosna kopija je staraPostoji rizik od gubitka legitimnih promjena napravljenih nakon pravljenja sigurnosne kopije (na primjer, kreiranje korisnika, promjene lozinke ili modifikacije grupe). Stoga je uobičajena praksa ograničiti autoritativne restauracije samo na strogo neophodne objekte ili stabla.

Vraćanje i oporavak SYSVOL-a (FRS u odnosu na DFSR)

SYSVOL je ključna komponenta kontrolera domene: Pohranjuje skripte za pokretanje, grupne politike, sigurnosne predloške i druge bitne dijeljene resurse.Greška u vašim dozvolama, oštećenje datoteka ili problemi s replikacijom mogu učiniti GPO-e neupotrebljivim ili uzrokovati nepravilno ponašanje kod klijenata.

U zavisnosti od verzije Windows Servera i statusa migracije, SYSVOL se može replicirati od strane FRS (Usluga replikacije datoteka) ili za DFSR (Replikacija distribuiranog sistema datoteka)Postupak za autoritativno vraćanje SYSVOL-a varira ovisno o tome koji se od ta dva koristi.

Da biste to utvrdili, možete provjeriti ključ u registru. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalStateAko ovaj podključ postoji i njegova vrijednost je 3 (DELETED), koristi se DFSR. Ako ne postoji ili mu je vrijednost drugačija, imamo posla s okruženjem koje i dalje koristi FRS.

U okruženjima sa FRS-om, autoritativni oporavak SYSVOL-a obično uključuje podešavanje vrijednosti. Burflags en HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process na određenu vrijednost (npr. 212 decimalno / 0xD4 heksadecimalno) kako bi se naznačilo da je ovaj kontroler domena autoritativni izvor.

Ako DFSR replicira SYSVOL, proces je nešto složeniji: uključuje korištenje ADSIEdit za izmjenu SYSVOL objekata pretplate (atributa msDFSR-Omogućeno y msDFSR-Opcije) na autoritativnom DC-u i na ostalima, prisiliti replikaciju AD-a, izvršiti dfsrdiag pollad i potvrdite u dnevniku događaja pojavu događaji 4114, 4602, 4614 i 4604 koji potvrđuju da je SYSVOL ispravno inicijaliziran i repliciran.

Oporavak virtuelnih kontrolera domena sa VHD-a

U virtualiziranim okruženjima vrlo je uobičajeno imati VHD/VHDX datoteke kontrolera domenaAko nemate sigurnosnu kopiju stanja sistema, ali imate funkcionalan "stari" VHD, možete montirati novi DC s tog diska, iako to morate učiniti vrlo pažljivo kako biste izbjegli izazivanje vraćanja USN-a.

Preporuka je Ne pokrećite tu virtuelnu mašinu direktno u normalnom režimuUmjesto toga, trebali biste pokrenuti sistem sa prethodnog VHD-a u DSRMOtvorite uređivač registra i idite na HKLM\SYSTEM\CurrentControlSet\Services\NTDS\ParametersTamo je preporučljivo provjeriti vrijednost Broj prethodnih DSA restauracija (ako postoji) i, prije svega, kreirajte novu DWORD (32-bitnu) vrijednost pod nazivom Baza podataka vraćena iz sigurnosne kopije sa vrednošću 1.

Odabirom ove vrijednosti, Active Directory se obavještava da je baza podataka vraćena iz sigurnosne kopije, što prisiljava generiranje novog InvocationID-a prilikom pokretanja u normalnom načinu radaNa ovaj način, ostali kontroleri domena to interpretiraju kao novu instancu i ispravno prilagođavaju svoje vodene žigove replikacije, sprječavajući vraćanje USN-a na prethodnu verziju.

Nakon ponovnog pokretanja DC-a u normalnom režimu, preporučljivo je provjeriti Preglednik događaja, posebno dnevnik Usluge direktorija, tražeći događaj 1109Ovaj događaj potvrđuje da se atribut InvocationID servera promijenio i prikazuje stare i nove vrijednosti, kao i najviši USN u trenutku pravljenja sigurnosne kopije. Pored toga, vrijednost Broj prethodnih DSA restauracija Trebalo je da se poveća za jedan.

Ako se ovi događaji ne pojave ili se broj ne poveća, trebali biste provjeriti verzije operativnog sistema i servisne pakete, budući da Određena ponašanja pri restauraciji zavise od specifičnih zakrpaU svakom slučaju, uvijek je preporučljivo raditi na kopiji originalnog VHD-a, čuvajući netaknutu verziju u slučaju da se proces treba ponoviti.

Praktični scenariji i dodatne preporuke

U praksi, problemi korupcije ili nepravilne restauracije često se javljaju u svakodnevnim scenarijima: Ručne izmjene dozvola u SYSVOL-u, pokušaji ažuriranja ADMX/ADML predložaka, promjene GPO-a koje se ne replicirajuitd. Relativno je lako uzrokovati nedosljednosti ako se dijeljene mape ručno mijenjaju, kao što je SYSVOL\Policies bez poštovanja replikacije.

U slučaju primarnog kontrolera domena sa prekinutom replikacijom (i AD podaci i SYSVOL) i porukama praćenja tipa „Baza podataka je vraćena korištenjem nepodržane procedure. Mogući uzrok: Vraćanje USN-a na prethodno stanje", mudro je uraditi sljedeće:

• Provjerite sa dcdiag y repadmin obim grešaka i da li postoje „trajni objekti“.
• Provjerite događaj 2095 i vrijednost DSA nije moguće pisati u Registru.
• Procijenite da li je moguće Ukloni taj DC i ponovo ga sastavi. (Ako postoje tri ili više drugih ispravnih DC-ova, ovo je obično najbolja opcija).
• Ako je to jedini DC ili kritičar, pokrenite obnavljanje stanja sistema iz kompatibilne sigurnosne kopije, idealno nedavne i unutar perioda zaštitnog znaka.

U domenama sa više kontrolera, toplo se preporučuje da kontroleri domena budu što je moguće "čistiji": bez dodatnih uloga ili lokalnih korisničkih podatakaNa ovaj način, ako jedan zakaže ili se ošteti, novi se može formatirati i promovirati na osnovu drugog DC-a ili putem IFM-a, što znatno smanjuje složenost oporavka.

Nadalje, vrijedi imati na umu ograničenja kao što su Kopije stanja sistema su važeće samo tokom perioda zabrane rada. (60, 90, 180 dana, ovisno o konfiguraciji) kako bi se izbjeglo oživljavanje izbrisanih objekata i da se NTLM ključevi mašine mijenjaju svakih 7 dana. Kod vrlo starih vraćanja, možda će biti potrebno resetiraj timske račune problemi sa "Active Directory Users and Computers" ili čak njihovo uklanjanje i ponovno pridruživanje domeni.

Posjedovanje procedura za redovno pravljenje sigurnosnih kopija stanja sistema, Jasno dokumentirajte FSMO uloge, globalni katalog i topologiju replikacijeA testiranje koraka vraćanja u prvobitno stanje u laboratorijskom okruženju je vremenska investicija koja štedi mnogo glavobolja kada dođe dan da se kontroler domene ošteti ili da neko bez razmišljanja napravi snimak sistema.