Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Den här artikeln beskriver arkitekturen för kloning och säker återställning av virtualiserade domänkontrollanter. Den visar processerna, kloning och säker återställning med flödesscheman och ger sedan en detaljerad förklaring av varje steg i processen.
Arkitektur för kloning av virtualiserade domänkontrollanter
Översikt
Kloning av virtualiserade domänkontrollanter förlitar sig på hypervisor-plattformen för att exponera en identifierare som kallasVM-Generation ID för att identifiera skapandet av en virtuell maskin. AD DS lagrar först värdet för den här identifieraren i sin databas (NTDS. DIT) under befordran av domänkontrollanter. När den virtuella datorn startas jämförs det aktuella värdet för VM-Generation-ID:t från den virtuella datorn med värdet i databasen. Om de två värdena skiljer sig åt återställer domänkontrollanten anrops-ID:t och tar bort RID-poolen, vilket förhindrar återanvändning av USN eller potentiellt skapande av dubbletter av säkerhetsobjekt. Domänkontrollanten söker sedan efter en DCCloneConfig.xml fil på de platser som beskrivs i steg 3 i Kloning av detaljerad bearbetning. Om den hittar en DCCloneConfig.xml fil drar den slutsatsen att den distribueras som en klon, så den initierar kloning för att etablera sig själv som ytterligare en domänkontrollant genom att befordra om med hjälp av den befintliga NTDS. DIT- och SYSVOL-innehåll som kopierats från källmediet.
I en blandad miljö där vissa hypervisor-program stöder VM-GenerationID och andra inte gör det, är det möjligt att ett klonmedia av misstag distribueras på ett hypervisor-program som inte stöder generations-ID för virtuella datorer. Förekomsten av DCCloneConfig.xml fil indikerar administrativ avsikt att klona en domänkontrollant. Om en DCCloneConfig.xml fil hittas under starten men ingen VM-GenerationID tillhandahålls från värden, startas därför klondomänkontrollanten i DSRM (Directory Services Restore Mode) för att förhindra att resten av miljön påverkas. Klonmediet kan därefter flyttas till en hypervisor som stöder VM-GenerationID och sedan kan kloning göras om.
Om klonmediet distribueras på ett hypervisor-program som stöder VM-GenerationID men en DCCloneConfig.xml fil inte tillhandahålls, eftersom domänkontrollanten upptäcker en VM-GenerationID ändring mellan dess DIT och den från den nya virtuella datorn, utlöser den skydd för att förhindra USN-återanvändning och undvika duplicerade SID:er. Kloning initieras dock inte, så den sekundära domänkontrollanten fortsätter att köras under samma identitet som källdomänkontrollanten. Den här sekundära domänkontrollanten bör tas bort från nätverket så snart som möjligt för att undvika inkonsekvenser i miljön.
Kloning Detaljerad bearbetning
Följande diagram visar arkitekturen för en inledande kloningsåtgärd och för ett kloningsförsök. Dessa processer förklaras mer detaljerat senare i det här avsnittet.
Inledande kloningsoperation
Kloning av nya försök
Följande steg förklarar processen mer detaljerat:
En befintlig domänkontrollant för virtuella datorer startar upp i en hypervisor som stöder VM-Generation ID.
Den här virtuella datorn har inget befintligt värde för Generation-ID för den virtuella datorn inställt på sitt AD DS-datorobjekt efter befordran.
Även om det är null innebär nästa datorskapande att den fortfarande klonas, eftersom en ny VM-Generation-ID inte matchar.
Den virtuella Generation-ID anges efter nästa omstart av domänkontrollanten och replikeras inte.
Den virtuella datorn läser sedan det VM-Generation-ID som tillhandahålls av VMGenerationCounter-drivrutinen. Den jämför de två VM-Generation-ID:na.
Om ID:t matchar är det här inte en ny virtuell dator och kloningen fortsätter inte. Om det finns en DCCloneConfig.xml fil byter domänkontrollanten namn på filen med en tid-datum-stämpel för att förhindra kloning. Servern fortsätter att starta normalt. Så här fungerar varje omstart av en virtuell domänkontrollant i Windows Server 2012.
Om de två ID:erna inte matchar är detta en ny virtuell dator som innehåller en NTDS. DIT från en tidigare domänkontrollant (eller så är det en återställd ögonblicksbild). Om det finns en DCCloneConfig.xml fil fortsätter domänkontrollanten med kloningsåtgärder. Annars fortsätter den med återställningsåtgärder för ögonblicksbilder. Se Arkitektur för säker återställning av virtualiserade domänkontrollanter.
Om hypervisorn inte tillhandahåller ett VM-Generation-ID för jämförelse, men det finns en DCCloneConfig.xml-fil, byter gästen namn på filen och startar sedan upp i DSRM för att skydda nätverket från en dubblett av domänkontrollanten. Om det inte finns någon dccloneconfig.xml fil startar gästen normalt (med risk för en dubblett av domänkontrollanten i nätverket).
NTDS-tjänsten kontrollerar värdet för VDCisCloning DWORD-registervärdenamnet (under HKEY_Local_Machine\System\CurrentControlSet\Services\Ntds\Parameters).
Om den inte finns är det här ett första försök till kloning för den här virtuella datorn. Gästen implementerar VDC-objektdupliceringsskydd för att ogiltigförklara den lokala RID-poolen och ange ett nytt replikeringsanrops-ID för domänkontrollanten
Om den redan är inställd på 0x1 är detta ett "återförsök"-kloningsförsök, där en tidigare kloningsåtgärd misslyckades. Säkerhetsåtgärderna för VDC-objektduplicering vidtas inte eftersom de redan måste ha körts en gång tidigare och skulle ändra gästen i onödan flera gånger.
Namnet på IsClone DWORD-registervärdet skrivs (under Hkey_Local_Machine\System\CurrentControlSet\Services\NTDS\Parameters)
NTDS-tjänsten ändrar gäststartflaggan så att den startar i DS-reparationsläge för eventuella ytterligare omstarter.
NTDS-tjänsten försöker läsa DcCloneConfig.xml på någon av de tre godkända platserna (DSA Working Directory, %windir%\NTDS eller flyttbara läs-/skrivmedier, i ordning efter enhetsbeteckning, i roten på enheten).
Om filen inte finns på någon giltig plats kontrollerar gästen IP-adressen för duplicering. Om IP-adressen inte dupliceras startar servern upp normalt. Om det finns en duplicerad IP-adress startar datorn i DSRM för att skydda nätverket från en duplicerad domänkontrollant.
Om filen finns på en giltig plats verifierar NTDS-tjänsten sina inställningar. Om filen är tom (eller om vissa inställningar är tomma) konfigurerar NTDS automatiska värden för dessa inställningar.
Om DcCloneConfig.xml finns men innehåller ogiltiga poster eller är oläslig, misslyckas kloningen och gästen startar i DSRM (Directory Services Restore Mode).
Gästen inaktiverar all automatisk DNS-registrering för att förhindra oavsiktlig kapning av källdatorns namn och IP-adresser.
Gästen stoppar Netlogon-tjänsten för att förhindra annonsering eller besvarande av AD DS-nätverksbegäranden från klienter.
NTDS verifierar att det inte finns några tjänster eller program installerade som inte ingår i DefaultDCCloneAllowList.xml eller CustomDCCloneAllowList.xml
Om det finns installerade tjänster eller program som inte finns i standardlistan över tillåtna undantag eller listan över tillåtna anpassade undantag misslyckas kloningen och gästen startar upp i DSRM för att skydda nätverket från en dubblett av domänkontrollanten.
Om det inte finns några inkompatibiliteter fortsätter kloningen.
Om automatisk IP-adressering kommer att användas på grund av tomma DCCloneConfig.xml nätverksinställningar, aktiverar gästen DHCP på nätverkskorten för att få ett IP-adresslån, nätverksroutning och namnmatchningsinformation.
Gästen hittar och kontaktar domänkontrollanten som kör FSMO-rollen för PDC-emulatorn. Detta använder DNS och DCLocator-protokollet. Den upprättar en RPC-anslutning och anropar metoden IDL_DRSAddCloneDC för att klona domänkontrollantens datorobjekt.
Om gästens källdatorobjekt har domänhuvudets utökade behörighet "Tillåt en domänkontrollant att skapa en klon av sig själv" fortsätter kloningen.
Om gästens källdatorobjekt inte har den utökade behörigheten misslyckas kloningen och gästen startar upp i DSRM för att skydda nätverket från en duplicerad domänkontrollant.
Namnet på AD DS-datorobjektet är inställt så att det matchar det namn som anges i DCCloneConfig.xml, om sådant finns, eller genereras automatiskt i PDCE. NTDS skapar rätt NTDS-inställningsobjekt för lämplig logisk Active Directory-plats.
Om det här är en PDC-kloning byter gästen namn på den lokala datorn och startar om. Efter omstart går den igenom steg 1 - 10 igen och går sedan till steg 13.
Om det här är en replika DC-kloning sker ingen omstart i det här skedet.
Gästen tillhandahåller kampanjinställningarna till DS-rollservertjänsten, som påbörjar kampanjen.
DS-rollservertjänsten stoppar alla AD DS-relaterade tjänster (NTDS, NTFRS/DFSR, KDC, DNS).
Gästen tvingar fram NT5DS-tidssynkronisering (Windows NTP) med en annan domänkontrollant (i en standardhierarki för Windows tidstjänst innebär detta att PDCE används). Gästen kontaktar PDCE. Alla befintliga Kerberos-biljetter rensas.
Gästen konfigurerar DFSR- eller NTFRS-tjänsterna så att de körs automatiskt. Gästen tar bort alla befintliga DFSR- och NTFRS-databasfiler (standard: c:\windows\ntfrs och c:\system volume information\dfsr\<database_GUID>) för att tvinga fram icke-auktoritativ synkronisering av SYSVOL när tjänsten startas nästa gång. Gästen tar inte bort filinnehållet i SYSVOL för att förinställa SYSVOL när synkroniseringen startar senare.
Gästen får ett nytt namn. DS-rollservertjänsten på gästen påbörjar AD DS-konfigurationen (befordran) med hjälp av den befintliga NTDS. DIT-databasfilen som källa, i stället för malldatabasen som ingår i c:\windows\system32 som en kampanj normalt gör.
Gästen kontaktar RID Master FSMO-rollinnehavaren för att få en ny RID-poolallokering.
Befordringsprocessen skapar ett nytt anrops-ID och återskapar NTDS-inställningsobjektet för den klonade domänkontrollanten (oavsett kloning är detta en del av domänbefordran när du använder en befintlig NTDS. DIT-databas).
NTDS replikeras i objekt som saknas, är nyare eller har en högre version från en partnerdomänkontrollant. The NTDS. DIT innehåller redan objekt från den tidpunkt då källdomänkontrollanten gick offline, och de används som möjligt för att minimera inkommande replikeringstrafik. De globala katalogpartitionerna fylls i.
DFSR- eller FRS-tjänsten startar och eftersom det inte finns någon databas synkroniserar SYSVOL inkommande trafik från en replikeringspartner på ett icke-auktoritativt sätt. Den här processen återanvänder befintliga data i SYSVOL-mappen för att minimera nätverksreplikeringstrafiken.
Gästen återaktiverar DNS-klientregistrering nu när datorn har ett unikt namn och nätverk.
Gästen kör de SYSPREP-moduler som anges av DefaultDCCloneAllowList.xml <SysprepInformation-elementet> för att rensa bort referenser till det tidigare datornamnet och SID.
Kloningskampanjen är klar.
Gästen tar bort DSRM-startflaggan så att nästa omstart blir normal.
Gästen byter namn på DCCloneConfig.xml med en tillagd datum- och tidsstämpel, så att den inte läses igen vid nästa start.
Gästen tar bort VDCIsCloning DWORD-registervärdenamnet under HKEY_Local_Machine\System\CurrentControlSet\Services\NTDS\Parameters.
Gästen anger DWORD-registervärdet "VdcCloningDone" under HKEY_Local_Machine\System\CurrentControlSet\Services\NTDS\Parameters till 0x1. Windows använder inte det här värdet, utan tillhandahåller det i stället som en markör för tredje part.
Gästen uppdaterar attributet msDS-GenerationID på sitt eget klonade domänkontrollantobjekt så att det matchar det aktuella gäst-VM-Generation-ID:t.
Gästen startar om. Nu är det en normal domänkontrollant för annonsering.
Arkitektur för säker återställning av virtualiserade domänkontrollanter
Översikt
AD DS förlitar sig på hypervisor-plattformen för att exponera en identifierare som kallasVM-Generation ID för att identifiera återställning av ögonblicksbilder av en virtuell dator. AD DS lagrar först värdet för den här identifieraren i sin databas (NTDS. DIT) under befordran av domänkontrollanter. När en administratör återställer den virtuella datorn från en tidigare ögonblicksbild jämförs det aktuella värdet för VM-Generation-ID:t från den virtuella datorn med värdet i databasen. Om de två värdena skiljer sig åt återställer domänkontrollanten anrops-ID:t och tar bort RID-poolen, vilket förhindrar återanvändning av USN eller potentiellt skapande av dubbletter av säkerhetsobjekt. Det finns två scenarier där säker återställning kan ske:
När en virtuell domänkontrollant startas efter att en ögonblicksbild har återställts medan den stängdes av
När en ögonblicksbild återställs på en virtuell domänkontrollant som körs
Om den virtualiserade domänkontrollanten i ögonblicksbilden är i ett pausat tillstånd i stället för att stängas av måste du starta om AD DS-tjänsten för att utlösa en ny begäran om RID-pool. Du kan starta om AD DS-tjänsten med hjälp av snapin-modulen Tjänster eller med hjälp av Windows PowerShell (Restart-Service NTDS -force).
I följande avsnitt beskrivs säker återställning i detalj för varje scenario.
Detaljerad bearbetning av säker återställning
Följande flödesschema visar hur säker återställning sker när en virtuell domänkontrollant startas efter att en ögonblicksbild har återställts medan den stängdes av.
När den virtuella datorn startar upp efter en återställning av ögonblicksbilder kommer den att ha ett nytt VM-Generation-ID som tillhandahålls av hypervisor-värden på grund av återställningen av ögonblicksbilden.
Det nya VM-Generation-ID:t från den virtuella datorn jämförs med det VM-Generation-ID:t i databasen. Eftersom de två ID:erna inte matchar används virtualiseringsskydd (se steg 3 i föregående avsnitt). När återställningen är klar uppdateras den VM-GenerationID som angetts på AD DS-datorobjektet så att det matchar det nya ID som tillhandahålls av hypervisor-värden.
Gästen använder virtualiseringsskydd genom att:
Ogiltigförklarar den lokala RID-poolen.
Ange ett nytt anrops-ID för domänkontrollantdatabasen.
Anmärkning
Den här delen av den säkra återställningen överlappar kloningsprocessen. Även om den här processen handlar om säker återställning av en virtuell domänkontrollant efter att den har startats upp efter en återställning av ögonblicksbilder, sker samma steg under kloningsprocessen.
Följande diagram visar hur virtualiseringsskydd förhindrar divergens som induceras av USN-återställning när en ögonblicksbild återställs på en virtuell domänkontrollant som körs.
Anmärkning
Föregående bild är förenklad för att förklara begreppen.
Vid tidpunkten T1 tar hypervisor-administratören en ögonblicksbild av den virtuella DC1. DC1 har för närvarande ett USN-värde (highestCommittedUsn i praktiken) på 100, InvocationId (representeras som ID i föregående diagram) på A (i praktiken skulle detta vara GUID). Värdet savedVMGID är det VM-GenerationID i DIT-filen för domänkontrollanten (lagrad mot domänkontrollantens datorobjekt i ett attribut med namnet msDS-GenerationId). VMGID är det aktuella värdet för den VM-GenerationId som är tillgänglig från drivrutinen för den virtuella datorn. Det här värdet anges av hypervisor-programmet.
Vid ett senare tillfälle T2 läggs 100 användare till i den här domänkontrollanten (betrakta användare som ett exempel på uppdateringar som kan ha utförts på den här domänkontrollanten mellan tiden T1 och T2; dessa uppdateringar kan faktiskt vara en blandning av användarskapanden, gruppskapanden, lösenordsuppdateringar, attributuppdateringar och så vidare). I det här exemplet förbrukar varje uppdatering ett unikt USN (även om en användarskapande i praktiken kan förbruka mer än ett USN). Innan du checkar in dessa uppdateringar kontrollerar DC1 om värdet för VM-GenerationID i databasen (savedVMGID) är detsamma som det aktuella värdet som är tillgängligt från drivrutinen (VMGID). De är desamma, eftersom ingen återställning har skett ännu, så uppdateringarna checkas in och USN flyttas upp till 200, vilket indikerar att nästa uppdatering kan använda USN 201. Det finns ingen ändring i InvocationId, savedVMGID eller VMGID. Dessa uppdateringar replikeras ut till DC2 vid nästa replikeringscykel. DC2 uppdaterar sitt högvattenmärke (och UptoDatenessVector) som representeras här helt enkelt som DC1(A) @USN = 200. Det innebär att DC2 är medveten om alla uppdateringar från DC1 i kontexten för InvocationId A till USN 200.
Vid tidpunkten T3 tillämpas ögonblicksbilden som togs vid tidpunkten T1 på DC1. DC1 har återställts, så dess USN återställs till 100, vilket indikerar att den kan använda USN från 101 för att associera med efterföljande uppdateringar. I det här läget skulle dock värdet för VMGID vara annorlunda på hypervisorer som stöder generations-ID för virtuella datorer.
Därefter, när DC1 utför en uppdatering, kontrollerar den om värdet för VM-GenerationId som den har i sin databas (savedVMGID) är detsamma som värdet från den virtuella maskindrivrutinen (VMGID). I det här fallet är det inte samma sak, så DC1 härleder detta som en indikation på en återställning, och det utlöser virtualiseringsskydd. Med andra ord återställer den sitt InvocationId (ID = B) och tar bort RID-poolen (visas inte i föregående diagram). Den sparar sedan det nya värdet för VMGID i databasen och checkar in dessa uppdateringar (USN 101–250) i kontexten för det nya InvocationId B. Vid nästa replikeringscykel vet DC2 ingenting från DC1 i kontexten för InvocationId B, så den begär allt från DC1 som är associerat med InvocationID B. Det innebär att de uppdateringar som utförs på DC1 efter tillämpningen av ögonblicksbilden konvergerar på ett säkert sätt. Dessutom skulle den uppsättning uppdateringar som utfördes på DC1 vid T2 (som förlorades på DC1 efter återställningen av ögonblicksbilden) replikeras tillbaka till DC1 vid nästa schemalagda replikering eftersom de hade replikerats ut till DC2 (vilket anges av den streckade linjen tillbaka till DC1).
När gästen använder virtualiseringsskydd replikerar NTDS Active Directory-objektskillnader inkommande icke-auktoritativt från en partnerdomänkontrollant. Vektorn up-to-dateness för målkatalogtjänsten uppdateras i enlighet med detta. Sedan synkroniserar gästen SYSVOL:
Om du använder FRS stoppar gästen NTFRS-tjänsten och anger D2 BURFLAGS-registervärdet. Sedan startar den NTFRS-tjänsten, som icke-auktoritativt replikerar inkommande trafik och återanvänder befintliga oförändrade SYSVOL-data när det är möjligt.
Om du använder DFSR stoppar gästen DFSR-tjänsten och tar bort DFSR-databasfilerna (standardplatsen: %systemroot%\system volume information\dfsr\<database GUID).> Sedan startar den DFSR-tjänsten, som replikerar inkommande trafik utan auktoritet och återanvänder befintliga oförändrade SYSVOL-data när det är möjligt.
Anmärkning
- Om hypervisor-programmet inte tillhandahåller ett VM-Generation-ID för jämförelse stöder hypervisor-programmet inte virtualiseringsskydd och gästen fungerar som en virtualiserad domänkontrollant som kör Windows Server 2008 R2 eller tidigare. Gästen implementerar karantänskydd för USN-återställning om det görs ett försök att börja replikera med USN:er som inte har avancerat förbi det senaste högsta USN som setts av partnerdomänkontrollanten. Mer information om karantänskydd för USN-återställning finns i USN och USN-återställning