Gjenopprette og gjenopprette en ødelagt lokal domenekontroller

Når en domenekontroller blir ødelagt eller gjenopprettes feil, er frykten enorm: Pålogginger mislykkes, gruppepolicyobjekter slutter å gjelde, og replikeringen bryter sammen nesten uten ledetråder.Den gode nyheten er at det finnes klare prosedyrer for å gjenopprette en fysisk eller virtuell DC, forutsatt at de aksepterte metodene for sikkerhetskopiering og gjenoppretting respekteres.

I moderne Windows Server-miljøer krever gjenoppretting av en domenekontroller god forståelse av konsepter som systemstatus, autoritativ/ikke-autoritativ gjenoppretting, SYSVOL-, DFSR/FRS- og USN-tilbakeføringerHvis disse problemene håndteres raskt eller med inkompatible bildebehandlingsverktøy, kan resultatet bli en skog full av stille inkonsekvenser som er svært vanskelige å diagnostisere.

Hvorfor det er viktig å beskytte og gjenopprette en domenekontroller på riktig måte

Active Directory er kjernen i autentisering og autorisasjon i et Windows-domeneDen lagrer brukere, datamaskiner, grupper, tillitsforhold, gruppepolicyer, sertifikater og andre kritiske elementer. Denne informasjonen ligger hovedsakelig i databasen. Ntds.dit, de tilhørende loggfilene og mappen SYSVOL, blant andre komponenter som utgjør den såkalte «systemets tilstand».

Systemstatusen inkluderer blant annet Active Directory-loggfiler og -data, Windows-registeret, systemvolumet, SYSVOL, sertifikatdatabasen (hvis en sertifiseringsinstans finnes), IIS-metabasen, oppstartsfiler og beskyttede operativsystemkomponenterDerfor må enhver seriøs strategi for forretningskontinuitet inkludere regelmessige sikkerhetskopier av systemtilstanden til hvert datasenter.

Når det faktisk oppstår skade på Active Directory-databasen, en alvorlig replikeringsfeil eller et problem med tillatelser på SYSVOLDomenekontrolleren kan slutte å behandle spørringer, ikke starte Active Directory-tjenester eller utløse overlappende feil i hele skogen. I disse tilfellene, Rask og skikkelig gjenoppretting utgjør forskjellen mellom en alvorlig hendelse og en langvarig katastrofe..

Før du prøver å gjenopprette, er det viktig å skille mellom et ekte databaseproblem og mer vanlige feil. Svært ofte, Årsaken ligger i DNS, nettverksendringer, brannmurer eller ruter modifisert med verktøy som netsh -kommandoenDerfor er det lurt å utelukke disse faktorene først før du berører AD-databasen.

Grunnleggende diagnostikk- og replikeringskontrollverktøy

Ved symptomer på korrupsjon eller replikeringsfeil er det første fornuftige trinnet å sjekke miljøets tilstand ved hjelp av innebygde verktøy. DCDiag, Repadmin, ReplMon (i eldre versjoner) og hendelsesvisningen De er dine beste allierte før du vurderer aggressive restaureringer.

med DCDiag En generell kontroll av alle domenekontrollere utføres, og problemer med replikering, DNS, AD DS-tjenester osv. identifiseres. Repadmin Den lar deg se replikeringsstatus, replikeringspartnere, USN-vannmerker og oppdage vedvarende objekter. I eldre versjoner av Windows, ReplMan Den tilbød en grafisk visning av replikasjonsfeil innenfor domenet.

I tillegg til disse verktøyene er det viktig å se gjennom hendelsesvisningen for «Directory Services» og «DFS Replication». Hendelser som 467 og 1018 peker på faktisk korrupsjon av databasen., mens hendelsene 1113/1115/1114/1116 gjelder aktivering eller deaktivering av input/output-replikering.

Hvis en mistenkt DC må isoleres midlertidig for å forhindre at den sprer korrupsjon, kan vi Deaktiver innkommende og utgående replikering med Repadmin:

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

Og for å gjenopprette replikeringen til normal, fjern ganske enkelt disse alternativene:

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

Støttede sikkerhetskopier av systemstatus på domenekontrollere

For å kunne inndrive en DC med garantier, er det viktig å ha Sikkerhetskopiering av systemstatus utført med Active Directory-kompatible verktøyDisse verktøyene bruker Microsofts API-er for sikkerhetskopiering og gjenoppretting og Volume Shadow Copy Service (VSS) på en støttet måte.

Blant de vanligste løsningene er Windows Server Backup, tredjepartsløsninger integrert med VSS (som NAKIVO, Backup Exec og andre)eller eldre verktøy som f.eks. Ntbackup i Windows 2000/2003. I alle tilfeller må de respektere AD API-ene for å sikre konsistensen av databasen og dens replikaer etter gjenoppretting.

Windows Server 2012 og senere versjoner har et viktig nytt tillegg: Hyper-V-generasjons-ID (GenID)Denne identifikatoren lar en virtuell domenekontroller oppdage at disken har blitt rullet tilbake til et tidligere tidspunkt. Når dette skjer, AD DS genererer en ny InvocationID og behandler situasjonen som om den var gjenopprettet fra en vellykket sikkerhetskopiering.varsle replikeringspartnerne sine, og dermed muliggjøre sikker omskriving uten å pådra seg en USN-tilbakerulling.

Det er viktig å respektere gravsteinens levetidDette indikerer hvor lenge en sikkerhetskopi av systemtilstand kan brukes uten å risikere at objekter som ble slettet for lenge siden, blir gjeninnført. Det er vanligvis 180 dager i moderne versjoner, og det anbefales å utføre sikkerhetskopier minst hver 90. dag for å opprettholde tilstrekkelig sikkerhetsmargin.

Uautoriserte metoder som forårsaker USN-reverseringer

En av de farligste årsakene til stille inkonsekvenser i Active Directory er USN-tilbakerullingDenne situasjonen oppstår når innholdet i AD-databasen rulles tilbake ved hjelp av en teknikk som ikke støttes, uten at InvocationID gjenopprettes eller replikeringspartnerne varsles.

Det typiske scenarioet er å starte en DC fra en diskbilde eller et øyeblikksbilde av en virtuell maskin tatt tidligereuten å bruke en kompatibel systemgjenoppretting. Eller kopier Ntds.dit-filen direkte, bruk bildebehandlingsprogrammer som Ghost, start opp fra et ødelagt diskspeil, eller bruk et lagringsøyeblikksbilde på nytt på arraynivå.

I disse tilfellene fortsetter domenekontrolleren å bruke samme InvocationID som før, men dens Lokal USN-teller går bakoverDe andre DC-ene husker å ha mottatt endringer opp til en høy USN, så når den tilbakestilte DC-en prøver å sende tilbake allerede gjenkjente USN-er, Partnerne deres tror de er oppdaterte og slutter å akseptere konkrete endringer..

Resultatet er at visse modifikasjoner (for eksempel brukeroppretting, passordendringer, enhetsregistrering, endringer i gruppemedlemskap, nye DNS-oppføringerDisse feilene replikeres aldri fra den gjenopprettede domenet til resten av nettverket, men overvåkingsverktøy viser kanskje ikke tydelige feil. Dette er en ekstremt farlig stille feil.

For å oppdage disse situasjonene logger Windows Server 2003 SP1 og senere drivere Katalogtjenester-hendelse 2095 Når en ekstern domenekontroller oppdages som sender allerede bekreftede USN-er uten endring i InvocationID, vil systemet Den setter den berørte domenet i karantene, pauser Netlogon og forhindrer at ytterligere endringer skjer. som ikke kunne gjengis riktig.

Som ytterligere rettsmedisinske bevis kan det skal konsulteres i registeret nøkkelen HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters og verdien DSA ikke skrivbarHvis denne verdien er satt (f.eks. 0x4), indikerer det at DC-en ble satt i en skrivefri tilstand av USN-reverseringsdeteksjon. Manuell endring av denne verdien for å «fikse» den støttes ikke fullstendig. og etterlater databasen i en permanent inkonsekvent tilstand.

Generelle strategier i tilfelle korrupsjon eller reversering av en domenekontroller

Fremgangsmåten som skal følges når du har en ødelagt eller feilaktig gjenopprettet DC, avhenger av flere faktorer: Antall domenekontrollere i domenet/skogen, tilgjengeligheten av gyldige kopier av systemstatusen, tilstedeværelsen av andre roller (FSMO, CA, global katalog) og problemets tidsmessige omfang.

Hvis det finnes andre sunne DC-er i domenet og Det finnes ingen unike kritiske data på den skadede domenekontrollerenDet raskeste og reneste alternativet er vanligvis å fjerne domenekontrolleren og bygge den opp igjen. Men hvis det er den eneste domenekontrolleren, eller hvis den er vert for sensitive roller og data, vil en mer forsiktig gjenoppretting (autoritativ eller ikke-autoritativ) være nødvendig.

Generelt sett er alternativene:

• Tvangsdegrader den korrupte domenet og fjern det fra domenet, etterfulgt av rensing av metadata og, hvis aktuelt, ny promotering.
• Gjenopprett fra en gyldig sikkerhetskopi av systemstatus, enten i autoritativ eller ikke-autoritativ modus.
• Gjenoppbygg den sentrale kontrollenheten fra en annen ved hjelp av IFM (Install From Media), når det ikke finnes noen nylig kopi, men det finnes andre korrekte domenekontrollere.
• Bruke et VHD-øyeblikksbilde av en virtuell DC, og bruk de ekstra trinnene for å markere databasen som gjenopprettet fra sikkerhetskopi (Database gjenopprettet fra sikkerhetskopi = 1) og sørg for at en ny InvocationID genereres.

Hvis det er klar mistanke om en USN-tilbakerulling (for eksempel etter å ha gjenopprettet en virtuell maskin fra et øyeblikksbilde uten å følge beste praksis) og hendelse 2095 vises, er den mest fornuftige handlingen vanligvis å Ta den likestrømsenheten ut av drift, og ikke forsøk å "fikse" den på stedet., med mindre det er mulig å gå tilbake til en sikkerhetskopi av den støttede systemtilstanden som ble tatt før tilbakestillingen.

Tvungen degradering og opprydding av metadata

Når en domenekontroller er så skadet at den ikke kan degraderes normalt, eller har blitt feilaktig gjenopprettet og du vil forhindre at den sprer problemer, kan du ty til en tvungen degradering.

I eldre versjoner ble denne operasjonen utført med dcpromo /tvangsfjerning, hva Fjern AD DS-rollen uten å forsøke å replikere endringene til resten av skogen.I moderne miljøer har veiviseren endret seg, men konseptet er det samme: å fjerne den problematiske domenet fra AD-topologien uten at den deltar i videre replikering.

Etter en tvungen nedgradering er det obligatorisk å utføre en kommando fra en syk domenekontroller. metadata-rensing ved hjelp av verktøyet NtdsutilDenne prosessen fjerner alle referanser til den slettede domenet (NTDS-innstillingsobjekter, DNS-referanser osv.) fra AD-databasen, slik at ingen "spøkelses"-rester gjenstår for å forvirre replikasjonen.

Hvis den degraderte kontrolleren hadde FSMO-roller (PDC Emulator, RID Master, Schema Master osv.), vil det være nødvendig å overfører eller overtar disse rollene til en annen DC før eller etter degraderingen, avhengig av situasjonen. Senere kan operativsystemet installeres på nytt på den serveren, og det kan forfremmes tilbake til en ren DC.

Ikke-autoritativ vs. autoritativ gjenoppretting i Active Directory

Når en gyldig kopi av systemstatusen er tilgjengelig, kan AD-gjenoppretting gjøres på to måter: ikke-autoritær og autoritativÅ forstå forskjellen er nøkkelen til å ikke gå glipp av nylige endringer eller replikere utdaterte data.

I en ikke-autoritær restaureringDC-en returneres til et tidligere punkt, men når den starter, De andre domenekontrollerne regnes som referansenMed andre ord, etter oppstart ber den gjenopprettede domenekontrolløren om innkommende replikering og oppdaterer databasen sin med eventuelle manglende endringer fra de andre domenekontrollørene. Dette alternativet er ideelt når Det finnes andre friske kontrollere, og vi vil at den gjenopprettede skal ta igjen dem..

I en autoritær restaureringDet er imidlertid eksplisitt sagt at Det er de gjenopprettede dataene som skal gjelde. over det de andre domenets kontrollenheter har. Dette betyr at de gjenopprettede objektene etter gjenopprettingen vil ha et høyere versjonsnummer som tvinger dem til å bli replikert fra den kontrollenheten til resten av domenet. Det er det riktige valget når Vi har ved et uhell slettet objekter eller OU-er, eller vi ønsker å tilbakestille innholdet i SYSVOL og GPO til en tidligere tilstand og få det replikert..

En viktig detalj er at autoritativ gjenoppretting ikke nødvendigvis trenger å gjelde hele databasen. Med verktøyet Ntdsutil Individuelle objekter, undertrær (f.eks. en OU) eller hele domenet kan merkes som autoritative. Dette gir betydelig fleksibilitet for for eksempel hente bare en bruker, en gruppe, en OU eller undertreet dc=mittselskap,dc=lokal.

Generell prosedyre for å gjenopprette systemstatus i en DC

Den grunnleggende måten å gjenopprette systemtilstanden til en DC (enten fysisk eller virtuell) med kompatible verktøy er alltid lik: Start opp i gjenopprettingsmodus for katalogtjenester (DSRM), gjenopprett ved hjelp av sikkerhetskopieringsverktøyet, og start på nytt.

Oppsummert vil de typiske trinnene for en virtuell domenekontroller være:

1. Start den virtuelle maskinen i Windows Boot Manager (vanligvis ved å trykke F5/F8 under oppstart). Hvis den virtuelle maskinen administreres av en hypervisor, kan det være nødvendig å sette maskinen på pause for å fange opp tastetrykket.
2. I de avanserte oppstartsalternativene velger du Gjenopprettingsmodus for katalogtjenester (Gjenopprettingsmodus for katalogtjenester). Denne modusen starter serveren uten å montere Active Directory-databasen på en funksjonell måte.
3. Logg inn med DSRM-administratorkontoen definert under den opprinnelige promoteringen av DC (ikke med en standard domeneadministratorkonto).
4. Kjør sikkerhetskopieringsverktøyet brukes (Windows Server Backup, NAKIVO eller annen kompatibel) og velger å gjenopprette systemtilstanden til ønsket sikkerhetskopieringspunkt.
5. Fullfør gjenopprettingsveiviseren og Start DC-en på nytt i normal modusI en ikke-autoritativ gjenoppretting vil serveren starte replikering for å ta igjen de andre domenene.

Når vi snakker om tredjeparts sikkerhetskopieringsprodukter, som f.eks. NAKIVO Backup & ReplikeringDens "app-bevisste" modus er i stand til å gjenkjenne at maskinen som gjenopprettes er en likestrømsenhet, og juster prosessen automatisk for å bevare AD-konsistensI de fleste scenarier med flere kontrollere er en fullstendig gjenoppretting i ikke-autoritativ modus tilstrekkelig.

Autoritativ restaurering med Ntdsutil

Hvis du vil at endringene på den gjenopprettede domenekontrolleren skal prioriteres over resten, må du legge til et ekstra trinn etter den ikke-autoritative gjenopprettingen: bruk Ntdsutil til å markere objekter som autoritative.

Den forenklede flyten ville være:

1. Gjenopprett systemtilstanden på standardmåten og la serveren fortsatt være i DSRM-modus (Ikke start på nytt i normal modus ennå).
2. Åpne a ledetekst med utvidede rettigheter og løp ntdsutil.
3. Aktiver AD-forekomsten med aktivere instans-ntd-er.
4. Å gå inn i konteksten av autoritativ restaurering med autoritativ gjenoppretting.
5. Bruk kommandoer som restore object <DN_objeto> o restore subtree <DN_subarbol>, der DN er det unike navnet på objektet eller undertreet som skal gjenopprettes autoritativt.
6. Bekreft transaksjonen, og når den er fullført, Start DC-en på nytt i normal modus slik at de merkede objektene replikeres med prioritet til resten av domenet.

Denne typen restaurering krever stor forsiktighet. Hvis hele domenet er autoritativt gjenopprettet og sikkerhetskopien er gammelDet er en risiko for å miste legitime endringer som er gjort etter sikkerhetskopien (for eksempel brukeroppretting, passordendringer eller gruppeendringer). Derfor er det vanlig praksis å begrense autoritative gjenopprettinger til kun de strengt nødvendige objektene eller trærne.

SYSVOL-restaurering og -gjenoppretting (FRS vs. DFSR)

SYSVOL er en nøkkelkomponent i domenekontrolleren: Den lagrer oppstartsskript, gruppepolicyer, sikkerhetsmaler og andre viktige delte ressurser.En feil i tillatelsene dine, filskade eller replikeringsproblemer kan gjøre gruppepolicyobjekter ubrukelige eller forårsake uregelmessig oppførsel hos klienter.

Avhengig av Windows Server-versjonen og migreringsstatusen, kan SYSVOL replikeres av FRS (filreplikeringstjeneste) eller ved DFSR (Distribuert filsystemreplikering)Prosedyren for en autoritativ gjenoppretting av SYSVOL varierer avhengig av hvilken av de to som er i bruk.

For å finne ut dette kan du sjekke nøkkelen i registeret. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrering av Sysvols\LocalStateHvis denne undernøkkelen finnes og verdien er 3 (SLETTET), brukes DFSR. Hvis den ikke finnes eller verdien er annerledes, har vi å gjøre med et miljø som fortsatt bruker FRS.

I miljøer med FRS innebærer autoritativ gjenoppretting av SYSVOL vanligvis å justere verdien Burflags en HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process til en bestemt verdi (f.eks. 212 desimaler / 0xD4 heksadesimaler) for å indikere at denne domenen er den autoritative kilden.

Hvis SYSVOL replikeres av DFSR, er prosessen noe mer omfattende: den innebærer bruk av ADSIEdit å endre SYSVOL-abonnementsobjekter (attributter msDFSR-aktivert y msDFSR-alternativer) på den autoritative domenet og på de andre, tving frem AD-replikering, utfør dfsrdiag pollad og bekreft i hendelsesloggen at hendelsene 4114, 4602, 4614 og 4604 som bekrefter at SYSVOL er initialisert og replikert riktig.

Gjenopprette virtuelle domenekontrollere fra VHD

I virtualiserte miljøer er det veldig vanlig å ha VHD/VHDX-filer for domenekontrollereHvis du ikke har en sikkerhetskopi av systemtilstanden, men har en fungerende «gammel» VHD, kan du montere en ny DC fra den disken, men du må gjøre det svært forsiktig for å unngå å forårsake en USN-tilbakerulling.

Anbefalingen er Ikke start den virtuelle maskinen direkte i normal modusI stedet bør du starte opp fra den forrige VHD-en i DSRMÅpne Registerredigering og naviger til HKLM\SYSTEM\CurrentControlSet\Services\NTDS\ParametersDer er det lurt å sjekke verdien Antall tidligere DSA-restaureringer (hvis den finnes) og fremfor alt, opprett en ny DWORD-verdi (32-bit) kalt Database gjenopprettet fra sikkerhetskopi med verdi 1.

Ved å velge denne verdien får Active Directory beskjed om at databasen er gjenopprettet fra en sikkerhetskopi, noe som tvinger frem genererer en ny InvocationID ved oppstart i normal modusPå denne måten tolker de andre domenekontrollørene det som en ny forekomst og justerer replikeringsvannmerkene sine riktig, noe som forhindrer tilbakerulling av USN.

Etter at du har startet DC-en på nytt i normal modus, anbefales det å sjekke hendelsesvisningen, spesielt loggen til Katalogtjenester, på jakt etter arrangement 1109Denne hendelsen bekrefter at serverens InvocationID-attributt er endret, og viser de gamle og nye verdiene, samt den høyeste USN-en på sikkerhetskopieringstidspunktet. I tillegg er verdien av Antall tidligere DSA-restaureringer Den burde ha økt med én.

Hvis disse hendelsene ikke vises, eller antallet ikke øker, bør du sjekke operativsystemversjonene og servicepakkene, siden Visse restaureringsatferder avhenger av spesifikke oppdateringerUansett er det alltid lurt å jobbe med en kopi av den originale VHD-en, og beholde en intakt versjon i tilfelle prosessen må gjentas.

Praktiske scenarier og ytterligere anbefalinger

I praksis dukker det ofte opp problemer med korrupsjon eller feilaktige restaureringer i hverdagsscenarier: Manuelle endringer av tillatelser i SYSVOL, forsøk på å oppdatere ADMX/ADML-maler, GPO-endringer som ikke replikeresosv. Det er relativt enkelt å forårsake inkonsekvenser hvis delte mapper endres manuelt, for eksempel SYSVOL\Policies uten å respektere replikering.

Ved en primær DC med ødelagt replikering (både AD-data og SYSVOL) og overvåkingsmeldinger av typen «Databasen ble gjenopprettet ved hjelp av en prosedyre som ikke støttes. Mulig årsak: Tilbakerulling av USN«, det kloke å gjøre er:

• Sjekk med dcdiag y repadmin omfanget av feilene og om det finnes «vedvarende objekter».
• Sjekk hendelse 2095 og verdien DSA ikke skrivbar i registeret.
• Vurder om det er mulig fjern den DC-en og bygg den opp igjen (Hvis det er tre eller flere andre friske dendritiske celler, er dette vanligvis det beste alternativet).
• Hvis det er den eneste DC eller kritikeren, ta opp en gjenoppretting av systemtilstand fra en kompatibel sikkerhetskopi, ideelt sett nylig og innenfor tombstone-perioden.

I domener med flere kontrollere anbefales det på det sterkeste at domenene for kontrollere er så «rene» som mulig: uten ytterligere roller eller lokale brukerdataPå denne måten, hvis en feiler eller blir ødelagt, kan en ny formateres og promoteres basert på en annen DC eller gjennom IFM, noe som reduserer kompleksiteten ved gjenoppretting betraktelig.

Videre er det verdt å huske på begrensninger som at Systemstatuskopier er bare gyldige i tombstone-perioden (60, 90, 180 dager avhengig av konfigurasjonen) for å unngå å gjenopplive slettede objekter, og at NTLM-maskinnøkler endres hver 7. dag. I svært gamle gjenopprettinger kan det være nødvendig å tilbakestill teamkontoer problemer fra «Active Directory-brukere og -datamaskiner» eller til og med fjerne dem og koble dem til domenet igjen.

Ha prosedyrer på plass for regelmessig sikkerhetskopiering av systemets tilstand, Dokumenter FSMO-rollene, den globale katalogen og replikasjonstopologien tydeligOg å teste gjenopprettingstrinnene i et labmiljø er tidsinvesteringer som sparer deg for mye hodebry når dagen kommer at en domenekontroller blir ødelagt eller noen bruker et øyeblikksbilde uten å tenke seg om.