Gendannelse og genoprettelse af en beskadiget lokal domænecontroller

Når en domænecontroller bliver beskadiget eller gendannes forkert, er skrækken enorm: Login mislykkes, GPO'er holder op med at anvendes, og replikering bryder sammen næsten uden spor.Den gode nyhed er, at der er klare procedurer for at gendanne en fysisk eller virtuel DC, forudsat at de accepterede sikkerhedskopierings- og gendannelsesmetoder respekteres.

I moderne Windows Server-miljøer kræver gendannelse af en domænecontroller en god forståelse af koncepter som f.eks. systemstatus, autoritativ/ikke-autoritativ gendannelse, SYSVOL-, DFSR/FRS- og USN-rollbacksHvis disse problemer håndteres forhastet eller med inkompatible billeddannelsesværktøjer, kan resultatet være en skov fuld af tavse uoverensstemmelser, der er meget vanskelige at diagnosticere.

Hvorfor det er afgørende at beskytte og gendanne en domænecontroller korrekt

Active Directory er hjertet i godkendelse og autorisation i et Windows-domæneDen gemmer brugere, computere, grupper, tillidsforhold, gruppepolitikker, certifikater og andre kritiske elementer. Disse oplysninger findes primært i databasen. Ntds.dit, de tilhørende logfiler og mapper SYSVOL, blandt andre komponenter, der udgør den såkaldte "systemets tilstand".

Systemstatus omfatter blandt andet Active Directory-logfiler og -data, Windows-registreringsdatabasen, systemvolumen, SYSVOL, certifikatdatabasen (hvis der findes en certificeringscentral), IIS-metabasen, opstartsfiler og beskyttede operativsystemkomponenterDerfor skal enhver seriøs strategi for forretningskontinuitet omfatte regelmæssige sikkerhedskopier af systemtilstanden for hvert datacenter.

Når der opstår faktisk beskadigelse af Active Directory-databasen, en alvorlig replikeringsfejl eller et problem med tilladelser på SYSVOLDomænecontrolleren kan stoppe med at behandle forespørgsler, mislykkes med at starte Active Directory-tjenester eller udløse overlappende fejl i hele skoven. I disse tilfælde, En hurtig og korrekt genopretning er forskellen mellem en alvorlig hændelse og en langvarig katastrofe..

Før man forsøger en gendannelse, er det afgørende at skelne mellem et ægte databaseproblem og mere almindelige fejl. Meget ofte, Årsagen ligger i DNS, netværksændringer, firewalls eller ruter ændret med værktøjer som f.eks. netsh -kommandoDerfor er det tilrådeligt at udelukke disse faktorer først, før man rører ved AD-databasen.

Grundlæggende diagnostiske og replikeringskontrolværktøjer

I tilfælde af symptomer på korruption eller replikeringsfejl er det første fornuftige skridt at kontrollere miljøets tilstand ved hjælp af native værktøjer. DCDiag, Repadmin, ReplMon (i ældre versioner) og Logbogen De er dine bedste allierede, før du overvejer aggressive restaureringer.

med DCDiag Der udføres en generel kontrol af alle domænecontrollere, hvor problemer med replikering, DNS, AD DS-tjenester osv. identificeres. Repadmin Det giver dig mulighed for at se replikeringsstatus, replikeringspartnere, USN-vandmærker og registrere persistente objekter. I ældre versioner af Windows, ReplMon Den tilbød en grafisk visning af replikationsfejl inden for domænet.

Ud over disse værktøjer er det vigtigt at gennemgå Logbogen for "Directory Services" og "DFS Replication". Hændelser som 467 og 1018 peger på faktisk korruption af databasen, mens begivenhederne 1113/1115/1114/1116 vedrører aktivering eller deaktivering af input/output-replikering.

Hvis en mistænkt DC midlertidigt skal isoleres for at forhindre, at den spreder korruption, kan vi Deaktiver indgående og udgående replikering med Repadmin:

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

Og for at gendanne replikeringen til normal, skal du blot fjerne disse muligheder:

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

Understøttede sikkerhedskopier af systemtilstand på domænecontrollere

For at kunne inddrive en DC med garantier er det vigtigt at have Sikkerhedskopier af systemtilstand udført ved hjælp af Active Directory-kompatible værktøjerDisse værktøjer bruger Microsofts API'er til sikkerhedskopiering og gendannelse og Volume Shadow Copy Service (VSS) på en understøttet måde.

Blandt de mest almindelige løsninger er Windows Server Backup, tredjepartsløsninger integreret med VSS (såsom NAKIVO, Backup Exec og andre)eller ældre forsyningsvirksomheder som f.eks. Ntbackup i Windows 2000/2003. I alle tilfælde skal de respektere AD API'erne for at sikre databasens og dens replikaers konsistens efter gendannelse.

Windows Server 2012 og nyere versioner har en vigtig ny tilføjelse: Hyper-V Generations-ID (GenID)Denne identifikator gør det muligt for en virtuel domænecontroller at registrere, at dens disk er blevet rullet tilbage til et tidligere tidspunkt. Når dette sker, AD DS genererer et nyt InvocationID og behandler situationen, som om den var blevet gendannet fra en vellykket sikkerhedskopiering.underretter sine replikeringspartnere, hvilket muliggør sikker omskrivning uden at medføre en USN-rollback.

Det er vigtigt at respektere gravstenens levetidDette angiver, hvor længe en sikkerhedskopi af systemtilstanden kan bruges uden at risikere genindførelse af objekter, der er slettet for længe siden. Det er typisk 180 dage i moderne versioner, og det anbefales at udføre sikkerhedskopier mindst hver 90. dag for at opretholde en tilstrækkelig sikkerhedsmargin.

Uautoriserede metoder, der forårsager USN-tilbageførsler

En af de farligste årsager til tavse inkonsistenser i Active Directory er USN-tilbagerulningDenne situation opstår, når indholdet af AD-databasen rulles tilbage ved hjælp af en ikke-understøttet teknik, uden at InvocationID'et gendannes, eller replikeringspartnerne underrettes.

Det typiske scenarie er at starte en DC fra en diskbillede eller et snapshot af en virtuel maskine taget tidligereuden at bruge en kompatibel systemgendannelse. Eller kopier Ntds.dit-filen direkte, brug billeddannelsesprogrammer som Ghost, start fra et ødelagt diskspejl eller genanvend et lagersnapshot på array-niveau.

I disse tilfælde fortsætter domænecontrolleren med at bruge det samme InvocationID som før, men dets Lokal USN-tæller går baglænsDe andre DC'er husker at have modtaget ændringer op til en høj USN, så når den tilbageførte DC forsøger at sende allerede genkendte USN'er tilbage, Deres partnere mener, at de er opdaterede og holder op med at acceptere konkrete ændringer..

Resultatet er, at visse ændringer (f.eks. brugeroprettelse, ændringer af adgangskoder, enhedsregistrering, ændringer af gruppemedlemskab, nye DNS-posterDisse fejl replikeres aldrig fra den gendannede DC til resten af ​​netværket, men overvågningsværktøjer viser muligvis ikke tydelige fejl. Dette er en ekstremt farlig stille fejl.

For at registrere disse situationer logger Windows Server 2003 SP1 og nyere drivere Katalogtjenester-hændelse 2095 Når en fjerncontroller registreres, der sender allerede bekræftede USN'er uden ændring i InvocationID, vil systemet Den sætter den berørte DC i karantæne, sætter Netlogon på pause og forhindrer yderligere ændringer. som ikke kunne replikeres korrekt.

Som yderligere retsmedicinsk bevismateriale kan det skal konsulteres i registret nøglen HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parametre og værdien DSA ikke skrivbarHvis denne værdi er indstillet (f.eks. 0x4), indikerer det, at DC'en blev sat i en ikke-skrivetilstand af USN-omvendingsdetektion. Manuel ændring af denne værdi for at "rette" den understøttes fuldstændigt ikke. og efterlader databasen i en permanent inkonsekvent tilstand.

Generelle strategier i tilfælde af beskadigelse eller tilbageførsel af en domænecontroller

Proceduren, der skal følges, når man har en beskadiget eller forkert gendannet DC, afhænger af flere faktorer: Antal domænecontrollere i domænet/skoven, tilgængelighed af gyldige kopier af systemtilstanden, tilstedeværelse af andre roller (FSMO, CA, globalt katalog) og problemets tidsmæssige omfang.

Hvis der er andre sunde DC'er i domænet og Der er ingen unikke kritiske data på den beskadigede domænecontrollerDen hurtigste og reneste løsning er normalt at fjerne domænecontrolleren og genopbygge den. Men hvis det er den eneste domænecontroller, eller hvis den er vært for følsomme roller og data, vil en mere omhyggelig gendannelse (autoritativ eller ikke-autoritativ) være nødvendig.

Generelt set er mulighederne:

• Tvangsnedgrader den korrupte DC og fjern den fra domænet, efterfulgt af rensning af metadata og, hvis relevant, ny promovering.
• Gendan fra en gyldig sikkerhedskopi af systemtilstanden, uanset om det er i autoritativ eller ikke-autoritativ tilstand.
• Genopbyg DC'en fra en anden ved hjælp af IFM (Install From Media), når der ikke er nogen nyere kopi, men der er andre korrekte DC'er.
• Brug af et VHD-snapshot af en virtuel DC, og anvende de yderligere trin for at markere databasen som gendannet fra sikkerhedskopi (Database gendannet fra sikkerhedskopi = 1) og sikre, at et nyt InvocationID genereres.

Hvis der er en klar mistanke om en USN-rollback (f.eks. efter gendannelse af en VM fra et snapshot uden at følge bedste praksis), og hændelse 2095 vises, er den mest fornuftige fremgangsmåde normalt at Tag den pågældende DC ud af drift, og forsøg ikke at "reparere" den på stedet., medmindre det er muligt at vende tilbage til en sikkerhedskopi af den understøttede systemtilstand, der blev taget før tilbagerulningen.

Tvungen degradering og oprydning af metadata

Når en domænecontroller er så beskadiget, at den ikke kan degraderes normalt, eller er blevet gendannet forkert, og du vil forhindre, at den spreder problemer, kan du ty til en tvungen degradering.

I ældre versioner blev denne operation udført med dcpromo /forceremoval, hvad Fjern AD DS-rollen uden at forsøge at replikere ændringerne til resten af ​​skoven.I moderne miljøer har guiden ændret sig, men konceptet er det samme: at fjerne den problematiske DC fra AD-topologien uden at den deltager i yderligere replikering.

Efter en tvungen nedgradering er det obligatorisk at udføre en kommando fra en sund DC. rensning af metadata ved hjælp af værktøjet NtdsutilDenne proces fjerner alle referencer til den slettede DC (NTDS-indstillingsobjekter, DNS-referencer osv.) fra AD-databasen, så ingen "spøgelses"-rester tilbage, der kan forvirre replikationen.

Hvis den degraderede controller havde FSMO-roller (PDC Emulator, RID Master, Schema Master osv.), vil det være nødvendigt at overfører eller overtager disse roller til en anden DC før eller efter degraderingen, afhængigt af situationen. Senere kan operativsystemet geninstalleres på den server, og det kan forfremmes tilbage til en ren DC.

Ikke-autoritær vs. autoritativ gendannelse i Active Directory

Når en gyldig kopi af systemtilstanden er tilgængelig, kan AD-gendannelse udføres på to måder: ikke-autoritative og autoritativeAt forstå forskellen er nøglen til ikke at gå glip af nylige ændringer eller replikere forældede data.

I én ikke-autoritær restaureringDC'en returneres til et tidligere punkt, men når den starter, De andre domænecontrollere betragtes som referencenMed andre ord anmoder den gendannede DC efter opstart om indgående replikering og opdaterer sin database med eventuelle manglende ændringer fra de andre DC'er. Denne mulighed er ideel, når Der er andre raske controllere, og vi vil have, at den gendannede skal indhente dem..

I én autoritær restaureringDet er dog eksplicit angivet, at De gendannede data er det, der skal være gældende. i forhold til hvad de andre DC'er har. Det betyder, at de gendannede objekter efter gendannelsen vil have et højere versionsnummer, der tvinger dem til at blive replikeret fra den pågældende DC til resten af ​​domænet. Det er det passende valg, når Vi har ved et uheld slettet objekter eller OU'er, eller vi ønsker at vende tilbage til indholdet af SYSVOL og GPO til en tidligere tilstand og få det replikeret..

En vigtig detalje er, at autoritativ gendannelse ikke nødvendigvis behøver at være for hele databasen. Med værktøjet Ntdsutil Individuelle objekter, undertræer (f.eks. en OU) eller hele domænet kan markeres som autoritative. Dette giver betydelig fleksibilitet til f.eks. hente kun en bruger, en gruppe, en OU eller undertræet dc=mycompany,dc=local.

Generel procedure for gendannelse af systemstatus i en DC

Den grundlæggende metode til at gendanne systemtilstanden for en DC (uanset om den er fysisk eller virtuel) med kompatible værktøjer er altid den samme: Start i Directory Services Restore Mode (DSRM), gendan ved hjælp af sikkerhedskopieringsværktøjet, og genstart.

Kort sagt ville de typiske trin for en virtuel domænecontroller være:

1. Start den virtuelle maskine i Windows Boot Manager (normalt ved at trykke på F5/F8 under opstart). Hvis den virtuelle maskine administreres af en hypervisor, kan det være nødvendigt at sætte maskinen på pause for at registrere tastetrykket.
2. I de avancerede opstartsindstillinger skal du vælge Gendannelsestilstand for katalogtjenester (Gendannelsestilstand for katalogtjenester). Denne tilstand starter serveren uden at montere Active Directory-databasen på en funktionel måde.
3. Log ind med DSRM-administratorkontoen defineret under den oprindelige promovering af DC'en (ikke med en standard domæneadministratorkonto).
4. Kør sikkerhedskopieringsværktøjet brugt (Windows Server Backup, NAKIVO eller anden kompatibel) og vælg at gendanne systemtilstanden til det ønskede backuppunkt.
5. Færdiggør gendannelsesguiden og Genstart DC'en i normal tilstandI en ikke-autoritativ gendannelse vil serveren starte replikering for at indhente de andre dommerstyrede systemer.

Når vi taler om tredjeparts backupprodukter, som f.eks. NAKIVO Backup & ReplikeringDens "app-bevidste" tilstand er i stand til at genkende, at den maskine, der gendannes, er en DC, og automatisk justere processen for at bevare AD-konsistensI de fleste scenarier med flere controllere er en fuld gendannelse i ikke-autoritativ tilstand tilstrækkelig.

Autoritativ gendannelse med Ntdsutil

Hvis du vil have ændringerne på den gendannede domænecontroller til at have forrang over resten, skal du tilføje et ekstra trin efter den ikke-autoritative gendannelse: Brug Ntdsutil til at markere objekter som autoritative.

Det forenklede flow ville være:

1. Gendan systemtilstanden på standardmåden og lad serveren stadig være i DSRM-tilstand (Genstart ikke i normal tilstand endnu).
2. Åbn a kommandoprompt med forhøjede rettigheder og løb ntdsutil.
3. Aktivér AD-instansen med aktiver instans-ntd'er.
4. Indtræden i konteksten af ​​autoritativ restaurering med autoritativ gendannelse.
5. Brug kommandoer som f.eks restore object <DN_objeto> o restore subtree <DN_subarbol>, hvor DN er det entydige navn på det objekt eller undertræ, der skal gendannes autoritativt.
6. Bekræft transaktionen, og når den er gennemført, Genstart DC'en i normal tilstand således at de markerede objekter replikeres med prioritet til resten af ​​domænet.

Denne type restaurering kræver stor forsigtighed. Hvis hele domænet er autoritativt gendannet, og sikkerhedskopien er gammelDer er risiko for at miste legitime ændringer foretaget efter sikkerhedskopieringen (f.eks. brugeroprettelse, ændringer af adgangskoder eller gruppeændringer). Derfor er det almindelig praksis at begrænse autoritative gendannelser til kun de strengt nødvendige objekter eller træer.

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

SYSVOL er en nøglekomponent i domænecontrolleren: Den gemmer opstartsskripter, gruppepolitikker, sikkerhedsskabeloner og andre vigtige delte ressourcer.En fejl i dine tilladelser, filbeskadigelse eller replikeringsproblemer kan gøre GPO'er ubrugelige eller forårsage uregelmæssig adfærd i klienter.

Afhængigt af Windows Server-versionen og migreringsstatussen kan SYSVOL blive replikeret af FRS (filreplikeringstjeneste) eller for DFSR (Distribueret filsystemreplikering)Proceduren for en autoritativ gendannelse af SYSVOL varierer afhængigt af hvilken af ​​de to der er i brug.

For at afgøre dette kan du kontrollere nøglen i registreringsdatabasen. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrering af Sysvols\LocalStateHvis denne undernøgle findes, og dens værdi er 3 (SLET), bruges DFSR. Hvis den ikke findes, eller dens værdi er anderledes, har vi at gøre med et miljø, der stadig bruger FRS.

I miljøer med FRS involverer autoritativ gendannelse af SYSVOL normalt justering af værdien Burflags en HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process til en specifik værdi (f.eks. 212 decimal / 0xD4 hex) for at angive, at denne DC er den autoritative kilde.

Hvis SYSVOL replikeres af DFSR, er processen noget mere omfattende: den involverer brug af ADSIEdit at ændre SYSVOL-abonnementsobjekter (attributter msDFSR-aktiveret y msDFSR-indstillinger) på den autoritative DC og på de andre, tving AD-replikering frem, udfør dfsrdiag pollad og bekræft i hændelsesloggen forekomsten af begivenhederne 4114, 4602, 4614 og 4604 der bekræfter, at SYSVOL er blevet initialiseret og replikeret korrekt.

Gendannelse af virtuelle domænecontrollere fra VHD

I virtualiserede miljøer er det meget almindeligt at have VHD/VHDX-filer for domænecontrollereHvis du ikke har en sikkerhedskopi af systemtilstanden, men har en fungerende "gammel" VHD, kan du montere en ny DC fra den disk, men du skal gøre det meget forsigtigt for at undgå at forårsage en USN-rollback.

Anbefalingen er Start ikke den virtuelle maskine direkte i normal tilstandI stedet bør du starte fra den forrige VHD i DSRMÅbn Registreringseditoren og naviger til HKLM\SYSTEM\CurrentControlSet\Services\NTDS\ParametersDer er det tilrådeligt at tjekke værdien Antal tidligere DSA-restaureringer (hvis den findes) og frem for alt opret en ny DWORD-værdi (32-bit) kaldet Database gendannet fra backup med værdi 1.

Ved at vælge denne værdi får Active Directory besked om, at databasen er blevet gendannet fra en sikkerhedskopi, hvilket tvinger generering af et nyt InvocationID ved opstart i normal tilstandPå denne måde fortolker de andre DC'er det som en ny instans og justerer deres replikeringsvandmærker korrekt, hvilket forhindrer USN-rollback.

Efter genstart af DC'en i normal tilstand, anbefales det at kontrollere Logbogen, især loggen over Directory tjenester, leder efter begivenhed 1109Denne hændelse bekræfter, at serverens InvocationID-attribut er ændret, og viser de gamle og nye værdier samt den højeste USN på tidspunktet for sikkerhedskopieringen. Derudover er værdien af Antal tidligere DSA-restaureringer Den burde have været forøget med én.

Hvis disse hændelser ikke vises, eller antallet ikke stiger, bør du kontrollere operativsystemversionerne og servicepakkerne, da Visse gendannelsesadfærd afhænger af specifikke programrettelserUnder alle omstændigheder er det altid tilrådeligt at arbejde på en kopi af den originale VHD og beholde en intakt version, i tilfælde af at processen skal gentages.

Praktiske scenarier og yderligere anbefalinger

I praksis opstår der ofte problemer med korruption eller ukorrekte restaureringer i hverdagsscenarier: Manuelle ændringer af tilladelser i SYSVOL, forsøg på at opdatere ADMX/ADML-skabeloner, GPO-ændringer, der ikke replikeresosv. Det er relativt nemt at forårsage uoverensstemmelser, hvis delte mapper ændres manuelt, f.eks. SYSVOL\Policies uden respekt for replikering.

I tilfælde af en primær DC med brudt replikering (både AD-data og SYSVOL) og overvågningsmeddelelser af typen "Databasen blev gendannet ved hjælp af en ikke-understøttet procedure. Mulig årsag: USN-rollback", er det klogeste at gøre:

• Tjek med dcdiag y genadmin omfanget af fejlene og om der er "vedvarende objekter".
• Tjek hændelse 2095 og værdien DSA ikke skrivbar i registret.
• Vurder om det er muligt fjern den DC og genopbyg den (Hvis der er tre eller flere andre raske dendritiske celler, er dette normalt den bedste mulighed).
• Hvis det er den eneste DC eller kritiker, så rejs en gendannelse af systemtilstand fra en kompatibel sikkerhedskopi, ideelt set nyere og inden for tombstone-perioden.

I domæner med flere controllere anbefales det kraftigt, at DC'erne er så "rene" som muligt: uden yderligere roller eller lokale brugerdataPå denne måde kan en ny formateres og promoveres baseret på en anden DC eller via IFM, hvis en fejler eller bliver beskadiget, hvilket reducerer kompleksiteten af ​​gendannelsen betydeligt.

Derudover er det værd at huske på begrænsninger som f.eks. Systemtilstandskopier er kun gyldige i tombstone-perioden (60, 90, 180 dage afhængigt af konfigurationen) for at undgå at genoplive slettede objekter, og at NTLM-maskinnøgler ændres hver 7. dag. I meget gamle gendannelser kan det være nødvendigt at nulstil teamkonti problemer fra "Active Directory-brugere og -computere" eller endda fjerne dem og genforbinde dem med domænet.

At have procedurer på plads til regelmæssig sikkerhedskopiering af systemets tilstand, Dokumentér tydeligt FSMO-rollerne, det globale katalog og replikationstopologienOg at teste gendannelsestrinnene i et laboratoriemiljø er tidsinvesteringer, der sparer en masse hovedpine, når den dag kommer, hvor en domænecontroller bliver beskadiget, eller nogen anvender et snapshot uden at tænke sig om.