DSRM (Directory Services Restore Mode): a Windows Server helyreállítási módjának magyarázata

A modern informatikai infrastruktúrák gerincét gyakran az Active Directory (AD) szolgáltatás képezi, különösen a Windows Server környezetekben. Ez a központi címtárszolgáltatás felelős a felhasználók, számítógépek, csoportok és egyéb hálózati erőforrások kezeléséért, hitelesítéséért és jogosultságkezeléséért. Amikor az Active Directoryval kapcsolatos problémák merülnek fel – legyen szó adatbázis-sérülésről, véletlen törlésről, vagy súlyos rendszerhibáról –, a helyreállítás kulcsfontosságúvá válik a működés folytonosságának biztosításához. Ebben a kritikus helyzetben lép színre a DSRM, azaz a Directory Services Restore Mode (Címtárszolgáltatások Helyreállítási Módja).

A DSRM egy speciális indítási mód a Windows Server operációs rendszerekben, amely lehetővé teszi a domain kontrollerek (DC-k) indítását az Active Directory szolgáltatások betöltése nélkül. Ez alapvető fontosságú, mivel ha az AD maga hibás, vagy sérült, a normál indítási mód egyszerűen nem működne, vagy tovább rontaná a helyzetet. A DSRM hozzáférést biztosít a rendszergazdáknak a domain kontroller alapvető fájljaihoz és szolgáltatásaihoz, így lehetővé téve a hibás Active Directory adatbázis (NTDS.DIT) helyreállítását, a jelszavak visszaállítását, vagy egyéb kritikus karbantartási feladatok elvégzését. Nem csupán egy puszta „csökkentett mód”, hanem egy kifejezetten az Active Directory helyreállítására és karbantartására tervezett környezet, amely elengedhetetlen eszköz minden rendszergazda eszköztárában, aki Windows alapú hálózatokkal dolgozik.

Ez a cikk részletesen bemutatja a DSRM működését, céljait, használati eseteit, és a hozzá kapcsolódó legjobb gyakorlatokat. Kitérünk arra, hogyan lehet belépni DSRM módba különböző Windows Server verziókon, hogyan kell kezelni a DSRM jelszót, és milyen helyreállítási stratégiák alkalmazhatók ezen a speciális környezeten keresztül. Célunk, hogy átfogó és gyakorlatias tudást nyújtsunk a DSRM-ről, segítve a rendszergazdákat a hatékonyabb hibaelhárításban és a katasztrófa-helyreállítási tervek kidolgozásában.

A DSRM alapvető célja és működési elve

A Directory Services Restore Mode (DSRM) lényegét tekintve egy biztonságos indítási mód, amely kizárólag a domain kontrollereken érhető el. Fő célja, hogy lehetővé tegye az Active Directory adatbázisának (NTDS.DIT fájl) és a kapcsolódó rendszerelemek (például a SYSVOL megosztás) offline, nem-produkciós környezetben történő kezelését és helyreállítását. Normál üzemmódban az Active Directory szolgáltatások futnak, és folyamatosan zárolva tartják az NTDS.DIT fájlt, megakadályozva ezzel a közvetlen hozzáférést és módosítást, ami a DSRM-et elengedhetetlenné teszi a mélyebb beavatkozásokhoz.

Amikor egy domain kontroller DSRM módban indul, az Active Directory szolgáltatások nem töltődnek be. Ehelyett a rendszer a helyi SAM (Security Account Manager) adatbázisát használja a hitelesítéshez, ami azt jelenti, hogy a DSRM-be való belépéshez szükséges jelszó nem az Active Directoryban tárolódik, hanem a domain kontroller helyi SAM adatbázisában. Ez a függetlenség kritikus, hiszen ha az Active Directory sérült, a normál AD-hitelesítés nem működne. A DSRM módban a rendszergazda hozzáférhet a fájlrendszerhez, a beállításjegyzékhez, és futtathat parancssori eszközöket, mint például az NTDSUTIL, amelyekkel az Active Directory adatbázisát manipulálni, ellenőrizni vagy helyreállítani lehet.

A DSRM nem csupán egy „csökkentett mód”; egy speciális, dedikált környezet az Active Directory kritikus helyreállítási és karbantartási feladataihoz.

Fontos megérteni, hogy a DSRM-et nem arra tervezték, hogy a napi rendszergazdai feladatokat végezzék benne. Kizárólag vészhelyzetekre, vagy tervezett, mélyebb karbantartási műveletekre szolgál, amikor az Active Directory integritása veszélybe kerül, vagy helyreállítást igényel. Mivel a domain kontroller DSRM módban nem tudja kiszolgálni a hálózati kéréseket Active Directory szolgáltatásként, a hálózat többi része nem fog tudni hitelesítést végezni, vagy erőforrásokat keresni ezen a DC-n keresztül.

Miért van szükség DSRM-re?

Az Active Directory rendkívül komplex és kritikus fontosságú szolgáltatás, amely számos függőséggel rendelkezik. Egy hiba a címtárszolgáltatásban láncreakciót indíthat el, ami a teljes hálózati működést megbéníthatja. A DSRM több okból is nélkülözhetetlen:

• Sérült Active Directory adatbázis (NTDS.DIT): Az adatbázis sérülése esetén a DC nem tud normálisan elindulni, vagy hibásan működik. A DSRM lehetővé teszi a sérült adatbázis offline javítását vagy egy korábbi, működőképes állapotból történő visszaállítását.
• Véletlen törlések: Ha egy kritikus Active Directory objektumot (pl. egy teljes OU-t, felhasználói fiókot vagy csoportot) véletlenül törölnek, a DSRM módban végrehajtott autoritatív visszaállítással az objektum visszaállítható anélkül, hogy a replikáció során a törlési művelet terjedne a többi DC-re.
• Elfelejtett rendszergazdai jelszavak: Ha az Active Directory tartományi rendszergazdai jelszava elveszik vagy elfelejtődik, a DSRM módban a helyi DSRM jelszóval belépve a tartományi rendszergazdai jelszó visszaállítható.
• NTDS.DIT tömörítése és karbantartása: Bár ritkábban, de előfordulhat, hogy az NTDS.DIT fájl mérete indokolatlanul megnő. A DSRM módban az NTDSUTIL eszközzel offline tömörítést végezhetünk, amely csökkentheti az adatbázis fizikai méretét.
• Metadatok eltávolítása: Ha egy domain controllert nem megfelelően távolítottak el a tartományból, a DSRM módban futtatható NTDSUTIL segítségével eltávolíthatók a DC-vel kapcsolatos metadatok az Active Directoryból, megakadályozva ezzel a replikációs hibákat.

A DSRM tehát nem egy mindennapi eszköz, hanem egy utolsó mentsvár, egy „sebészi” beavatkozási lehetőség, amely lehetővé teszi a domain kontrollerek újraélesztését és az Active Directory integritásának helyreállítását súlyos problémák esetén.

A DSRM jelszó: jelentősége és kezelése

A DSRM jelszó az egyik legkritikusabb elem a Directory Services Restore Mode használatakor. Ahogy korábban említettük, ez a jelszó nem az Active Directoryban tárolódik, hanem a domain kontroller helyi SAM (Security Account Manager) adatbázisában. Ez a különállás biztosítja, hogy akkor is be tudjunk lépni DSRM-be, ha az Active Directory adatbázisa sérült vagy nem elérhető.

A DSRM jelszó beállítása és alaphelyzetbe állítása

A DSRM jelszót a domain kontroller előléptetésekor kell beállítani. A Windows Server telepítő varázslója (DCpromo vagy Server Manageren keresztül az „Add Roles and Features” varázsló) rákérdez erre a jelszóra, amikor egy szervert domain controllerré léptetünk elő. Fontos, hogy ezt a jelszót gondosan válasszuk meg, és biztonságosan tároljuk, mivel ez az egyetlen kulcs, amellyel hozzáférhetünk a DC belső működéséhez, ha az Active Directory leáll.

Ha a DSRM jelszót elfelejtettük, vagy biztonsági okokból meg szeretnénk változtatni, azt többféleképpen is megtehetjük, még akkor is, ha a domain kontroller normál üzemmódban fut:

1. Az NTDSUTIL használata

Az NTDSUTIL egy parancssori eszköz, amely számos Active Directoryval kapcsolatos feladat elvégzésére alkalmas, beleértve a DSRM jelszó kezelését is. Ez a leggyakrabban használt és legmegbízhatóbb módszer.

1. Nyissunk egy emelt szintű parancssort (Run as administrator) a domain kontrolleren.
2. Írjuk be: ntdsutil és nyomjuk meg az Entert.
3. Az ntdsutil: promptnál írjuk be: set dsrm password és nyomjuk meg az Entert.
4. A dsrm password: promptnál írjuk be: reset password on server null (vagy a szerver nevét, ha távolról végezzük, de helyben a null is működik).
5. Ekkor a rendszer kétszer is bekéri az új DSRM jelszót. Győződjünk meg róla, hogy erős, komplex jelszót választunk, amely tartalmaz nagy- és kisbetűket, számokat és speciális karaktereket.
6. Miután beállítottuk a jelszót, írjuk be: q (quit) mindkét promptnál, hogy kilépjünk az NTDSUTIL-ból.

Ez a módszer azonnal frissíti a DSRM jelszót a helyi SAM adatbázisban.

2. A `dsrmadmainpassword` parancs (Windows Server 2008 R2 és újabb)

A Windows Server 2008 R2 és újabb verziókban bevezettek egy egyszerűbb parancsot a DSRM jelszó visszaállítására, ami valójában az NTDSUTIL-t hívja meg a háttérben. Ez a parancs a dsrmadmainpassword (tévesen gyakran írják dsrmadminpassword-nak, de a helyes a dsrmadmainpassword).

1. Nyissunk egy emelt szintű parancssort.
2. Írjuk be: dsrmadmainpassword és nyomjuk meg az Entert.
3. A rendszer ekkor azonnal bekéri az új jelszót kétszer.

Ez a parancs egyszerűbb, de a funkciója megegyezik az NTDSUTIL-on keresztül végzett jelszóállítással.

A DSRM jelszó biztonsága és legjobb gyakorlatai

Mivel a DSRM jelszó kulcsfontosságú a domain kontroller helyreállításához, annak biztonsága kiemelt prioritást élvez. Íme néhány legjobb gyakorlat:

• Komplex jelszó: Használjunk erős, komplex jelszót, amely megfelel a szervezet jelszó-politikájának, és tartalmaz nagybetűket, kisbetűket, számokat és speciális karaktereket.
• Biztonságos tárolás: Ne tároljuk a DSRM jelszót egyszerű szöveges fájlban a szerveren vagy könnyen hozzáférhető helyen. Használjunk jelszókezelő szoftvert (pl. LastPass Enterprise, KeePass) vagy tároljuk titkosított formában, biztonságos, hozzáférés-korlátozott helyen.
• Rendszeres változtatás: Bár a DSRM jelszó nem jár le automatikusan, érdemes rendszeresen, például évente egyszer megváltoztatni biztonsági okokból.
• Dokumentáció: A DSRM jelszót és a hozzá tartozó eljárásokat dokumentálni kell a katasztrófa-helyreállítási terv részeként. Győződjünk meg róla, hogy több, megbízható személy is hozzáférhet a jelszóhoz vészhelyzet esetén.
• Ne használjuk a tartományi admin jelszavát: Soha ne állítsuk be a DSRM jelszót ugyanarra, mint a tartományi rendszergazdai jelszó. Ez egy alapvető biztonsági hiba, mivel ha a tartományi admin jelszó kompromittálódik, a DSRM is azonnal veszélybe kerül.

A DSRM jelszó elengedhetetlen a domain controllerek helyreállításához. Annak gondos kezelése és biztonságos tárolása alapvető feltétele a hatékony katasztrófa-helyreállításnak és a hálózati biztonság fenntartásának.

Belépés DSRM módba: lépésről lépésre

A DSRM módba való belépés módja némileg eltérhet a Windows Server verzióktól és a szerver állapotától függően. Fontos, hogy tisztában legyünk a különböző megközelítésekkel, hogy vészhelyzet esetén gyorsan és hatékonyan tudjunk cselekedni.

1. Domain kontroller újraindítása és a boot menü használata (Windows Server 2008/2008 R2)

Ez a klasszikus módszer a régebbi Windows Server verziókban a leggyakoribb. Amikor a domain kontroller elindul, a boot folyamat során meg kell nyomni egy bizonyos billentyűt a speciális indítási opciók eléréséhez.

1. Indítsa újra a domain controllert.
2. A boot folyamat során nyomja meg az F8 billentyűt többször. Ezt általában a Windows logó megjelenése előtt kell megtenni. Ha túl későn nyomja meg, a Windows normálisan elindul, és újra kell indítania.
3. Megjelenik az Advanced Boot Options menü.
4. A nyílbillentyűkkel válassza ki a „Directory Services Restore Mode” opciót, majd nyomja meg az Entert.
5. A rendszer ezután megpróbál DSRM módban elindulni. Amikor a bejelentkezési képernyő megjelenik, a felhasználónév általában Administrator lesz (vagy a DSRM felhasználónév, ha azt módosították), és a jelszó a korábban beállított DSRM jelszó.

2. Rendszerindítási beállítások módosítása (Windows Server 2012 és újabb)

A Windows Server 2012-től kezdődően az F8 billentyűs módszer már nem mindig működik, vagy sokkal gyorsabban kell reagálni. Az újabb rendszerek a gyors rendszerindítás (Fast Startup) miatt gyakran kihagyják az F8 ablakot. Ebben az esetben a rendszerindítási beállításokat kell módosítani a Windows helyreállítási környezetén (WinRE) vagy az MSCONFIG segítségével.

A. Rendszerindítás a helyreállítási környezetből (WinRE)

Ez a módszer akkor hasznos, ha a szerver nem tud normálisan elindulni, vagy ha a rendszergazda nincs fizikailag a gépnél, de van hozzáférése a konzolhoz (pl. virtuális gép konzolja).

1. Indítsa újra a szervert. Ha a szerver nem indul el normálisan, a Windows automatikusan beléphet a helyreállítási környezetbe. Ha normálisan indulna, de DSRM-be akarunk lépni:
   • Nyomja meg a Win + I billentyűkombinációt a Beállítások megnyitásához.
   • Navigáljon a Frissítés és biztonság > Helyreállítás menüponthoz.
   • A „Speciális indítás” részben kattintson az „Újraindítás most” gombra.
2. A helyreállítási környezetben válassza a „Hibaelhárítás” (Troubleshoot) opciót.
3. Ezután válassza a „Speciális beállítások” (Advanced options) lehetőséget.
4. Válassza a „Indítási beállítások” (Startup Settings) opciót.
5. Kattintson az „Újraindítás” (Restart) gombra.
6. Az újraindítás után megjelenik egy menü a különböző indítási beállításokkal. Keresse meg a „Directory Services Restore Mode” (vagy valami hasonló) opciót, és nyomja meg a hozzá tartozó számot (általában 4 vagy 5).
7. A szerver DSRM módban indul el. Jelentkezzen be a DSRM felhasználóval és jelszóval.

B. Az MSCONFIG használata (a Windows rendszeren belülről)

Ha a domain kontroller még működőképes, de DSRM módban szeretnénk újraindítani egy tervezett karbantartás céljából, az MSCONFIG (System Configuration) eszköz kényelmes megoldást nyújt.

1. Nyomja meg a Win + R billentyűkombinációt, írja be: msconfig és nyomja meg az Entert.
2. A Rendszerkonfiguráció ablakban válassza az „Indítás” (Boot) fület.
3. A „Rendszerindítási beállítások” (Boot options) alatt pipálja be a „Biztonságos rendszerindítás” (Safe boot) jelölőnégyzetet.
4. Válassza ki az „Active Directory javítás” (Active Directory repair) rádiógombot (ez felel meg a DSRM-nek).
5. Kattintson az „Alkalmaz” (Apply) majd az „OK” gombra.
6. A rendszer felajánlja az újraindítást. Válassza az „Újraindítás” (Restart) lehetőséget.
7. A szerver DSRM módban indul el. Jelentkezzen be a DSRM felhasználóval és jelszóval.

Fontos megjegyzés: Ne felejtse el kikapcsolni a „Biztonságos rendszerindítás” opciót az MSCONFIG-ban, miután befejezte a DSRM munkát, különben a szerver minden újraindításkor DSRM módban fog elindulni!

3. Távoli hozzáférés és virtuális gépek

Virtuális gépek esetén (pl. Hyper-V, VMware) a konzolhoz való hozzáférés kulcsfontosságú. A távoli asztal (RDP) nem használható DSRM módban történő bejelentkezéshez, mivel az Active Directory szolgáltatások nem futnak, és az RDP hitelesítés az AD-n keresztül történik. Mindig a hipervizor menedzsment konzolját (pl. Hyper-V Manager, vSphere Client) kell használni a virtuális gép konzoljának eléréséhez.

A DSRM módba való belépés sikere nagyban függ a megfelelő jelszó ismeretétől és a fenti lépések pontos betartásától. Mindig győződjünk meg arról, hogy a DSRM jelszó naprakész és hozzáférhető, mielőtt bármilyen helyreállítási műveletbe kezdenénk.

Helyreállítási stratégiák DSRM módban: autoritatív és nem-autoritatív visszaállítás

Amikor egy domain controller DSRM módban van, két fő típusú Active Directory helyreállítást végezhetünk: a nem-autoritatív visszaállítást és az autoritatív visszaállítást. A kettő közötti különbség alapvető fontosságú, és a választás a probléma jellegétől függ.

1. Nem-autoritatív visszaállítás (Non-Authoritative Restore)

A nem-autoritatív visszaállítás a leggyakoribb és legegyszerűbb helyreállítási módszer. Ennek során a sérült domain controllert egy korábbi, működőképes állapotba állítjuk vissza egy rendszerállapot-mentésből. Miután a DC újra online állapotba kerül, azonnal megkezdi a replikációt a többi, még működőképes domain kontrollerrel, és átveszi tőlük a legfrissebb Active Directory adatokat. Ez azt jelenti, hogy a visszaállított DC Active Directory adatbázisa „elavultnak” minősül, és a replikáció során felülíródik a hálózatban lévő többi DC frissebb adataival.

Mikor használjuk?

• Ha egy domain controller hardverhiba vagy szoftveres korrupció miatt nem indul el, de a többi DC a hálózatban rendben működik és tartalmazza a legfrissebb AD adatokat.
• Ha a cél egy új DC gyors beüzemelése egy korábbi biztonsági mentésből, anélkül, hogy a teljes Active Directory visszaállításra kerülne.
• Ez a módszer alkalmas egyetlen DC visszaállítására, ha az AD adatbázisa sérült, de a hálózat egésze még ép.

Folyamat (röviden):

1. Indítsa el a domain controllert DSRM módban.
2. Végezze el a rendszerállapot-helyreállítást egy korábbi biztonsági mentésből. Ez általában a Windows Server Backup (WSB) vagy egy harmadik féltől származó biztonsági mentési szoftver segítségével történik. A WSB esetén a wbadmin parancsot használhatjuk a parancssorból.
3. Miután a visszaállítás befejeződött, indítsa újra a DC-t normál üzemmódban.
4. A DC elindulásakor automatikusan megkezdi a bejövő replikációt a többi domain kontrollerrel, és szinkronizálja az Active Directory adatbázisát a legfrissebb állapotra.

A nem-autoritatív visszaállítás viszonylag egyszerű és kockázatmentes, feltéve, hogy a hálózatban vannak más, megbízható domain kontrollerek, amelyekről a friss adatok replikálhatók.

A nem-autoritatív visszaállítás egy „önjavító” folyamat a DC számára, amely a replikáció során a többi DC-től veszi át a friss adatokat.

2. Autoritatív visszaállítás (Authoritative Restore)

Az autoritatív visszaállítás egy sokkal drasztikusabb és ritkábban alkalmazott helyreállítási módszer. Akkor használjuk, ha egy vagy több Active Directory objektumot (felhasználó, csoport, OU, stb.) véletlenül töröltek, vagy ha az Active Directory teljes adatbázisa valamilyen okból kompromittálódott, és azt egy korábbi időpontra kell visszaállítani anélkül, hogy a replikáció során a törölt vagy hibás adatok terjednének a hálózaton. Ebben az esetben a visszaállított adatok „autoritatívvá” válnak, ami azt jelenti, hogy a többi domain controller is felülírja a saját, esetleg elavultabb adatait a visszaállított DC-ről replikált információkkal.

Mikor használjuk?

• Véletlen törlés: Ha egy kritikus Active Directory objektumot vagy egy teljes szervezeti egységet (OU) véletlenül töröltek, és azt vissza kell állítani anélkül, hogy a törlés replikálódna a hálózatban.
• Logikai sérülés: Ha az Active Directory adatbázisa logikailag sérült (pl. hibás attribútumértékek, inkonzisztens adatok), és egy korábbi, ismert jó állapotba kell visszaállítani a teljes címtárat.
• Tombstone Lifetime (TSL) probléma: Ha egy DC offline volt hosszabb ideig, mint a TSL, és visszakerül a hálózatba, az inkonzisztenciákat okozhat. Az autoritatív visszaállítás segíthet ezen problémák kezelésében.

Folyamat:

Az autoritatív visszaállítás két fő lépésből áll:

1. Nem-autoritatív visszaállítás: Először is, a sérült domain controllert (vagy a legutóbbi, ismert jó állapotú biztonsági mentésből visszaállított DC-t) DSRM módban indítjuk el, és végrehajtunk egy nem-autoritatív rendszerállapot-helyreállítást. Ezen a ponton a DC AD adatbázisa még nem autoritatív.
2. Autoritatívvá tétel az NTDSUTIL segítségével: Miután a nem-autoritatív visszaállítás befejeződött, és a DC továbbra is DSRM módban van, az NTDSUTIL parancssori eszközt használjuk az objektumok vagy az egész adatbázis autoritatívvá tételéhez.

Autoritatív visszaállítás az NTDSUTIL segítségével (DSRM módban):

1. Indítsa el a domain controllert DSRM módban.
2. Nyisson egy emelt szintű parancssort.
3. Írja be: ntdsutil és nyomja meg az Entert.
4. Az ntdsutil: promptnál írja be: activate instance ntds és nyomja meg az Entert.
5. Ezután írja be: authoritative restore és nyomja meg az Entert.
6. Az authoritative restore: promptnál a következő parancsokat használhatja a visszaállítás scope-jának meghatározására:
   • Egyedi objektum visszaállítása:
     restore object "CN=Felhasználó Név,OU=Felhasználók,DC=domain,DC=com"
     (Cserélje ki a DN-t a visszaállítani kívánt objektum teljes megkülönböztető nevére.)
   • Teljes szervezeti egység (OU) visszaállítása:
     restore subtree "OU=Eladások,DC=domain,DC=com"
     (Ez visszaállítja az OU-t és az összes benne lévő objektumot.)
   • Teljes Active Directory visszaállítása (csak akkor, ha ez az egyetlen DC, vagy ha az egész erdőt vissza kell állítani):
     restore database
     (Ez ritkán használt, és csak akkor, ha az egész erdő sérült, és ez az egyetlen módja a helyreállításnak.)
7. Miután kiadta a megfelelő restore parancsot, az NTDSUTIL megerősítést kér. Erősítse meg a műveletet. Az NTDSUTIL növeli a visszaállított objektumok verziószámát (Update Sequence Number – USN), így azok magasabb USN-nel rendelkeznek, mint a hálózatban lévő többi DC-n lévő törölt vagy elavult verziók.
8. Miután a visszaállítás befejeződött, írja be: q (quit) mindkét promptnál, hogy kilépjen az NTDSUTIL-ból.
9. Indítsa újra a DC-t normál üzemmódban.

Amikor a DC újra elindul normál üzemmódban, a magasabb USN-ek miatt a visszaállított objektumok replikálódnak a többi domain kontrollerre, felülírva a törölt vagy elavult verziókat. Ez egy erőteljes, de potenciálisan veszélyes művelet, amelyet csak akkor szabad végrehajtani, ha pontosan tudjuk, mit csinálunk, és ha a probléma jellege megköveteli az autoritatív visszaállítást.

Az autoritatív visszaállítás előtt mindig gondoskodjunk arról, hogy a legfrissebb és legmegfelelőbb biztonsági mentés álljon rendelkezésre, és legyünk tisztában a visszaállítás potenciális hatásaival a teljes Active Directory környezetre.

Az NTDSUTIL szerepe és használata DSRM módban

Az NTDSUTIL egy rendkívül sokoldalú és erőteljes parancssori segédprogram, amely elengedhetetlen az Active Directory adatbázisának kezeléséhez és karbantartásához. Bár néhány funkciója normál üzemmódban is elérhető, a legkritikusabb és legmélyebb beavatkozások, különösen a helyreállítási műveletek, kizárólag DSRM módban végezhetők el vele.

Az NTDSUTIL főbb funkciói DSRM módban

Az NTDSUTIL számos almodult és parancsot tartalmaz, amelyekkel különféle feladatokat végezhetünk. DSRM módban az alábbi funkciók a leggyakrabban használtak:

1. Autoritatív visszaállítás (Authoritative Restore)

Ez az egyik legfontosabb funkció, ahogy azt a fenti szakaszban részletesen tárgyaltuk. Lehetővé teszi egy vagy több Active Directory objektum, vagy akár a teljes adatbázis autoritatív visszaállítását egy korábbi biztonsági mentésből. Ennek során az NTDSUTIL megnöveli a visszaállított objektumok verziószámát (USN), biztosítva, hogy azok felülírják az elavultabb verziókat a replikáció során. A parancsok, mint restore object, restore subtree, és restore database, mind az authoritative restore almodulon belül érhetők el.

2. Metadatok eltávolítása (Metadata Cleanup)

Ha egy domain controllert nem megfelelően távolítottak el a tartományból (pl. hardverhiba, váratlan leállás miatt), a metadatok (azaz a DC-vel kapcsolatos bejegyzések) továbbra is ott maradhatnak az Active Directoryban. Ez replikációs hibákat és egyéb problémákat okozhat. Az NTDSUTIL metadata cleanup almodulja lehetővé teszi ezeknek a „szellemkép” DC-knek a manuális eltávolítását az Active Directoryból.

1. Nyisson egy emelt szintű parancssort DSRM módban.
2. Írja be: ntdsutil.
3. ntdsutil: metadata cleanup
4. metadata cleanup: connections
5. connections: connect to server localhost (vagy egy másik élő DC, ha azt használjuk a tisztításhoz)
6. connections: quit
7. metadata cleanup: select operation target
8. select operation target: list domains (válassza ki a tartományt, amelyből a DC-t eltávolítjuk)
9. select operation target: select domain
10. select operation target: list sites (válassza ki a helyet)
11. select operation target: select site
12. select operation target: list servers in site (válassza ki a törlendő szervert)
13. select operation target: select server
14. select operation target: quit
15. metadata cleanup: remove selected server
16. Erősítse meg a törlést.
17. Lépjen ki az NTDSUTIL-ból.

Ez a folyamat kritikus a tartomány integritásának fenntartásához, és gyakran használják katasztrófa-helyreállítási forgatókönyvekben.

3. Fájlok (Files)

Az NTDSUTIL files almodulja lehetővé teszi az Active Directory adatbázisának (NTDS.DIT) és a kapcsolódó naplófájlok (log files) offline karbantartását. DSRM módban a következő funkciókat használhatjuk:

• compact to : Az NTDS.DIT adatbázis offline tömörítése. Ez segít csökkenteni az adatbázis fizikai méretét, miután sok objektumot töröltek belőle. Fontos, hogy a tömörítés után az új, tömörített adatbázist manuálisan át kell másolni az eredeti helyére (általában %SystemRoot%\NTDS).
• integrity: Ellenőrzi az NTDS.DIT adatbázis integritását és konzisztenciáját.
• recover: Megpróbálja helyreállítani az adatbázist a naplófájlok segítségével.

4. Szerepkörök (Roles – FSMO Roles)

Bár nem közvetlenül DSRM módban történik a szerepkörök áthelyezése, az NTDSUTIL roles almodulja kulcsfontosságú az FSMO (Flexible Single Master Operations) szerepkörök kezeléséhez, különösen vészhelyzetben. Ha egy FSMO szerepkör birtokosa véglegesen meghibásodott, az NTDSUTIL seize parancsával „elragadhatjuk” a szerepkört egy másik működő DC-re. Ezt általában normál üzemmódban végezzük egy működő DC-n, de a DSRM-mel való kapcsolat abban rejlik, hogy ha a korábbi FSMO tulajdonos nem indul el, a DSRM használható a hibás DC további vizsgálatára, mielőtt véglegesen elragadjuk a szerepkört.

Az NTDSUTIL használatának általános elvei

• Emelt szintű parancssor: Mindig emelt szintű parancssorból (Run as administrator) kell futtatni az NTDSUTIL-t, még DSRM módban is.
• Ismerje a parancsokat: Mielőtt bármilyen műveletet végezne az NTDSUTIL-lal, alaposan ismerje meg a használni kívánt parancsokat és azok hatásait. Egy rosszul kiadott parancs súlyos károkat okozhat az Active Directoryban.
• Dokumentáció és tesztelés: Minden NTDSUTIL alapú helyreállítási vagy karbantartási eljárást dokumentálni kell, és rendszeresen tesztelni kell egy nem-produkciós környezetben.
• „activate instance ntds”: Szinte minden NTDSUTIL művelet előtt, amely az Active Directory adatbázist érinti, aktiválni kell az NTDS instance-t a activate instance ntds paranccsal.

Az NTDSUTIL egy rendkívül hatékony, de egyben veszélyes eszköz a tapasztalatlan kezekben. Csak alapos megértés és előzetes tervezés után használjuk, különösen éles környezetben.

Rendszerállapot-mentés és helyreállítás: a DSRM kulcsfontosságú partnere

A rendszerállapot-mentés (System State Backup) és a DSRM elválaszthatatlanul összefüggenek az Active Directory helyreállítási stratégiájában. A DSRM biztosítja a környezetet, amelyben a helyreállítás végrehajtható, míg a rendszerállapot-mentés maga az a „mentőöv”, amely tartalmazza a DC működéséhez szükséges összes kritikus adatot.

Mi az a rendszerállapot-mentés?

A rendszerállapot-mentés nem egy teljes rendszermentés, hanem a Windows Server azon komponenseinek mentését foglalja magában, amelyek kritikusak a rendszer működéséhez és az Active Directory integritásához. Egy domain controller esetében a rendszerállapot-mentés a következőket tartalmazza:

• Active Directory adatbázis (NTDS.DIT): Az AD összes objektumát (felhasználók, csoportok, számítógépek stb.) tartalmazza.
• SYSVOL könyvtár: Tartalmazza a tartományi házirendeket (Group Policy Objects – GPO) és a bejelentkezési szkripteket. Ez a könyvtár replikálódik a DC-k között.
• Rendszerindító fájlok: A Windows indításához szükséges fájlok.
• COM+ Class Registration Database: Adatbázis a COM+ alkalmazásokhoz.
• Beállításjegyzék (Registry): A rendszer és az alkalmazások beállításai.
• Performance Counter Configuration Information: Teljesítményszámlálók konfigurációja.
• Certificate Services adatbázis (ha telepítve van): A tanúsítványokhoz kapcsolódó adatok.
• IIS metabase (ha telepítve van): Az IIS webkiszolgáló beállításai.

Lényegében, ha visszaállítunk egy rendszerállapot-mentést, azzal visszaállítjuk a domain kontroller összes Active Directoryval kapcsolatos és az alapvető rendszerfájljait arra az állapotra, amikor a mentés készült.

A rendszerállapot-mentés fontossága a DSRM-mel összefüggésben

A DSRM önmagában nem oldja meg a problémát; csak a hozzáférést biztosítja a sérült rendszerhez. A tényleges helyreállítás egy megbízható rendszerállapot-mentésből történik. Ennek hiányában a DSRM csak korlátozottan, legfeljebb a jelszó visszaállítására vagy a metadatok tisztítására használható, de az Active Directory adatbázisának valós visszaállítására nem.

Biztonsági mentési stratégiák

• Rendszeres mentések: Alapvető fontosságú a domain controllerek rendszeres rendszerállapot-mentése. A gyakoriság a változások volumenétől függ, de napi mentés erősen ajánlott.
• Több mentési pont: Tartsunk több mentési pontot (pl. az elmúlt 7 nap, vagy az elmúlt 4 hét mentéseit), hogy rugalmasan választhassunk a visszaállításkor.
• Mentési célhely: A mentéseket ne a domain kontroller helyi meghajtójára mentsük, hanem egy hálózati megosztásra, NAS-ra, SAN-ra vagy felhőalapú tárhelyre. Ez biztosítja, hogy hardverhiba esetén is hozzáférjünk a mentéshez.
• Tesztelés: Rendszeresen teszteljük a rendszerállapot-mentések visszaállítását egy tesztkörnyezetben. Ez az egyetlen módja annak, hogy megbizonyosodjunk arról, hogy a mentések érvényesek és használhatók vészhelyzet esetén.

A Windows Server Backup (WSB) használata

A Windows Server Backup egy beépített mentési eszköz, amely képes rendszerállapot-mentések készítésére és visszaállítására. Bár vannak fejlettebb, harmadik féltől származó megoldások, a WSB egy alapvető és ingyenes opció.

Rendszerállapot-mentés készítése WSB-vel:

1. Telepítse a Windows Server Backup szolgáltatást a Server Managerből (ha még nincs telepítve).
2. Nyissa meg a Windows Server Backup konzolt.
3. Kattintson a „Local Backup” (Helyi mentés) menüpontra, majd a „Backup Schedule” (Mentési ütemezés) vagy „Backup Once” (Egyszeri mentés) opcióra.
4. Kövesse a varázsló lépéseit. A „Select Backup Configuration” (Mentési konfiguráció kiválasztása) lépésnél válassza a „Custom” (Egyéni) lehetőséget, majd a „Add Items” (Elemek hozzáadása) gombra kattintva válassza ki a „System State” (Rendszerállapot) opciót.
5. Válassza ki a mentés célhelyét (pl. hálózati megosztás vagy dedikált lemez).
6. Fejezze be a varázslót.

Rendszerállapot-helyreállítás WSB-vel DSRM módban:

1. Indítsa el a domain controllert DSRM módban.
2. Nyisson egy emelt szintű parancssort.
3. A visszaállításhoz használja a wbadmin parancsot. Először meg kell találnia a rendelkezésre álló mentéseket:
   wbadmin get versions -backuptarget: (pl. -backuptarget:\\server\share)
4. A kimenetből válassza ki a visszaállítani kívánt verziót (Version Identifier).
5. Ezután indítsa el a visszaállítást:
   wbadmin start systemstaterecovery -version: -backuptarget: -authsysvol (az -authsysvol kapcsolóval biztosítjuk a SYSVOL autoritatív visszaállítását is, ami kritikus a GPO-k integritásához).
6. A parancs megerősítést kér, majd elkezdi a visszaállítást.
7. Miután a visszaállítás befejeződött, indítsa újra a DC-t normál üzemmódban.

A DSRM és a rendszerállapot-mentés kéz a kézben járnak a hatékony Active Directory katasztrófa-helyreállításban. A gondos tervezés, a rendszeres mentések és a tesztelés elengedhetetlen a hálózati szolgáltatások folytonosságának biztosításához.

Biztonsági megfontolások és legjobb gyakorlatok a DSRM használatakor

A Directory Services Restore Mode (DSRM) egy rendkívül erős eszköz, amely mélyreható hozzáférést biztosít a domain kontrollerhez és az Active Directory adatbázisához. Ebből adódóan a DSRM-mel kapcsolatos biztonsági megfontolások és a legjobb gyakorlatok betartása kulcsfontosságú a teljes hálózati infrastruktúra védelme szempontjából.

Biztonsági kockázatok

A DSRM egy „hátsó ajtó” a domain kontrollerhez. Ha valaki hozzáférést szerez a DSRM jelszóhoz és fizikailag vagy virtuálisan hozzáfér a szerverhez, az potenciálisan:

• Kikerülheti az Active Directory biztonsági mechanizmusait: Mivel a DSRM a helyi SAM adatbázist használja a hitelesítéshez, egy támadó, aki ismeri a DSRM jelszót, bejuthat a DC-be, anélkül, hogy az Active Directory szabályai érvényesülnének.
• Módosíthatja vagy törölheti az Active Directory adatbázisát: Az NTDSUTIL eszközzel súlyos károkat okozhatnak, beleértve az objektumok törlését, a séma módosítását, vagy a teljes AD adatbázis visszaállítását egy korábbi, esetleg kompromittált állapotból.
• Hozzáadhat vagy módosíthat rendszergazdai fiókokat: Bár a DSRM nem a tartományi adminisztrátorhoz ad hozzáférést, a helyi rendszergazdai fiókkal bejelentkezve manipulálhatók a rendszerfájlok, amelyek potenciálisan lehetővé teszik a tartományi jogosultságok megszerzését.
• Kivonhat (dump) jelszó-hasheket: A DSRM módban bizonyos eszközökkel kinyerhetők a helyi SAM adatbázisból a jelszó-hashek, beleértve a DSRM jelszó hash-ét is.

Legjobb gyakorlatok a DSRM biztonságos használatához

A fent említett kockázatok minimalizálása érdekében a következő legjobb gyakorlatokat kell követni:

1. Erős és egyedi DSRM jelszó

• A DSRM jelszó legyen komplex (nagy- és kisbetűk, számok, speciális karakterek).
• A DSRM jelszó különböző legyen a tartományi rendszergazdai jelszótól és az összes többi jelszótól.
• Rendszeresen, de legalább évente egyszer változtassuk meg a DSRM jelszót.

2. Jelszó biztonságos tárolása

• Ne tárolja a DSRM jelszót egyszerű szöveges fájlban a domain kontrolleren vagy könnyen hozzáférhető helyen.
• Használjon jelszókezelő szoftvert (pl. KeePass, LastPass Enterprise), amely titkosított formában tárolja a jelszavakat.
• Alternatív megoldásként nyomtassa ki a jelszót, és tárolja egy fizikailag biztonságos helyen (pl. széfben), amelyhez csak a megbízható rendszergazdák férhetnek hozzá.
• A jelszót a katasztrófa-helyreállítási terv részeként dokumentálja, és gondoskodjon arról, hogy több, megbízható személy is hozzáférhessen vészhelyzet esetén.

3. Fizikai biztonság

• A domain kontrollereket (legyenek azok fizikai vagy virtuális gépek) fizikailag védett környezetben kell tárolni (pl. zárt szerverszoba, adatközpont).
• Korlátozza a hozzáférést a szerverek konzoljához. Ha valaki fizikailag hozzáfér a szerverhez, és újraindíthatja, akkor potenciálisan bejuthat DSRM-be.

4. Rendszeres biztonsági mentések és tesztelés

• Készítsen rendszeres rendszerállapot-mentéseket a domain kontrollerekről.
• Tesztelje a mentések visszaállítását egy izolált tesztkörnyezetben. Ez nemcsak a mentések érvényességét ellenőrzi, hanem gyakorlási lehetőséget is biztosít a DSRM használatára.

5. Biztonsági audit és monitorozás

• Monitorozza a domain kontrollerek eseménynaplóit (Event Logs) a szokatlan bejelentkezési kísérletek vagy DSRM módba való belépések után.
• Alkalmazzon biztonsági auditálást az Active Directoryban, hogy nyomon kövesse a kritikus módosításokat.

6. Képzés és tudatosság

• Csak a megfelelően képzett és megbízható rendszergazdák férjenek hozzá a DSRM jelszóhoz és végezzenek DSRM alapú műveleteket.
• Biztosítsa, hogy minden érintett személy tisztában legyen a DSRM használatával járó kockázatokkal és a biztonsági protokollokkal.

A DSRM egy „utolsó mentsvár” eszköz, amely kritikus fontosságú a katasztrófa-helyreállításban. Azonban hatékony és biztonságos használata megköveteli a gondos tervezést, a szigorú biztonsági protokollokat és a folyamatos odafigyelést. Egy jól átgondolt DSRM biztonsági stratégia nélkül a helyreállítási képességünk is veszélybe kerülhet, és a hálózatunk sebezhetővé válhat.

DSRM a gyakorlatban: tipikus forgatókönyvek és hibaelhárítás

A DSRM (Directory Services Restore Mode) elméleti alapjainak megismerése után nézzük meg, milyen tipikus forgatókönyvekben használjuk a gyakorlatban, és milyen gyakori problémákkal szembesülhetünk, valamint azok megoldásával.

Tipikus DSRM használati forgatókönyvek

1. Véletlenül törölt Active Directory objektum visszaállítása

Ez az egyik leggyakoribb ok, amiért az autoritatív visszaállítást alkalmazzuk. Egy felhasználó, csoport, vagy akár egy teljes OU törlése súlyos következményekkel járhat.

1. Azonosítsa a törlés időpontját.
2. Válasszon egy rendszerállapot-mentést, amely a törlés előtt készült.
3. Indítsa el a sérült vagy egy új, tiszta domain controllert DSRM módban.
4. Végezzen nem-autoritatív rendszerállapot-helyreállítást a kiválasztott mentésből.
5. Miután a helyreállítás befejeződött, de még DSRM módban van, használja az NTDSUTIL-t az autoritatív visszaállításhoz (authoritative restore almodul, restore object vagy restore subtree parancs).
6. Indítsa újra a DC-t normál üzemmódban. A visszaállított objektum replikálódik a hálózat többi DC-jére.

2. Elfelejtett Active Directory tartományi rendszergazdai jelszó

Bár ritka, előfordulhat, hogy a tartományi rendszergazdai jelszó elfelejtődik, és nincs más tartományi rendszergazda, aki visszaállíthatná.

1. Indítsa el az egyik domain controllert DSRM módban.
2. Jelentkezzen be a DSRM felhasználóval és jelszóval.
3. Nyisson egy emelt szintű parancssort.
4. Használja a net user Administrator * parancsot a helyi rendszergazdai jelszó (ez nem a tartományi admin, hanem a helyi SAM-ben lévő) visszaállítására, vagy használja az NTDSUTIL-t a DSRM jelszó visszaállítására, ha az is elveszett.
5. Ezután használja a net user <új_jelszó> parancsot a tartományi rendszergazdai jelszó visszaállítására. Mivel DSRM módban a rendszergazda rendelkezik a megfelelő jogosultságokkal, ez a művelet sikeres lesz.
6. Indítsa újra a DC-t normál üzemmódban.

3. Sérült NTDS.DIT fájl

Ha az Active Directory adatbázisa valamilyen okból (hardverhiba, szoftveres hiba, áramszünet) megsérül, a DC nem fog tudni normálisan elindulni.

1. Indítsa el a sérült domain controllert DSRM módban.
2. Próbálja meg ellenőrizni az adatbázis integritását az NTDSUTIL files almoduljának integrity parancsával.
3. Ha az integritásellenőrzés hibát mutat, végezzen nem-autoritatív rendszerállapot-helyreállítást egy korábbi, működőképes mentésből.
4. Ha nincs mentés, vagy a mentés is sérült, megpróbálhatja az ntdsutil files recover parancsot, de ennek sikeressége korlátozott.
5. Miután a helyreállítás sikeresen befejeződött, indítsa újra a DC-t normál üzemmódban.

4. Domain Controller eltávolítása utáni „szellemkép” metaadatok tisztítása

Ha egy domain controllert nem megfelelően távolítottak el a hálózatból (pl. egyszerűen kikapcsolták), a metaadatai továbbra is ott maradhatnak az Active Directoryban, ami replikációs hibákat okozhat.

1. Jelentkezzen be egy másik, működő domain kontrollerre (vagy a korábbi DC-re, ha az DSRM módban van, de inkább egy működő DC-t használjunk).
2. Nyisson egy emelt szintű parancssort.
3. Használja az NTDSUTIL metadata cleanup almodulját a „szellemkép” DC eltávolításához (lásd az NTDSUTIL részletesebb leírását).
4. Győződjön meg arról, hogy a DNS-ből is eltávolította a DC-hez tartozó rekordokat.

Gyakori hibaelhárítási problémák DSRM használatakor

1. Elfelejtett DSRM jelszó

Ez az egyik leggyakoribb probléma.

• Megoldás: Ha a DC normálisan elindul, használja az NTDSUTIL set dsrm password parancsát, vagy a dsrmadmainpassword parancsot a jelszó visszaállítására, ahogy azt korábban tárgyaltuk. Ha a DC nem indul el normálisan, és nincs más működő DC, akkor bonyolultabb a helyzet, és előfordulhat, hogy a DC-t újra kell telepíteni, vagy egy teljes erdő-helyreállítást kell végrehajtani, ha ez az egyetlen DC.

2. A rendszerállapot-mentés nem található vagy sérült

Ha a mentés nem elérhető vagy nem olvasható, a helyreállítás lehetetlen.

• Megoldás: Rendszeres mentések készítése több célhelyre, és azok rendszeres tesztelése elengedhetetlen. Ha nincs mentés, és a DC nem állítható helyre, akkor a legrosszabb esetben az Active Directoryt újra kell építeni, ami rendkívül időigényes és adatvesztéssel járhat.

3. Replikációs problémák a visszaállítás után

Nem-autoritatív visszaállítás után a DC-nek replikálnia kell a többi DC-vel. Ha ez nem történik meg, vagy hibásan zajlik, problémák adódhatnak.

• Megoldás: Ellenőrizze a DNS beállításokat a visszaállított DC-n (mutasson a működő DC-kre). Ellenőrizze a hálózati kapcsolatot. Futtasson repadmin /replsummary és dcdiag parancsokat a replikációs problémák diagnosztizálására. Kényszerítse a replikációt a repadmin /syncall paranccsal.

4. DSRM módban nincs hálózati kapcsolat

Alapértelmezetten a DSRM módban csak a lokális szolgáltatások indulnak el, és a hálózat korlátozott lehet.

• Megoldás: Néhány esetben szükség lehet a hálózati kártya illesztőprogramjainak manuális telepítésére vagy a hálózati szolgáltatások indítására DSRM módban, ha távoli mentésből kell visszaállítani. Győződjön meg róla, hogy a hálózati konfiguráció megfelelő.

A DSRM használata során felmerülő problémák gyakran összetettek, és megkövetelik a mélyreható Active Directory és Windows Server ismereteket. A legjobb védekezés a megelőzés: gondos tervezés, rendszeres mentések és a katasztrófa-helyreállítási tervek rendszeres tesztelése.

DSRM a modern Active Directory környezetekben: virtualizáció és felhőmegfontolások

Az informatika világa folyamatosan fejlődik, és az Active Directory környezetek sem kivételek. A virtualizáció és a felhőalapú megoldások egyre elterjedtebbé válnak, ami új megfontolásokat vet fel a DSRM (Directory Services Restore Mode) használatával kapcsolatban. Bár az alapelvek változatlanok maradnak, a megvalósítás és a legjobb gyakorlatok némileg módosulhatnak.

DSRM virtualizált domain controllerek esetén

A legtöbb vállalat ma már virtualizált környezetben futtatja a domain kontrollereit (Hyper-V, VMware vSphere stb.). Ez számos előnnyel jár, de a DSRM szempontjából van néhány speciális szempont:

• Konzol hozzáférés: Ahogy korábban említettük, RDP-n keresztül nem lehet bejelentkezni DSRM módban. Virtuális gépek esetén a hipervizor menedzsment konzolját (pl. Hyper-V Manager, vSphere Client, vagy távoli konzol kliensek) kell használni a virtuális gép konzoljának eléréséhez. Ez elengedhetetlen a boot menü eléréséhez és a DSRM-be való bejelentkezéshez.
• Pillanatképek (Snapshots): A pillanatképek rendkívül hasznosak a virtuális gépek gyors visszaállításához. Azonban az Active Directory domain kontrollerek esetében a pillanatképek használatát nagyon óvatosan kell kezelni.
  • Nem-produkciós környezetben: Fejlesztési és tesztelési célokra a pillanatképek hasznosak lehetnek a DSRM alapú helyreállítási eljárások gyakorlásához.
  • Produkciós környezetben: Soha ne használjon pillanatképeket éles domain kontrollerek visszaállításához, kivéve, ha az egész Active Directory erdőt vissza kell állítani (erdő-helyreállítási forgatókönyv). Ennek oka az, hogy a pillanatképek nem frissítik a domain kontroller USN-jét (Update Sequence Number) vagy a meghívási azonosítóját (Invocation ID). Ha egy DC-t pillanatképből állít vissza, az úgy tűnik majd a többi DC számára, mintha visszautazott volna az időben, ami replikációs inkonzisztenciákat, „USN rollback” problémákat és adatvesztést okozhat.
  • Alternatíva: Helyette mindig a rendszerállapot-mentést (System State Backup) és a DSRM-et használja a domain kontrollerek megbízható visszaállításához. A Windows Server 2012-től kezdve a Microsoft bevezetett egy „VM-Generation ID” funkciót, amely bizonyos esetekben segíthet elkerülni az USN rollback-et virtuális környezetben, de a legjobb gyakorlat továbbra is a rendszerállapot-mentés használata.
• Virtuális hálózat: DSRM módban a virtuális hálózati adaptereknek megfelelően kell működniük, ha hálózati erőforrásokról (pl. hálózati mentési célhely) szeretnénk visszaállítani. Győződjön meg róla, hogy a virtuális hálózati beállítások konzisztensek.

DSRM és felhőalapú Active Directory (Azure AD Connect, Azure AD DS)

A felhőalapú Active Directory megoldások, mint az Azure Active Directory (Azure AD) vagy az Azure Active Directory Domain Services (Azure AD DS), némileg más megközelítést igényelnek a helyreállítás szempontjából, mivel ezek Managed Services, és a DSRM-hez hasonló helyi hozzáférés korlátozott vagy nem létezik.

• Azure Active Directory (Azure AD): Az Azure AD egy felhőalapú identitás- és hozzáférés-kezelő szolgáltatás, amely alapvetően eltér a hagyományos, helyszíni Active Directorytól. Nincs „DSRM” mód az Azure AD-ben, mivel a Microsoft kezeli az infrastruktúrát és a helyreállítást. Az Azure AD helyreállítása a Microsoft belső protokolljai és redundanciája alapján történik. A felhasználói adatok visszaállítása (pl. véletlen törlés esetén) az Azure Portalon keresztül vagy PowerShell parancsokkal történhet (pl. soft-delete funkciók).
• Azure AD Connect: Ez az eszköz szinkronizálja a helyszíni Active Directoryt az Azure AD-vel. Ha a helyszíni AD-ben probléma merül fel, és DSRM-mel kell helyreállítani, az hatással lehet az Azure AD-re is, ha a szinkronizálás újraindul. Fontos, hogy a helyreállítás után ellenőrizzük a szinkronizálás állapotát, és szükség esetén teljes szinkronizálást futtassunk.
• Azure Active Directory Domain Services (Azure AD DS): Ez egy Managed Domain Service, amely hagyományos Active Directory funkcionalitást biztosít a felhőben. Bár a Microsoft kezeli az infrastruktúrát, bizonyos mértékig hozzáférést biztosít a tartományhoz. Azonban itt sincs közvetlen „DSRM” hozzáférés, mivel a Microsoft felelős az alapul szolgáló tartományvezérlők redundanciájáért és helyreállításáért. A felhasználók és csoportok kezelése távoli adminisztrációs eszközökkel történik.

Összefoglalva, a DSRM elsősorban a helyszíni (on-premises) és IaaS (Infrastructure as a Service) alapú, virtualizált Windows Server domain kontrollerekre vonatkozik. A felhőalapú, Managed Service modellek (PaaS, SaaS) esetében a helyreállítási mechanizmusok eltérőek, és a szolgáltató felelősségi körébe tartoznak. Mindazonáltal a helyi AD infrastruktúra továbbra is kulcsfontosságú marad sok vállalat számára, és a DSRM ismerete elengedhetetlen a megbízható működés fenntartásához.