← Active Directory

Backup & Recovery

Ein Skript hat 400 Konten gelöscht, und die Löschung ist längst auf allen Domain Controllern angekommen — Redundanz hat sie nicht aufgehalten, sondern verteilt. Ob der Fall zehn Minuten oder einen halben Tag kostet, entschied sich Monate vorher: mit der Frage, ob der AD-Papierkorb aktiv war. Dieses Modul behandelt Wiederherstellung als Entscheidungsbaum — warum Replikation kein Backup ist, autoritativ gegen nicht autoritativ und warum der Umfang die eigentliche Entscheidung ist, die drei Wege der Objekt-Wiederherstellung mit sehr unterschiedlichem Ergebnis, die Tombstone-Lifetime als Verfallsdatum jeder Sicherung, der stille Replikationsausfall nach einem zurückgesetzten Prüfpunkt — und was ein Forest Recovery verlangt, das niemand unter Druck zum ersten Mal durchspielen sollte.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-06

Replikation ist kein Backup

AD repliziert Multi-Master: jede Änderung an einem DC wandert automatisch zu allen anderen. Das schützt gegen Hardware-Ausfall eines einzelnen DC — aber nicht gegen einen logischen Fehler.

Löscht jemand versehentlich eine OU mit hunderten Konten oder korrumpiert ein fehlerhaftes Skript Attribute, dann repliziert AD diesen Schaden zuverlässig auf alle DCs. Zehn Domain Controller machen die Löschung nur zehnfach vorhanden, nicht rückgängig.

MerksatzRedundanz schützt gegen Ausfall, Backup gegen Fehler und Korruption. Nur ein AD-fähiges System-State-Backup je Domäne — regelmäßig getestet — deckt logische Schäden und den Totalverlust ab.
Der zweite Grund, warum Redundanz nicht genügtMulti-Master-Replikation verteilt jede Änderung — auch die falsche, und zwar mit derselben Geschwindigkeit wie die richtige. Ein fehlerhaftes Skript, das Attribute überschreibt, hat seine Wirkung binnen Minuten forestweit. Redundanz macht dieses Problem sogar größer statt kleiner: Es gibt keinen unberührten Knoten, von dem man abschreiben könnte. Genau das ist der Punkt, an dem eine Sicherung die einzige Quelle des früheren Zustands ist.

Authoritative vs. non-authoritative Restore

Wird ein DC aus einem Backup zurückgespielt, entscheidet der Restore-Modus, was mit den wiederhergestellten Objekten passiert:

Non-authoritative
Der DC kommt mit altem Stand hoch und lässt sich von den anderen DCs auf den aktuellen Stand nachführen. Das ist der Normalfall, um einen ausgefallenen DC wieder einzureihen.
Authoritative
Ein Objekt/eine Teilstruktur wird mit erhöhter Versionsnummer markiert, sodass sie sich beim Replizieren gegen alle anderen DCs durchsetzt — nötig, um versehentlich Gelöschtes zurückzuholen.
KernmissverständnisEin non-authoritative Restore holt gelöschte Objekte nicht zurück: Die anderen DCs kennen den „gelöscht“-Zustand mit höherer Version und re-replizieren die Löschung sofort wieder auf den frisch zurückgespielten DC. Zum Zurückholen brauchst du authoritative (oder den Papierkorb).
Den Umfang eng setzenEine autoritative Wiederherstellung überschreibt den Stand aller anderen Domain Controller — für genau die Objekte, die man als maßgeblich markiert. Wird der Umfang zu weit gefasst, etwa ein ganzer Zweig statt der betroffenen Objekte, verschwinden auch alle legitimen Änderungen, die seit dem Sicherungszeitpunkt in diesem Zweig entstanden sind: neu angelegte Konten, geänderte Kennwörter, angepasste Mitgliedschaften. Der Umfang ist damit die eigentliche Entscheidung — nicht die Wahl der Betriebsart.

Objekt-Recovery: drei Wege, zwei Fallen

Für ein einzelnes gelöschtes Konto gibt es drei Optionen — mit sehr unterschiedlichem Ergebnis:

AD-Papierkorb (Recycle Bin)
Stellt das Objekt mit allen Attributen wieder her — auch link-valued wie Gruppenmitgliedschaften — und mit derselben SID. Muss vorab aktiviert sein (irreversibel). Der saubere Weg.
Tombstone-Reanimation
Belebt den „Grabstein“ wieder, aber link-valued Attribute (Gruppen) und geleerte Attribute sind weg und müssen manuell rekonstruiert werden. Notlösung ohne Papierkorb/Backup.
Neu anlegen
Erzeugt eine neue SID. Alle über die alte SID vergebenen Zugriffe (ACLs, Profile, Postfach) sind verloren — auch wenn der Name identisch ist.
MerksatzDie SID ist die Identität, nicht der Name. Wer neu anlegt, baut einen Namensvetter ohne Rechte. Wer reanimiert, verliert die Gruppen. Der Papierkorb behält beides — deshalb vor dem ersten Störfall aktivieren.
Warum Reanimation die schlechteste der drei istOhne aktiven Papierkorb bleibt von einem gelöschten Objekt nur ein Grabstein — und der behält lediglich eine kleine Teilmenge der Attribute. Ein reanimiertes Konto hat zwar seine ursprüngliche SID zurück und damit die Berechtigungen, die direkt an ihr hängen; Gruppenmitgliedschaften und die meisten anderen Attribute sind jedoch weg. Was auf dem Papier wie eine Rettung aussieht, erzeugt in der Praxis ein Konto, das existiert, aber nichts mehr darf — und niemand hat eine Liste, was es vorher durfte.

USN-Rollback: warum man einen DC nicht „zurückspult“

Jeder DC nummeriert seine Änderungen fortlaufend über die USN (Update Sequence Number) und identifiziert seine Datenbank-Instanz über eine Invocation-ID. Die anderen DCs merken sich „von diesem Partner habe ich bis USN *n* gesehen“.

Setzt du einen DC per VM-Snapshot oder Image auf einen älteren Stand zurück — ohne AD-fähigen Restore — kann seine USN hinter das fallen, was die Partner schon gesehen haben. Er würde USNs erneut verwenden, die Partner aber für „schon repliziert“ halten. Ergebnis: USN-Rollback mit Replikationsdivergenz. Unterstützte AD-Versionen erkennen diesen Zustand typischerweise und halten die Replikation an (mit passenden Ereignissen); darauf darfst du dich nicht als Recovery-Mechanismus verlassen.

AusnahmeAb Windows Server 2012 kann ein virtueller DC auf einem Hypervisor mit VM-GenerationID-Unterstützung einen Snapshot-Revert erkennen: Die GenerationID ändert sich, der DC setzt seine Invocation-ID zurück und meldet sich sauber — ein USN-Rollback wird so vermieden. Ohne diese Plattformunterstützung ist ein Snapshot-Revert nicht unterstützt.

Tombstone Lifetime & Lingering Objects

Gelöschte Objekte werden nicht sofort entfernt, sondern als Tombstone aufbewahrt — für die Tombstone Lifetime (TSL). In neu erstellten Forests mit aktuell unterstützten Windows-Server-Versionen sind das typischerweise 180 Tage; bestehende Forests können einen anderen, auch historischen oder bewusst konfigurierten Wert haben. Danach räumt die Garbage Collection den Grabstein endgültig weg.

War ein DC länger als die TSL offline, hat er die Löschungen nie mitbekommen und die Grabsteine sind auf den anderen DCs bereits weggeräumt. Verbindest du ihn jetzt einfach wieder, „kennt“ er Objekte, die überall sonst gelöscht sind — Lingering Objects. Sie können sogar re-repliziert werden und tote Konten oder Gruppen zurückbringen.

MerksatzEin zu lange offline gewesener DC wird nicht einfach wieder verbunden und die TSL wird nicht nachträglich erhöht (die Grabsteine sind schon weg). Richtig: tatsächliche TSL und Replikationslage prüfen, Lingering Objects nach einem unterstützten Verfahren bereinigen oder den DC kontrolliert ersetzen — und Strict Replication Consistency nicht aus Bequemlichkeit abschalten.
Der Wert, den man nachsieht statt annimmtDie geltende Tombstone-Lifetime hängt davon ab, welche Version auf dem ersten Domain Controller des Forests lief — und ein späteres Upgrade hat sie nicht verändert. Ein gewachsener Forest kann deshalb bis heute auf dem alten, kürzeren Wert stehen, ohne dass es je aufgefallen wäre. Das ist eine Zahl, die man einmal in der eigenen Umgebung abfragt und in die Wiederherstellungsdokumentation schreibt — sie begrenzt gleichzeitig die brauchbare Lebensdauer jeder Sicherung.

Forest Recovery: der geordnete Ablauf

Ist der ganze Forest zerstört oder kompromittiert (z. B. Ransomware, ein manipulierter Schema-/Domänen-Zustand), hilft kein einzelner Restore. Microsofts Forest-Recovery-Leitfaden gibt einen strikten Ablauf vor — die Kernidee: Vertrauen wiederherstellen, bevor irgendein DC wieder ans Produktionsnetz kommt.

DCs isolieren→1. schreibbaren DC je Domäne aus geprüftem Backup (non-auth) restoren→Metadaten der übrigen DCs bereinigen + FSMO seizen→krbtgt (2×), Computerkonto- & Trust-Passwörter zurücksetzen→Global Catalog & DNS neu aufbauen, Replikation verifizieren→übrige DCs frisch neu aufsetzen & einreihen
Warum krbtgt zweimalDas krbtgt-Konto signiert alle Kerberos-Tickets. Bei Kompromittierung muss sein Passwort zweimal zurückgesetzt werden, weil AD die letzten zwei Passwörter in der History akzeptiert — ein einmaliger Reset ließe das alte, möglicherweise dem Angreifer bekannte Geheimnis noch gelten.

Der Papierkorb: was er kann, und was er kostet

Der AD-Papierkorb ist die einzige Wiederherstellungsmethode, die ein gelöschtes Objekt vollständig zurückbringt — mit seiner SID, seinen Gruppenmitgliedschaften und allen Attributen, ohne Ausfallzeit und ohne einen Domain Controller neu zu starten. Genau deshalb lohnt es, seine drei Eigenschaften vorher zu kennen.

Nicht rückgängig zu machen
Einmal eingeschaltet, lässt er sich laut Dokumentation nicht wieder abschalten. Das ist keine Warnung vor einem Risiko, sondern ein Hinweis, dass die Entscheidung endgültig ist.
Er kostet Platz, dauerhaft
Die Verzeichnisdatenbank wächst auf jedem Domain Controller des Forests, weil gelöschte Objekte samt aller Attribute vorgehalten werden — und der Bedarf wächst mit der Zeit weiter.
Er wirkt erst nach Replikation
Bis die Konfigurationsänderung alle Domain Controller erreicht hat, ist er nicht vollständig funktionsfähig. Zwischen dem Einschalten und dem Verlassen auf ihn liegt also ein Fenster.
Die Bedingung, die alles entscheidetDer Papierkorb hilft nur für Objekte, die gelöscht wurden, während er aktiv war. Nachträglich einschalten bringt nichts zurück. Das macht ihn zu einer der wenigen Maßnahmen, deren Wert vollständig davon abhängt, dass jemand sie vor dem Vorfall getroffen hat — und deren Fehlen man erst im Vorfall bemerkt, wenn es zu spät ist.
Beim Wiederherstellen ganzer BäumeEine Sammelwiederherstellung sortiert nach bestem Bemühen so, dass übergeordnete Objekte vor ihren untergeordneten wiederhergestellt werden. Verlässlich ist das nicht: Bei unvollständigen Teilbäumen oder wenn die Wiederherstellung eines übergeordneten Objekts scheitert, bleiben die darunter liegenden zurück. Die Dokumentation empfiehlt deshalb ausdrücklich, zuerst die übergeordneten Objekte wiederherzustellen und die Unterbäume danach in einem eigenen Schritt. Für Objekte außerhalb der Domänenpartition — etwa in der Konfigurations- oder einer DNS-Partition — führt der Weg ohnehin über Restore-ADObject.

Was ein Backup taugt: drei Zahlen und eine Bedingung

„Wir haben Backups“ ist keine Aussage über Wiederherstellbarkeit. Vier Angaben machen daraus eine — und drei davon bekommt man nur durch Ausprobieren.

  • Wie alt darf der Stand sein? Der Abstand zwischen zwei Sicherungen bestimmt, wie viel Verzeichnisarbeit im Ernstfall verloren geht. Bei Active Directory ist das oft weniger dramatisch als gedacht — Kennwörter und Mitgliedschaften lassen sich nacharbeiten, ein ganzer Tag Kontoneuanlagen nicht.
  • Wie lange dauert es? Die Zeit von der Entscheidung bis zur ersten erfolgreichen Anmeldung. Diese Zahl kennt man nur aus einer Übung, und sie ist regelmäßig ein Vielfaches der Schätzung.
  • Wer kann es? Eine Wiederherstellung, die nur eine Person durchführen kann, ist im Urlaub dieser Person nicht verfügbar.
  • Und die Bedingung: Die Sicherung muss jünger als die Tombstone-Lifetime sein. Eine ältere bringt Objekte zurück, deren Löschung im Verzeichnis nicht mehr bekannt ist — sie erzeugt genau die Lage, die man vermeiden will.
Was gesichert werden mussFür Active Directory ist die relevante Einheit der Systemstatus eines Domain Controllers — er umfasst die Verzeichnisdatenbank, die Protokolldateien, SYSVOL und die Registrierung. Ein Abbild des Datenträgers ist kein Ersatz: Sein Zurückspielen erzeugt genau den stillen Replikationsausfall, gegen den die AD-fähigen Verfahren gebaut sind. Und mindestens ein solcher Stand wird je Domäne gebraucht, nicht je Forest.

Forest Recovery: warum es ein Runbook braucht

Ein Forest Recovery unterscheidet sich von jeder anderen Wiederherstellung in einem Punkt: Es ist streng sequenziell und verlangt, dass währenddessen kein anderer Domain Controller mitredet. Alle bis auf den ersten wiederhergestellten müssen isoliert bleiben, sonst repliziert der beschädigte Zustand zurück in die gerade gesäuberte Umgebung.

Daraus folgt eine Reihe von Entscheidungen, die niemand unter Druck zum ersten Mal treffen sollte: welcher Domain Controller je Domäne der Ausgangspunkt ist, in welcher Reihenfolge die Domänen zurückkommen, wann Rollen neu vergeben werden, wann die restlichen DCs neu aufgebaut statt wiederhergestellt werden, und wann die Umgebung wieder ans Netz darf.

Warum `krbtgt` zweimalBei einem Vorfall gehört das Kennwort des krbtgt-Kontos gewechselt — und zwar zweimal, weil eine Historie von zwei Werten geführt wird und ein einzelner Wechsel den vorherigen Schlüssel gültig lässt. Zwischen beiden Wechseln muss genug Zeit für die vollständige Replikation liegen: Wer sie zu schnell hintereinander ausführt, sperrt Domain Controller aus, die den ersten Wechsel noch nicht kennen — und macht aus einer Abwehrmaßnahme einen selbst verursachten Ausfall.
Der Teil, den man nicht üben kann — und der Teil, den man üben mussDen echten Ernstfall übt niemand vollständig. Üben lassen sich aber die Teile, an denen es tatsächlich scheitert: Ist die Sicherung lesbar? Kennt jemand das DSRM-Kennwort? Existiert eine Umgebung, in der isoliert wiederhergestellt werden kann? Liegt das Runbook an einem Ort, der ohne Active Directory erreichbar ist? Die letzte Frage ist die, die am häufigsten mit „nein“ beantwortet wird — das Runbook liegt im Intranet, und das Intranet braucht eine Anmeldung.

Durchgerechnet: eine gelöschte OU mit 400 Konten

Den Weg wählen, bevor man etwas anfasst

Szenario

Ein Skript hat vor zwei Stunden eine produktive OU mit rund 400 Benutzerkonten gelöscht. Die Löschung ist auf alle Domain Controller repliziert. Es gibt eine System-State-Sicherung von heute Nacht.

Anforderungen

  • Die Konten müssen mit ihren bisherigen Berechtigungen zurückkommen
  • Der laufende Betrieb soll so wenig wie möglich unterbrochen werden

Schritte

  1. Zuerst die Frage, die alles entscheidet: War der AD-Papierkorb zum Zeitpunkt der Löschung aktiv? Wenn ja, ist der Fall in Minuten erledigt — die Objekte kommen samt SID, Mitgliedschaften und Attributen zurück, ohne Ausfallzeit.
  2. Falls ja, in der richtigen Reihenfolge: Erst die OU selbst wiederherstellen, dann die darin enthaltenen Konten. Eine Sammelaktion über den ganzen Baum sortiert nur nach bestem Bemühen und lässt bei einem Fehlschlag am übergeordneten Objekt die untergeordneten liegen.
  3. Falls nein — was kommt nicht infrage: Die Konten neu anzulegen. Sie bekämen neue SIDs und damit keine der bestehenden Berechtigungen; man hätte 400 Namensvettern ohne Zugriff und keine Liste, worauf sie einmal berechtigt waren.
  4. Falls nein — was infrage kommt: Eine autoritative Wiederherstellung aus der Nachtsicherung, begrenzt auf genau diesen Teilbaum. Sie überschreibt den Löschzustand auf allen Domain Controllern.
  5. Und ihr Preis: Alles, was sich in diesem Teilbaum seit der Nacht legitim geändert hat, wird mit zurückgedreht. Der Umfang gehört deshalb so eng wie möglich gesetzt — und was zwischen Sicherung und Löschung passiert ist, gehört ermittelt und nachgezogen.

Merksatz: Der Papierkorb entscheidet zwischen zehn Minuten und einem halben Tag — und die Entscheidung darüber fiel Monate vor dem Vorfall. Das ist der Grund, warum er trotz seiner dauerhaften Kosten fast immer die richtige Wahl ist.

Die Werkzeuge und wofür sie zuständig sind

Wiederherstellung in Active Directory verteilt sich auf wenige Werkzeuge mit klar getrennten Zuständigkeiten. Sie zu verwechseln kostet im Ernstfall Zeit, die man nicht hat.

Verwaltungskonsole
Gelöschte Objekte der Domänenpartition suchen und zurückholen, solange der Papierkorb aktiv war. Der schnellste Weg für den häufigsten Fall.
Restore-ADObject
Dasselbe per Skript — und der einzige Weg für Objekte außerhalb der Domänenpartition, etwa aus der Konfigurations- oder einer DNS-Partition.
Get-ADObject -IncludeDeletedObjects
Nachsehen, was überhaupt noch da ist, bevor man etwas anfasst. Die Bestandsaufnahme vor der Entscheidung.
ntdsutil
Der Werkzeugkasten für die schweren Fälle: autoritative Wiederherstellung, Metadaten bereinigen, das Wiederherstellungs-Kennwort setzen.
repadmin
Nach jeder Wiederherstellung die Gegenprobe: Repliziert wieder alles, und ohne Fehler?
Die Reihenfolge im ErnstfallErst nachsehen, was noch da ist, dann entscheiden, welcher Weg passt, dann handeln — und danach prüfen, ob die Umgebung wieder konvergiert. Der dritte Schritt ist der einzige, den alle im Kopf haben; die anderen drei entscheiden darüber, ob er das Richtige tut.

Zusammenfassung — gleich im Check

Du kennst jetzt die Achsen: authoritative vs. non-authoritative Restore, die drei Wege der Objekt-Recovery (Papierkorb/Reanimation/Neuanlage), die USN-Rollback-Falle bei Snapshot-Reverts, Tombstone Lifetime & Lingering Objects, den geordneten Forest-Recovery-Ablauf und warum Replikation kein Backup ist.

Gleich im CheckIn den nächsten Entscheidungen wählst du für konkrete Störfälle selbst den richtigen Recovery-Weg — und siehst pro Option, warum sie trägt oder aus welchem konkreten Grund sie Daten oder Vertrauen zerstört.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →
Quellen & Aktualität23 Primärquellen · zuletzt geprüft:
  1. 01Microsoft Learn — AD Forest Recovery Guide (Übersicht und geordneter Ablauf)
  2. 02Microsoft Learn — AD Forest Recovery: Perform initial recovery (non-authoritative Restore des ersten DC, Metadaten-Cleanup, FSMO seizen, RID-Pool)
  3. 03Microsoft Learn — AD Forest Recovery: Reset the krbtgt password (zweifacher Reset wegen Passwort-History = 2)
  4. 04Microsoft Learn — Introduction to Active Directory Domain Services (AD DS) Virtualization (VM-GenerationID, USN-Rollback-Schutz)
  5. 05Microsoft Learn — USN and USN Rollback (Ursache, stille Divergenz, Quarantäne)
  6. 06Microsoft Learn — Introducing the Active Directory Recycle Bin (Erhalt von link-valued und non-link-valued Attributen)
  7. 07Microsoft Learn — Outdated Active Directory objects generate event ID 1988 (Lingering Objects, Strict Replication Consistency)
  8. 08learn.microsoft.com/en-us/windows-server/ident…ncements--level-100-
  9. 09learn.microsoft.com/en-us/powershell/module/ac…ory/restore-adobject
  10. 10learn.microsoft.com/en-us/previous-versions/wi…003/cc738018(v=ws.10
  11. 11learn.microsoft.com/en-us/troubleshoot/windows…er-from-usn-rollback
  12. 12Microsoft Learn — Active Directory Recycle Bin overview
  13. 13Microsoft Learn — Advanced AD DS management using AD Administrative Center
  14. 14Microsoft Learn — AD Forest Recovery guide
  15. 15Microsoft Learn — AD Forest Recovery: Perform initial recovery
  16. 16Microsoft Learn — Active Directory Domain Services backup and restore guidance
  17. 17Microsoft Learn — Introduction to Active Directory Domain Services virtualization
  18. 18Microsoft Learn — USN and USN rollback
  19. 19Microsoft Learn — How to detect and remove lingering objects in an AD DS forest
  20. 20Microsoft Learn — Manually remove lingering objects on outdated replication partners
  21. 21Microsoft Open Specifications — Tombstone Lifetime and Deleted-Object Lifetime
  22. 22Microsoft Learn — AD Forest Recovery: Determine how to recover the forest
  23. 23Microsoft Learn — AD Forest Recovery: Reset the krbtgt password