Återställa och återställa en skadad lokal domänkontrollant

När en domänkontrollant blir skadad eller återställs felaktigt är oron enorm: Inloggningar misslyckas, gruppolicyobjekt slutar tillämpas och replikeringen bryts ner nästan utan några ledtrådar.Den goda nyheten är att det finns tydliga procedurer för att återställa en fysisk eller virtuell domänkontrollant, förutsatt att de accepterade säkerhetskopierings- och återställningsmetoderna respekteras.

I moderna Windows Server-miljöer kräver återställning av en domänkontrollant en god förståelse för begrepp som systemstatus, auktoritativ/icke-auktoritativ återställning, SYSVOL-, DFSR/FRS- och USN-återställningarOm dessa problem åtgärdas förhastat eller med inkompatibla avbildningsverktyg kan resultatet bli en skog full av tysta inkonsekvenser som är mycket svåra att diagnostisera.

Varför det är viktigt att skydda och återställa en domänkontrollant på rätt sätt

Active Directory är hjärtat i autentisering och auktorisering i en Windows-domänDen lagrar användare, datorer, grupper, förtroendeförhållanden, grupprinciper, certifikat och andra viktiga element. Denna information finns huvudsakligen i databasen. Ntds.dit, de tillhörande loggfilerna och mappen SYSVOL, bland andra komponenter som utgör det så kallade "systemets tillstånd".

Systemstatusen inkluderar bland annat Active Directory-loggfiler och data, Windows-registret, systemvolymen, SYSVOL, certifikatdatabasen (om en certifikatutfärdare finns), IIS-metabasen, startfiler och skyddade operativsystemkomponenterDärför måste varje seriös strategi för affärskontinuitet inkludera regelbundna säkerhetskopior av systemtillståndet för varje datacenter.

När det inträffar en faktisk skada på Active Directory-databasen, ett allvarligt replikeringsfel eller ett problem med behörigheter på SYSVOLDomänkontrollanten kan sluta bearbeta frågor, misslyckas med att starta Active Directory-tjänster eller utlösa kaskadfel i hela skogen. I dessa fall, En snabb och korrekt återhämtning gör skillnaden mellan en allvarlig incident och en långvarig katastrof..

Innan man försöker återställa databasen är det viktigt att skilja mellan ett verkligt databasproblem och mer vardagliga fel. Mycket ofta, Orsaken ligger i DNS, nätverksändringar, brandväggar eller rutter som modifierats med verktyg som netsh -kommandotDärför är det lämpligt att utesluta dessa faktorer först innan man vidrör AD-databasen.

Grundläggande verktyg för diagnostik och replikeringskontroll

Vid symptom på korruption eller replikeringsfel är det första förnuftiga steget att kontrollera miljöns tillstånd med hjälp av inbyggda verktyg. DCDiag, Repadmin, ReplMon (i äldre versioner) och händelseläsaren De är dina bästa allierade innan du överväger aggressiva restaureringar.

med DCDiag En allmän kontroll av alla domänkontrollanter utförs, där problem med replikering, DNS, AD DS-tjänster etc. identifieras. Repadmin Den låter dig visa replikeringsstatus, replikeringspartners, USN-vattenstämplar och identifiera beständiga objekt. I äldre versioner av Windows, ReplMon Den erbjöd en grafisk vy över replikeringsfel inom domänen.

Utöver dessa verktyg är det viktigt att granska Loggboken för "Directory Services" och "DFS Replication". Händelser som 467 och 1018 pekar på faktisk korruption av databasen, medan händelserna 1113/1115/1114/1116 avser att aktivera eller inaktivera indata/utdata-replikering.

Om en misstänkt DC behöver isoleras tillfälligt för att förhindra att korruption sprider sig, kan vi Inaktivera inkommande och utgående replikering med Repadmin:

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

Och för att återställa replikeringen till det normala, ta helt enkelt bort dessa alternativ:

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

Stödda säkerhetskopior av systemtillstånd på domänkontrollanter

För att kunna återkräva en DC med garantier är det viktigt att ha Säkerhetskopiering av systemstatus utförd med Active Directory-kompatibla verktygDessa verktyg använder Microsofts API:er för säkerhetskopiering och återställning och Volume Shadow Copy Service (VSS) på ett stödt sätt.

Bland de vanligaste lösningarna är Windows Server Backup, tredjepartslösningar integrerade med VSS (som NAKIVO, Backup Exec med flera)eller äldre verktyg som t.ex. Ntbackup i Windows 2000/2003. I samtliga fall måste de respektera AD API:erna för att säkerställa databasens och dess replikers konsekvens efter återställning.

Windows Server 2012 och senare versioner har ett viktigt nytt tillägg: Hyper-V Generation ID (GenID)Denna identifierare gör det möjligt för en virtuell domänkontrollant att upptäcka att dess disk har rullats tillbaka till en tidigare tidpunkt. När detta inträffar, AD DS genererar ett nytt InvocationID och behandlar situationen som om den hade återställts från en lyckad säkerhetskopia.meddelar sina replikeringspartners, vilket möjliggör säker omskrivning utan att medföra en USN-återställning.

Det är viktigt att respektera gravstenens livslängdDetta indikerar hur länge en säkerhetskopia av systemtillstånd kan användas utan att riskera att objekt som raderats för länge sedan återinförs. Det är vanligtvis 180 dagar i moderna versioner, och det rekommenderas att säkerhetskopiera minst var 90:e dag för att upprätthålla tillräcklig säkerhetsmarginal.

Obehöriga metoder som orsakar USN-återföringar

En av de farligaste orsakerna till tysta inkonsekvenser i Active Directory är USN-återställningDen här situationen uppstår när innehållet i AD-databasen återställs med en teknik som inte stöds, utan att InvocationID återställs eller replikeringspartnerna meddelas.

Det typiska scenariot är att starta en domänkontrollant från en diskbild eller en ögonblicksbild av en virtuell maskin som tagits tidigareutan att använda en kompatibel systemåterställning. Eller kopiera Ntds.dit-filen direkt, använd avbildningsprogram som Ghost, starta från en trasig diskspegel eller återanvänd en lagringsögonblicksbild på arraynivå.

I dessa fall fortsätter domänkontrollanten att använda samma InvocationID som tidigare, men dess Lokal USN-räknare går baklängesDe andra DC:erna kommer ihåg att de mottagit ändringar upp till ett högt USN, så när den återställda DC:n försöker skicka tillbaka redan igenkända USN:er, Deras partners tror att de är uppdaterade och slutar acceptera konkreta förändringar..

Resultatet blir att vissa modifieringar (till exempel användarskapande, lösenordsändringar, enhetsregistrering, ändringar av gruppmedlemskap, nya DNS-posterDessa fel replikeras aldrig från den återställda domänkontrollanten till resten av nätverket, men övervakningsverktyg kanske inte visar tydliga fel. Detta är ett extremt farligt tyst fel.

För att upptäcka dessa situationer loggar drivrutiner för Windows Server 2003 SP1 och senare Katalogtjänsthändelse 2095 När en fjärrkontrollant upptäcks som skickar redan bekräftade USN:er utan ändring i InvocationID, Den sätter den berörda domänkontrollanten i karantän, pausar Netlogon och förhindrar att ytterligare ändringar sker. som inte kunde replikeras korrekt.

Som ytterligare kriminaltekniskt bevis kan det att konsulteras i registret nyckeln HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parametrar och värdet DSA inte skrivbarOm detta värde är inställt (t.ex. 0x4) indikerar det att DC:n försattes i ett skrivfritt tillstånd av USN-omkastningsdetektering. Att manuellt ändra detta värde för att "åtgärda" det stöds inte helt. och lämnar databasen i ett permanent inkonsekvent tillstånd.

Allmänna strategier vid korruption eller återställning av en domänkontrollant

Proceduren att följa vid hantering av en skadad eller felaktigt återställd domänkontrollant beror på flera faktorer: Antal domänkontrollanter i domänen/skogen, tillgänglighet av giltiga kopior av systemtillståndet, förekomst av andra roller (FSMO, CA, global katalog) och problemets tidsmässiga omfattning.

Om det finns andra friska DC:er i domänen och Det finns inga unika kritiska data om den skadade domänkontrollantenDet snabbaste och renaste alternativet är vanligtvis att ta bort domänkontrollanten och återskapa den. Men om det är den enda domänkontrollanten, eller om den är värd för känsliga roller och data, kommer en mer noggrann återställning (auktoritativ eller icke-auktoritativ) att vara nödvändig.

Generellt sett är alternativen:

• Tvångsmässigt degradera den korrupta domänkontrollanten och ta bort den från domänen., följt av rensning av metadata och, om tillämpligt, ny marknadsföring.
• Återställ från en giltig säkerhetskopia av systemtillståndet, oavsett om det är i auktoritativt eller icke-auktoritativt läge.
• Återuppbygg domänkontrollanten från en annan med hjälp av IFM (Install From Media), när det inte finns någon nyligen publicerad kopia men det finns andra korrekta domänkontrollanter.
• Använda en VHD-ögonblicksbild av en virtuell domänkontrollant, och tillämpa de ytterligare stegen för att markera databasen som återställd från säkerhetskopia (Database restored from backup = 1) och säkerställa att ett nytt InvocationID genereras.

Om en USN-återställning tydligt misstänks (till exempel efter att en virtuell maskin har återställts från en ögonblicksbild utan att följa bästa praxis) och händelse 2095 visas, är den mest förnuftiga åtgärden vanligtvis att Ta bort den likströmsenheten från drift och försök inte "reparera" den på plats., såvida det inte är möjligt att återgå till en säkerhetskopia av det systemtillstånd som stöds och som togs före återställningen.

Tvingad degradering och rensning av metadata

När en domänkontrollant är så skadad att den inte kan degraderas normalt, eller har återställts felaktigt och du vill förhindra att problem sprider sig, kan du tillgripa en tvångsdegradering.

I äldre versioner utfördes denna operation med dcpromo /forceremoval, Vad Ta bort AD DS-rollen utan att försöka replikera ändringarna till resten av skogen.I moderna miljöer har guiden förändrats, men konceptet är detsamma: att ta bort den problematiska domänkontrollanten från AD-topologin utan att den deltar i ytterligare replikering.

Efter en påtvingad nedgradering är det obligatoriskt att köra ett kommando från en felfri domänkontrollant. metadatarensning med verktyget NtdsutilDen här processen tar bort alla referenser till den borttagna domänkontrollanten (NTDS-inställningsobjekt, DNS-referenser etc.) från AD-databasen, så att inga "spök"-rester kvarstår för att förvirra replikeringen.

Om den degraderade styrenheten hade FSMO-roller (PDC-emulator, RID-master, schemamaster etc.) kommer det att vara nödvändigt att överför eller övertar dessa roller till en annan domänkontrollant före eller efter degraderingen, beroende på situationen. Senare kan operativsystemet installeras om på den servern och det kan uppgraderas tillbaka till en ren domänkontrollant.

Icke-auktoritativ kontra auktoritativ återställning i Active Directory

När en giltig kopia av systemtillståndet är tillgänglig kan AD-återställning göras på två sätt: icke-auktoritär och auktoritärAtt förstå skillnaden är nyckeln till att inte missa nya ändringar eller replikera föråldrad data.

i en icke-auktoritativ restaureringDC:n återgår till en tidigare punkt, men när den väl startar, De andra domänkontrollanterna betraktas som referensenMed andra ord, efter uppstart begär den återställda domänkontrollanten inkommande replikering och uppdaterar sin databas med eventuella saknade ändringar från de andra domänkontrollanterna. Det här alternativet är idealiskt när Det finns andra friska kontrollanter, och vi vill att den återställda ska komma ikapp dem..

i en auktoritär restaureringDet anges emellertid uttryckligen att Det är den återställda informationen som ska gälla. jämfört med vad de andra domänkontrollanterna har. Det betyder att de återställda objekten efter återställningen kommer att ha ett högre versionsnummer för att tvinga dem att replikeras från den domänkontrollanten till resten av domänen. Det är det lämpliga valet när Vi har av misstag raderat objekt eller OU:er, eller så vill vi återställa innehållet i SYSVOL och GPO till ett tidigare tillstånd och replikera det..

En viktig detalj är att auktoritativ återställning inte nödvändigtvis behöver gälla hela databasen. Med verktyget Ntdsutil Enskilda objekt, underträd (t.ex. en OU) eller hela domänen kan markeras som auktoritativa. Detta ger avsevärd flexibilitet för till exempel hämta endast en användare, en grupp, en OU eller underträdet dc=mittföretag,dc=lokal.

Allmän procedur för att återställa systemstatus i en DC

Det grundläggande schemat för att återställa systemtillståndet för en domänkontrollant (oavsett om det är fysisk eller virtuell) med kompatibla verktyg är alltid liknande: Starta i DSRM (Directory Services Restore Mode), återställ med hjälp av säkerhetskopieringsverktyget och starta om.

Sammanfattningsvis skulle de typiska stegen för en virtuell domänkontrollant vara:

1. Starta den virtuella maskinen i Windows Boot Manager (vanligtvis genom att trycka på F5/F8 under start). Om den virtuella maskinen hanteras av en hypervisor kan det vara nödvändigt att pausa maskinen för att registrera tangenttryckningen.
2. I de avancerade startalternativen väljer du Återställningsläge för katalogtjänster (Återställningsläge för katalogtjänster). Det här läget startar servern utan att montera Active Directory-databasen på ett funktionellt sätt.
3. Logga in med DSRM-administratörskontot definierad under den ursprungliga marknadsföringen av domänkontrollanten (inte med ett standarddomänadministratörskonto).
4. Kör säkerhetskopieringsverktyget används (Windows Server Backup, NAKIVO eller annan kompatibel) och väljer att återställa systemtillståndet till önskad säkerhetskopieringspunkt.
5. Slutför återställningsguiden och Starta om DC:n i normalt lägeI en icke-auktoritativ återställning initierar servern replikering för att komma ikapp med de andra domänkontrollanterna.

När vi pratar om tredjepartsprodukter för säkerhetskopiering, som t.ex. NAKIVO Backup & ReplikeringDess "appmedvetna" läge kan känna igen att maskinen som återställs är en likströmsdriven enhet och justera processen automatiskt för att bevara AD-konsekvensI de flesta scenarier med flera styrenheter räcker det med en fullständig återställning i icke-auktoritativt läge.

Auktoritativ återställning med Ntdsutil

Om du vill att ändringarna på den återställda domänkontrollanten ska prioriteras framför resten måste du lägga till ett extra steg efter den icke-auktoritativa återställningen: använd Ntdsutil för att markera objekt som auktoritativa.

Det förenklade flödet skulle vara:

1. Återställ systemtillståndet på vanligt sätt och låt servern vara kvar i DSRM-läge (Starta inte om i normalt läge än).
2. Öppna a kommandotolken med förhöjda rättigheter och spring ntdsutil.
3. Aktivera AD-instansen med aktivera instans-ntd:er.
4. Att gå in i kontexten av auktoritativ restaurering med auktoritativ återställning.
5. Använd kommandon som restore object <DN_objeto> o restore subtree <DN_subarbol>, där DN är det unika namnet på det objekt eller underträd som ska återställas auktoritativt.
6. Bekräfta transaktionen och, när den är klar, Starta om DC:n i normalt läge så att de markerade objekten replikeras med prioritet till resten av domänen.

Denna typ av restaurering kräver stor försiktighet. Om hela domänen är auktoritativt återställd och säkerhetskopian är gammalDet finns en risk att man förlorar legitima ändringar som gjorts efter säkerhetskopieringen (till exempel användarskapande, lösenordsändringar eller gruppändringar). Därför är det vanligt att begränsa auktoritära återställningar till endast de absolut nödvändiga objekten eller träden.

SYSVOL-restaurering och återställning (FRS vs DFSR)

SYSVOL är en nyckelkomponent i domänkontrollanten: Den lagrar startskript, gruppolicyer, säkerhetsmallar och andra viktiga delade resurser.Fel i dina behörigheter, skadade filer eller replikeringsproblem kan göra grupprincipobjekt oanvändbara eller orsaka oregelbundet beteende hos klienter.

Beroende på Windows Server-versionen och migreringsstatusen kan SYSVOL replikeras av FRS (filreplikeringstjänst) poren DFSR (Distribuerad filsystemreplikering)Proceduren för en auktoritativ återställning av SYSVOL varierar beroende på vilken av de två som används.

För att avgöra detta kan du kontrollera nyckeln i registret. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrerar Sysvols\LocalStateOm den här undernyckeln finns och dess värde är 3 (BORTGÅTT) används DFSR. Om den inte finns eller om dess värde är annorlunda har vi att göra med en miljö som fortfarande använder FRS.

I miljöer med FRS innebär auktoritativ återställning av SYSVOL vanligtvis att värdet justeras Burflags en HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process till ett specifikt värde (t.ex. 212 decimaler / 0xD4 hex) för att indikera att denna DC är den auktoritativa källan.

Om SYSVOL replikeras av DFSR är processen något mer komplicerad: den involverar användning av ADSIEdit för att modifiera SYSVOL-prenumerationsobjekt (attribut msDFSR-aktiverad y msDFSR-alternativ) på den auktoritativa domänkontrollanten och på de andra, tvinga fram AD-replikering, kör dfsrdiag pollad och bekräfta i händelseloggen att händelserna 4114, 4602, 4614 och 4604 som intygar att SYSVOL har initialiserats och replikerats korrekt.

Återställa virtuella domänkontrollanter från VHD

I virtualiserade miljöer är det mycket vanligt att ha VHD/VHDX-filer för domänkontrollanterOm du inte har en säkerhetskopia av systemtillståndet men har en fungerande "gammal" virtuell hårddisk kan du montera en ny domänkontrollant från den disken, men du måste göra det mycket försiktigt för att undvika att orsaka en USN-återställning.

Rekommendationen är Starta inte den virtuella maskinen direkt i normalt lägeIstället bör du starta från den föregående virtuella hårddisken i DSRMÖppna Registereditorn och navigera till HKLM\SYSTEM\CurrentControlSet\Services\NTDS\ParametersDär är det lämpligt att kontrollera värdet Antal tidigare DSA-återställningar (om det finns) och framför allt skapa ett nytt DWORD-värde (32-bitars) som heter Databasen återställd från säkerhetskopia med värde 1.

Genom att välja detta värde får Active Directory veta att databasen har återställts från en säkerhetskopia, vilket tvingar generera ett nytt InvocationID vid uppstart i normalt lägePå så sätt tolkar de andra domänkontrollanterna det som en ny instans och justerar sina replikeringsvattenmärken korrekt, vilket förhindrar USN-återställning.

Efter att du har startat om DC i normalt läge är det lämpligt att kontrollera händelseloggen, särskilt loggen för Katalogtjänster, letar efter händelse 1109Den här händelsen bekräftar att serverns InvocationID-attribut har ändrats och visar de gamla och nya värdena, samt den högsta USN vid tidpunkten för säkerhetskopieringen. Dessutom värdet för Antal tidigare DSA-återställningar Den borde ha ökats med ett.

Om dessa händelser inte visas, eller om antalet inte ökar, bör du kontrollera operativsystemversionerna och Service Packs, eftersom Vissa återställningsbeteenden beror på specifika patcharI vilket fall som helst är det alltid lämpligt att arbeta med en kopia av den ursprungliga VHD:n och behålla en intakt version ifall processen behöver upprepas.

Praktiska scenarier och ytterligare rekommendationer

I praktiken uppstår ofta problem med korruption eller felaktiga restaureringar i vardagliga situationer: Manuella ändringar av behörigheter i SYSVOL, försök att uppdatera ADMX/ADML-mallar, GPO-ändringar som inte replikerasetc. Det är relativt lätt att orsaka inkonsekvenser om delade mappar ändras manuellt, till exempel SYSVOL\Policies utan att respektera replikering.

Vid en primär domänkontrollant med trasig replikering (både AD-data och SYSVOL) och övervakningsmeddelanden av typen "Databasen återställdes med en procedur som inte stöds. Möjlig orsak: Återställning av USN”, är det kloka att göra:

• Kontrollera med dcdiag y repadmin felens omfattning och huruvida det finns ”beständiga objekt”.
• Kontrollera händelse 2095 och värdet DSA inte skrivbar i registret.
• Bedöm om det är möjligt ta bort den där DC:n och bygg om den (Om det finns tre eller fler andra friska dendritiska celler är detta vanligtvis det bästa alternativet).
• Om det är den enda DC eller kritikern, ta upp en återställning av systemtillstånd från en kompatibel säkerhetskopia, helst aktuell och inom tombstone-perioden.

I domäner med flera kontrollanter rekommenderas det starkt att kontrollanterna är så "rena" som möjligt: utan ytterligare roller eller lokala användardataPå så sätt, om en misslyckas eller blir skadad, kan en ny formateras och promoveras baserat på en annan domänkontrollant eller via IFM, vilket avsevärt minskar komplexiteten i återställningen.

Dessutom är det värt att komma ihåg begränsningar som att Systemtillståndskopior är endast giltiga under tombstone-perioden (60, 90, 180 dagar beroende på konfigurationen) för att undvika att återuppliva raderade objekt, och att NTLM-maskinnycklar ändras var 7:e dag. I mycket gamla återställningar kan det vara nödvändigt att återställ teamkonton problem från "Active Directory-användare och datorer" eller till och med att ta bort dem och återansluta dem till domänen.

Ha rutiner på plats för regelbunden säkerhetskopiering av systemets tillstånd, Dokumentera tydligt FSMO-rollerna, den globala katalogen och replikeringstopologin.Och att testa återställningsstegen i en labbmiljö är tidsinvesteringar som sparar mycket huvudvärk när den dagen kommer då en domänkontrollant blir skadad eller någon använder en ögonblicksbild utan att tänka.