LDAP://Yusufs.Directory.Blog/ - Active Directory|Wiederherstellung

Restoreversuch eines alten AD-Backups

Yusuf Dikmenoglu — Sun, 09 Dec 2012 09:36:52 GMT

Die Tombstone Lifetime (TSL) definiert drei Verhaltensregeln innerhalb einer Active Directory Umgebung. Diese wären:

1. Wie lange ein System State-/Full Server - Backup verwendet werden darf.

2. In welcher Zeit sich die DCs mindestens einmal erfolgreich repliziert haben müssen.

3. Wann ein gelöschtes Objekt endgültig vom Garbage Collection Prozess endgültig aus der AD-Datenbank (NTDS.DIT) entfernt wird.

Welchen Wert die TSL hat, wann und wo die TSL gesetzt wird oder wie man diese ändern kann, ist hier beschrieben:

Die Tombstone Lifetime

Folgende Besonderheiten gibt es bzgl. der TSL:

1. Der Minimalwert der bis einschließlich „Windows Server 2008“ Gültigkeit hat ist „2“. Konfiguriert man bis Windows Server 2008 einen niedrigeren Wert (also 1), wird als Wert 60 festgelegt.

2. Wird ab „Windows Server 2008 R2“ ein Wert kleiner 2 konfiguriert, wird als Wert immer 2 festgelegt. Der Minimalwert den ab Windows Server 2008 R2 die TSL haben kann ist also immer 2.

Was passiert eigentlich wenn man ein AD-Backup versucht rückzusichern, das älter als die TSL ist?

Versucht man nun ein z.B. System State Backup das älter als die TSL ist rückzusichern, erhält man gleich zu Beginn des Restoreversuchs diese Fehlermeldung:

Eine Rücksicherung wird direkt schon vom Backup-Programm geblockt.

Weitere Informationen:
Was passiert in der AD-Datenbank wenn ein Objekt gelöscht wird?
Der Container Deleted Objects
3.1.1.1.5.1 Tombstone Lifetime and Deleted-Object Lifetime

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Ein AD-Schnappschuss erstellen

Yusuf Dikmenoglu — Sun, 30 May 2010 08:10:23 GMT

Mit Windows Server 2008 führte Microsoft eine neue Funktion ein mit der es möglich ist, eine Momentaufnahme (im englischen Snapshot genannt) des Active Directory (AD) im laufenden Betrieb auf einem DC zu erstellen und das sogar ohne den Betrieb zu beeinflussen. Ein AD-Snapshot kann dann zu Analyse- und Vergleichszwecken bereitgestellt werden. Aber auch zum Begutachten eines früheren Datenbestands eignet sich diese Technik hervorragend. Des Weiteren hat der Administrator mit dieser Funktion die Möglichkeit, ohne den DC im Modus Verzeichnisdienste wiederherstellen starten zu müssen, Daten aus dem AD-Snapshot zu exportieren und in der produktiven Umgebung zu importieren. Dabei ist lediglich ein Lese- und kein Schreibzugriff auf ein AD-Snapshot möglich! Mit dieser Technik die auf dem Volumenschattenkopiedienst (VSS) beruht, kann man in wenigen Augenblicken auf einfache Weise, punktgenaue AD-Snapshots der lokalen Kopie der AD-Datenbank (NTDS.dit) erstellen. Genau genommen wird ein Snapshot des gesamten Volumes erstellt, auf der sich die AD-Datenbank samt -Protokolle und dem SYSVOL-Verzeichnis befindet. Dabei können AD-Snapshots manuell oder automatisiert auf DCs, die mindestens unter Windows Server 2008 laufen erstellt werden. Der Domänenfunktionsmodus hat keine Relevanz.

Es gilt zu beachten, dass ein AD-Snapshot keine vollständige Kopie der AD-Datenbank enthält! Vielmehr stellt ein AD-Snapshot eine Sammlung von Datenträgerblöcken in der AD-Datenbank dar, die seit dem letzten AD-Snapshot geändert wurden. Durch zusammenfügen der Blöcke mit der lokalen Kopie der AD-Datenbank, kann der Volumenschattenkopiedienst die lokale Verzeichnisdatenbank zum Zeitpunkt der Erstellung des Snapshots darstellen.

Ein AD-Snapshot wird mit dem Kommandozeilentool NTDSUTIL erstellt. Man könnte zwar auch ein Snapshot im Betriebssystem erstellen, doch nur wenn das AD-Snapshot mit NTDSUTIL erstellt wird ist sichergestellt, dass die AD-Datenbank konsistent ist!

AD-Snapshots die mit Windows Server 2008 R2 fortgeführt werden helfen dem Administrator zu bestimmen, welche AD-Sicherung die gewünschten wiederherzustellenden Daten enthält. Auch wenn man lediglich überprüfen möchte, welche Werte ein Objekt bzw. ein Attribut vor einer Änderung hatte, eignet sich dieses Verfahren. In den AD Versionen vor Windows Server 2008 muss der Administrator mehrere Sicherungssätze rücksichern um zu bestimmen, welche Sicherung die wiederherzustellenden Daten enthält. Dazu ist es zwingend notwendig, dass der DC im Modus Verzeichnisdienst-wiederherstellen neu gestartet wird. Der Nachteil an den vorherigen AD-Versionen ist auch, dass es keine Möglichkeit gibt die AD-Daten die zu verschiedenen Zeitpunkten erstellt wurden zu vergleichen.

Aber: Ein AD-Snapshot ist nicht zur alleinigen Datensicherung geeignet! Er ist nur als Ergänzung gedacht! Denn aus einem AD-Snapshot können Daten bzw. Objekte nur sehr eingeschränkt mit Bordmittel (mit CSVDE oder LDIFDE) oder aufwändig mit Skripts exportiert und in die produktive AD-Umgebung importiert werden.

Ein AD-Snapshot erstellen

Für das Erstellen eines AD-Snapshots werden Domänen-Admin Rechte benötigt. Auf einem DC wird ein AD-Snapshot in der Kommandozeile mit NTDSUTIL wie folgt erstellt:

C:\>NTDSUTIL
NTDSUTIL: Snapshot
Snapshot: Activate Instance NTDS
Aktive Instanz wurde auf "NTDS" festgelegt.
Snapshot: Create
Snapshot wird erstellt...
Der Snapshotsatz {5b9dae90-de11-43b2-a8bb-e842b44ffb62} wurde erfolgreich generiert.
Snapshot:

Ein AD-Snapshot lässt sich auch mit einem Einzeiler erzeugen. Fügt man den folgenden Befehl z.B. in eine Batchdatei und lässt in einem geplanten Task die Batch ausführen (mit entsprechenden Rechten), kann man so das Erstellen von AD-Snapshots zusätzlich zur regelmäßigen System State-Sicherung automatisieren:

C:\>NTDSUTIL Snapshot "Activate Instance NTDS" Create quit quit

NTDSUTIL: Snapshot

Snapshot: Activate Instance NTDS

Aktive Instanz wurde auf "NTDS" festgelegt.

Snapshot: Create

Snapshot wird erstellt...

Der Snapshotsatz {5057fdd0-a0fb-427d-b71a-c36a4d22f9c3} wurde erfolgreich generiert.

Snapshot: quit

NTDSUTIL: quit

C:\> >

Wenn ein AD-Snapshot erstellt wurde, wird in der Ereignisanzeige unter der Serverrolle Active Directory-Domänendienste die Ereignis-ID 2001 mit der Beschreibung NTDS (528) NTDSA: Schattenkopieinstanz 2: Fixierung wurde gestartet. protokolliert.

Die erstellten AD-Snapshots anzeigen

Alle verfügbaren AD-Snapshots die gegenwärtig vom VSS auf einem DC verwaltet werden, lassen sich mit NTDSUTIL wie folgt Anzeigen:

C:\>NTDSUTIL

NTDSUTIL: Snapshot

Snapshot: List All

1: 2010/05/01:15:23 {ad2cf6fc-6fc4-420b-9d43-104196d67a57}

2: C: {41d34055-d61f-41f3-84d7-81b7b4016a8f}

3: 2010/05/02:13:39 {f9675e58-54bb-4a51-be21-60c81c44c286}

4: C: {110b7077-5c11-4b93-99e2-31411f6ebd8d}

5: 2010/05/03:21:21 {f747533a-7fd7-4915-a01d-6f59b1f31cb1}

6: C: {df0a7738-5d2d-4102-b006-e0c8cc712650}

Snapshot: >

Die Ausgabe in diesem Beispiel stellt jeden AD-Snapshot in zwei Zeilen dar. Wie in dem oberen Beispiel zu sehen ist, wurden drei AD-Snapshots erstellt. Sind die AD-Protokolle auf einer anderen Partition gespeichert als die AD-Datenbank, wird eine weitere Zeile angezeigt.

Ein AD-Snapshot löschen >

Auch wenn man genau weiß welchen AD-Snapshot man löschen möchte, muss man sich zuerst mit List All auf der Snapshot Ebene in NTDSUTIL alle verfügbaren AD-Snapshots anzeigen lassen. Lässt man sich die verfügbaren AD-Snapshots vorher nicht anzeigen und versucht mit einem Einzeiler direkt ein AD-Snapshot zu löschen, so kommt es zu dieser Fehlermeldung:

C:\>NTDSUTIL Snapshot "Delete 4"

NTDSUTIL: Snapshot

Snapshot: Delete 4

Ungültiger Snapshotindex 4.
Snapshot: >

Erst wenn man sich alle bestehenden AD-Snapshots anzeigen lässt, kann man ein AD-Snapshot wie folgt löschen:

C:\>NTDSUTIL Snapshot "List All"

NTDSUTIL: Snapshot

Snapshot: List All

1: 2010/05/01:15:23 {ad2cf6fc-6fc4-420b-9d43-104196d67a57}

2: C: {41d34055-d61f-41f3-84d7-81b7b4016a8f}

3: 2010/05/02:13:39 {f9675e58-54bb-4a51-be21-60c81c44c286}

4: C: {110b7077-5c11-4b93-99e2-31411f6ebd8d}

5: 2010/05/03:21:21 {f747533a-7fd7-4915-a01d-6f59b1f31cb1}

6: C: {df0a7738-5d2d-4102-b006-e0c8cc712650}

Snapshot: Delete 4

Der Snapshot {110b7077-5c11-4b93-99e2-31411f6ebd8d} wurde gelöscht.
Snapshot: >

Zum Löschen eines AD-Snapshots kann man einen der beiden Zeilen (die zusammen ein AD-Snapshot darstellen) angeben. Mit Delete 3 kann man ebenfalls dasselbe AD-Snapshot löschen. Anstatt der Nummern kann man auch die GUID angeben. Mit Delete f9675e58-54bb-4a51-be21-60c81c44c286 oder Delete 110b7077-5c11-4b93-99e2-31411f6ebd8d löscht man ebenso dasselbe AD-Snapshot.

Alle AD-Snapshots auf einmal kann man in der Snapshot Ebene mit Delete * löschen.

Ein AD-Snapshot verbinden >

Möchte man auf ein AD-Snapshot zugreifen, muss man diesen im ersten Schritt verbinden. Im zweiten Schritt muss dann das verbundene AD-Snapshot mit dem Datenbankbereitstellungstool DSAMAIN bereitgestellt werden. Um ein AD-Snapshot zu verbinden, gilt es entweder die Nummer oder die GUID bei Mount anzugeben. Doch zuerst müssen auch an dieser Stelle mit List All alle verfügbaren AD-Snapshots aufgerufen werden. Erst danach lässt sich ein AD-Snapshot folgendermaßen verbinden:

C:\>NTDSUTIL Snapshot „List All“

NTDSUTIL: Snapshot

Snapshot: List All

1: 2010/05/01:15:23 {ad2cf6fc-6fc4-420b-9d43-104196d67a57}

2: C: {41d34055-d61f-41f3-84d7-81b7b4016a8f}

3: 2010/05/03:21:21 {f747533a-7fd7-4915-a01d-6f59b1f31cb1}

4: C: {df0a7738-5d2d-4102-b006-e0c8cc712650}

Snapshot: Mount 1

Der Snapshot {41d34055-d61f-41f3-84d7-81b7b4016a8f} wird als C:\$SNAP_201005011523_VOLUMEC$\ bereitgestellt.
Snapshot: >

Nach dem das AD-Snapshot verbunden ist, wird dadurch auf dem %Systemdrive% Laufwerk, beginnend mit der Bezeichnung $SNAP<Erstellungsdatum und Uhrzeit> der AD-Snapshot im Dateisystem eingeblendet. Es ist auch möglich, mehrere AD-Snapshots gleichzeitig zu verbinden. Hat man also mit Mount 1 das erste AD-Snapshot verbunden, kann man anschließend mit Mount 3 das nächste AD-Snapshot zeitgleich verbinden, ohne vorher das erste AD-Snapshot zu trennen. Aus Lastgründen ist es jedoch sinnvoll, nicht mehr als zwei AD-Snapshots gleichzeitig zu verbinden bzw. bereitzustellen!

Es ist auch möglich, die AD-Datenbank aus einer System State-Sicherung zu verbinden und anschließend bereitzustellen. Dazu muss die AD-Datenbank an einen alternativen Ort wiederhergestellt werden.

Die verbundenen AD-Snapshots anzeigen >

Auf der Snapshot Ebene kann man mit List Mounted alle verbundenen AD-Snapshots auflisten:

C:\>NTDSUTIL Snapshot "List Mounted"

NTDSUTIL: Snapshot

Snapshot: List Mounted

1: 2010/05/01:15:23 {ad2cf6fc-6fc4-420b-9d43-104196d67a57}

2: C: {41d34055-d61f-41f3-84d7-81b7b4016a8f} C:\$SNAP_201005011523_VOLUMEC$\

3: 2010/05/03:21:21 {f747533a-7fd7-4915-a01d-6f59b1f31cb1}

4: C: {df0a7738-5d2d-4102-b006-e0c8cc712650}

C:\$SNAP_201005032121_VOLUMEC$\

Snapshot: >

Wie in diesem Beispiel zu sehen ist, sind zwei AD-Snapshots verbunden.

Ein verbundenes AD-Snapshot trennen

Um ein AD-Snaphot zu trennen, muss man auch an dieser Stelle zuerst alle verbundenen AD-Snapshots mit List Mounted anzeigen lassen, ehe man ein oder alle verbundenen AD-Snapshots trennen kann.

C:\>NTDSUTIL Snapshot "List Mounted"

NTDSUTIL: Snapshot

Snapshot: List Mounted

1: 2010/05/08:14:35 {95c31025-b317-4df6-a7a5-767d0ddbc771}

2: C: {65971d9e-5608-46a9-ab92-043d73b4a6af} C:\$SNAP_201005081435_VOLUMEC$\

3: 2010/05/08:17:11 {fef7ad30-a129-466c-9a37-09f2f4e50d84}

4: C: {8fcee771-b002-46aa-a878-7e2d9519eaf3} C:\$SNAP_201005081711_VOLUMEC$\

Snapshot: Unmount 1

Die Bereitstellung des Snapshots {65971d9e-5608-46a9-ab92-043d73b4a6af} wurde au

fgehoben.

Snapshot: >

Sind mehrere AD-Snapshots verbunden, kann man alle auf einmal in der Snapshot Ebene mit Unmount * gleichzeitig trennen.

Ein AD-Snapshot mit dem Datenbankbereitstellungstool DSAMAIN bereitstellen >

Damit man auf ein AD-Snapshot mit dem man sich bereits verbunden hat zugreifen kann, muss dieser parallel zur lokalen Kopie der AD-Datenbank auf dem DC als zusätzlicher Verzeichnisdienst geladen werden. Deshalb sollte man in einer separaten Eingabeaufforderung mit dem Datenbankbereitstellungstool DSAMAIN, das verbundene AD-Snapshot das mithilfe von NTDSUTIL erstellt wurde bereitstellen. Anschließend kann man dann mit einem LDAP-Tool wie z.B. Active Directory-Benutzer und -Computer, ADSIEdit oder LDP den AD-Snapshot wie jeden anderen aktiven DC durchsuchen oder mit CSVDE bzw. LDIFDE Inhalte exportieren.

Damit das AD-Snapshot bereitgestellt werden kann, muss dieser Befehl in der Kommandozeile eingegeben werden: DSAMain -DBPath <Pfad zur NTDS.dit> -LDAPPORT <ausgewählter LDAP-Port>. Bei dem Parameter -DBPath muss der Pfad zur AD-Datenbank das sich im verbundenen AD-Snapshot befindet angegeben werden. Bei -LDAPPort muss mindestens ein Port spezifiziert werden, über den die parallele AD-Instanz zur Verfügung gestellt wird. Standardmäßig benötigt das AD vier LDAP-Ports, nämlich 389 für LDAP, 636 für LDAP über SSL/TLS, 3268 für den globalen Katalog (GC) und 3269 für den GC über SSL. Da standardmäßig diese vier Ports von dem eigentlichen produktiven AD auf einem DC benutzt werden, ist es zwingend notwendig für das Bereitstellen des AD-Snapshots einen anderen, eigens ausgewählten verfügbaren Port zu wählen. Gibt man lediglich für den erforderlichen LDAPPort den Port 30000 an, wird automatisch für LDAPS der Port 30001, für den GC 30002 und für den GC über SSL der Port 30003 reserviert.

Der Befehl zum Bereitstellen eines AD-Snapshots muss mindestens so aussehen:

DSAMain -DBPath C:\$SNAP_201005091521_VOLUMEC$\Windows\NTDS\NTDS.dit -LDAPPort 30000 >

Möchte man alle benötigten LDAP-Ports selbst spezifizieren, so lautet der Befehl wie folgt:

DSAMain -DBPath C:\$SNAP_201005091521_VOLUMEC$\Windows\NTDS\NTDS.dit -LDAPPort 30000 -sslPort 30100 -gcPort 30200 -gcSslPort 30300 >

Wenn ein AD-Snapshot bereitgestellt wurde, wird in der Ereignisanzeige unter der Serverrolle Active Directory-Domänendienste die Ereignis-ID 102 mit der Beschreibung NTDS (2924) NTDSA: Das Datenbankmodul (6.01.7600.0000) hat eine neue Instanz gestartet (0).protokolliert. Wird die Bereitstellung aufgehoben, so wird die Ereignis-ID 103 verzeichnet.

Nach durchgeführter Arbeit, kann die Bereitstellung der zusätzlichen AD-Instanz mit CTRL+C beendet werden und man sollte noch mit Unmount * das bzw. die verbundenen AD-Snapshots trennen.

Auf den AD-Snapshot zugreifen

Wenn der AD-Snapshot bereitgestellt ist, kann man ihn mit der MMC dsa.msc betrachten, in dem man zuerst auf den Eintrag Active Directory-Benutzer und -Computer [FQDN des DCs] mit einem Rechtsklick die Option Domänencontroller ändern… aufruft. Danach wählt man die Option Bestimmter Domänencontroller oder AD LDS-Instanz aus und trägt den Computernamen, FQDN oder die IP-Adresse des DCs ein, auf dem der AD-Snapshot bereitgestellt wurde. Dabei ist zu beachten: Egal welches Tool verwendet wird, es ist zwingend notwendig das man den für die zusätzliche AD-Instanz vergebenen LDAP-Port stets mit angibt!

Die MMC dsa.msc eignet sich ideal um den AD-Datenbestand zum Erstellungszeitpunkt des AD-Snapshots zu durchforsten, aber nicht um Inhalte zu exportieren um diese dann in die produktive Umgebung zu importieren.
Einen Export kann man mit Bordmittel ebenfalls durchführen, nämlich mit CSVDE und LDIFDE. Natürlich lassen sich auch durch eigene Skripte Daten exportieren. Ein Export aller Benutzer mit lediglich den gewünschten Attributen aus einer bestimmten OU, könnte mit CSVDE wie folgt aussehen:

CSVDE -S <DC> -T <vergebener LDAP-Port> -D „OU=<OU>,DC=Domäne,DC=de“ -R „(sAMAccountType=805306368)“ -L “<gewünschteAttribute>” -P Subtree -M -N -U -F „C:\ADFoto.csv“

Nach dem Export kann man die CSV-Datei zur weiteren Bearbeitung in Excel importieren. Hat man die Bearbeitung der Datendatei fertiggestellt, kann man dann mit dem folgenden Befehl den Import in der produktiven AD-Umgebung durchführen:

CSVDE -I –K -F „C:\Datendatei.csv“

Beim Import in der produktiven AD-Umgebung mit CSVDE gilt es jedoch zu beachten, dass man dieses Kommandozeilentool nicht für die Bearbeitung bestehender Objekte einsetzen kann! Zum Bearbeiten bestehender Objekte bietet sich das Kommandozeilentool LDIFDE an, dass ähnlich wie CSVDE funktioniert. Mit LDIFDE könnte man einen Export aus dem AD-Snapshot folgendermaßen gestalten:

LDIFDE -S <DC> -T <vergebener LDAP-Port> -D „OU=<OU>,DC=Domäne,DC=de“ -R „(sAMAccountType=805306368)“ -L “<gewünschteAttribute>” -P Subtree -M -N -F „C:\Export.ldf“

Auch mit diesem Befehl werden alle Benutzer aus der angegebenen OU, mit den gewünschten Attributen aus der Momentaufnahme exportiert. Hat man die gewünschten Informationen aus dem AD-Snapshot exportiert, kann man diese wie folgt in die produktive Umgebung importieren:

LDIFDE -I -K -Z -F „C:\Import.ldf“

LDIFDE - LDAP Data Interchange Format Data Exchange
Auch mit den ds*-Tools kann man auf den AD-Snapshot zugreifen. Dabei muss man lediglich den Parameter -S mit dem Wert <FQDN des DCs>:<vergebener LDAP-Port> zusätzlich zur Abfrage angeben. Eine Abfrage die alle Benutzer einer bestimmten OU anzeigt, sieht so aus:

Dsquery * "OU=<OU>,DC=Domäne,DC=de" -Filter "(sAMAccountType=805306368)" -Attr * -Server <FQDN des DCs>:30000 -Limit 0
Natürlich kann man auch mit dem State of the Art Werkzeug, nämlich der AD-PowerShell auf die Momentaufnahme zugreifen und Daten daraus exportieren. Doch bevor man mit der AD-PowerShell auf die Momentaufnahme zugreifen kann, muss wie gehabt zuerst in NTDSUTIL das AD-Snapshot verbunden und mit DSAMain bereitgestellt werden. Ist der AD-Snapshot bereitgestellt, muss man in der AD-PowerShell als nächstes ein AD-PowerShell-Laufwerk erstellen. Mit dem folgenden AD-PowerShellbefehl wird ein Laufwerk, basierend auf dem AD-Snapshot erstellt:

New-PSDrive -Name <frei wählbarer Laufwerksname> -PSProvider ActiveDirectory -Root "" -Server <DC.Domäne.de>:<vergebener LDAP-Port>

Hat man das AD-PowerShell-Laufwerk erstellt, muss man mit cd <vergebener Laufwerksname>: auf das Laufwerk wechseln.

Anschließend kann man mit cd "<DN der Domänenpartition>" zur Domänenpartition, also auf die Verzeichnispartition in der die Benutzer-, Gruppen- und Computerkonten enthalten sind wechseln.

Nun kann man sich mit den entsprechenden AD-PowerShellabfragen die gewünschten Informationen ausgeben lassen oder im Zusammenhang mit dem Cmdlet Export-CSV, einen Export der gewünschten Daten in eine CSV-Datei durchführen. Z.B. kann man alle Benutzer aus einer OU mit allen Eigenschaften wie folgt exportieren:

Get-ADUser -Filter * -Searchbase "OU=<OU>,DC=Domäne,DC=de" -Properties * | Export-Csv C:\Export.txt -NoTypeInformation

Man muss aber nicht zwangsläufig zuerst ein neues AD-PowerShell-Laufwerk erstellen! Stattdessen kann man auch, nach dem der AD-Snapshot mit DSAMain bereitgestellt wurde, alle Benutzer aus einer OU mit allen Eigenschaften wie folgt exportieren:

Get-ADUser -Filter * -Searchbase "OU=<OU>,DC=Domäne,DC=de" -Properties * -Server <FQDN des DCs>:<vergebener LDAP-Port> | Export-Csv C:\Export.txt -NoTypeInformation

Massenimporte- und -exporte mit CSVDE und der AD-PowerShell durchführen

AD-PowerShell Befehle

Nützliche Werkzeuge

Der ADExplorer

Ein hilfreiches Werkzeug im Zusammenhang mit AD-Snapshots stellt der ADExplorer dar. Mit diesem Tool ist es unter anderem zum einen möglich, AD-Snapshots auf Knopfdruck zu erstellen und zum anderen, zwei AD-Snapshots miteinander zu vergleichen. Dabei kann jedoch ein AD-Snapshot weder mit der aktuellen AD-Datenbank, noch mit mehreren AD-Snapshots gleichzeitig verglichen werden! Was das Erstellen und verwalten eines AD-Snapshots mit dem ADExplorer betrifft, gestaltet sich das mit dem Tool bemerkenswert einfacher als mit NTDSUTIL!

Zum Erstellen eines AD-Snapshots startet man den ADExplorer und trägt im Feld Connect to den DC ein mit dem eine Verbindung hergestellt werden soll. In den Feldern User und Password gibt man die entsprechenden Benutzerdaten ein. Führt man stattdessen den ADExplorer direkt auf einem DC aus, muss keins der Felder ausgefüllt werden. Dann verbindet sich der ADExplorer automatisch mit dem DC auf dem es ausgeführt wird und verwendet die Benutzerinformationen, mit dem das Tool gestartet wurde. Nach dem sich der ADExplorer mit dem DC, genauer mit der AD-Datenbank verbunden hat, klickt man entweder in der Symbolleiste auf das Diskettensymbol oder im Menü unter File auf Create Snapshot… um eine Momentaufnahme der AD-Datenbank zu erstellen. Im Feld Specify the path to the snapshot file muss der Pfad inklusive des Dateinamen angegeben werden, in dem das AD-Snapshot erstellt werden soll. Bei dem Dateinamen ist zwingend darauf zu achten, dass die Dateiendung DAT lautet. Zusätzlich kann im Feld Enter an optional description for the snapshot eine Beschreibung angegeben werden, was aber nicht zwingend ist.

Die DAT-Datei die erstellt wurde kann nun auf ein anderes System, das keine Verbindung zur produktiven Umgebung hat transportiert und von dort aus mit dem ADExplorer analysiert werden. Das ist auf der einen Seite zwar ein wesentlicher Vorteil gegenüber NTDSUTIL, hat aber auch auf der anderen Seite einen gravierenden Nachteil! Das AD-Snapshot das mit NTDSUTIL erstellt wurde benötigt die Verbindung zur produktiven Umgebung, um die Momentaufnahme rekonstruieren zu können. Somit kann das AD-Snapshot nicht einfach kopiert und irgendwohin transportiert werden. Das AD-Snapshot das mit dem ADExplorer erstellt wurde benötigt hingegen keine Verbindung zur produktiven Umgebung und befindet sich in genau einer DAT-Datei. Das stellt natürlich ein hohes Sicherheitsrisiko dar! Deshalb ist bei den AD-Snapshots die mit dem ADExplorer erstellt wurden die gleiche Sicherheit zu gewähren, wie der physikalische Zugriff auf DCs oder den Datensicherungen!

Um auf ein AD-Snapshot (die DAT-Datei) zuzugreifen, startet man den ADExplorer, wählt die Option Enter the path of a previous snapshot to load aus und trägt den Pfad zur DAT-Datei ein oder navigiert dorthin. Ist man mit dem ADExplorer bereits mit dem produktiven AD verbunden, kann man sich zusätzlich mit ein oder mehreren AD-Snapshots (nacheinander) unter File - Connect… verbinden. Das eignet sich ideal für das schnelle überprüfen von vorherigen Datenbeständen. Hat man z.B. bei ein oder mehreren Objekten in der produktiven Umgebung Werte versehentlich verändert, kann man mit dem ADExplorer nachschauen welche Werte vorher eingetragen waren, in dem man sich mit dem produktiven AD und einem AD-Snapshot verbindet.

Das Löschen eines AD-Snapshots das mit dem ADExplorer erstellt wurde gestaltet sich ebenfalls einfacher als mit der NTDSUTIL-Variante. Es muss lediglich die DAT-Datei vom Dateisystem gelöscht werden.

Möchte man zwei AD-Snapshots miteinander vergleichen, startet man den ADExplorer mit der Option Enter the path of a previous snapshot to load und gibt das Quell-AD-Snapshot an. Anschließend wählt man im Menü Compare - Compare Snapshot… und gibt im Feld Select an archive to compare to das Ziel-AD-Snapshot an. Sollen nur ausgewählte Klassen und bestimmte Felder bzw. Attribute miteinander verglichen werden, so muss man diese in den beiden unteren Bereichen auswählen.

Mit einem Klick auf Compare werden beide AD-Snapshots verglichen und wenn unterschiede vorhanden sind, werden diese angezeigt.

AD Explorer

Das Directory Service Comparison Tool (DSCT)

Ein weiteres nützliches Werkzeug, das mehr Funktionen als der ADExplorer bietet ist das DSCT. Die Beschreibung zu dem Tool sowie den Download findet man auf der folgenden Seite:

Directory Service Comparison Tool 2.0 B3

Fazit

Die AD-Snapshots sind eine hervorragende Technik, die die AD-Sicherung sowie -Wiederherstellung ergänzt. Zum Wiederherstellen von AD-Informationen muss der DC nicht erst im Modus Verzeichnisdienste wiederherstellen gestartet werden. Die Wiederherstellung kann im laufenden Betrieb, ohne Beeinträchtigung, mit der AD-Snapshot Funktion erfolgen. Auch für das Vergleichen verschiedener Datenbestände eignet sich diese Technik. Außerdem können aus einem AD-Snapshot gezielt (einzelne) Werte exportiert und in die produktive Umgebung importiert werden. Gerade ab Windows Server 2008 R2 mit dem AD-Papierkorb und der bestehenden AD-Sicherung rundet diese Technik die AD-Wiederherstellung ab! Denn mit dem aktivierten AD-Papierkorb können zwar gelöschte Objekte ohne Datenverlust wiederhergestellt werden, nicht jedoch einzelne Werte. Dazu eignet sich ein AD-Snapshot.

Weitere Informationen:
Der Active Directory-Papierkorb im Windows Server 2008 R2
Active Directory Wiederherstellung
Der Container Deleted Objects

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Zwei wichtige IDs eines DCs: DC GUID und InvocationId

Yusuf Dikmenoglu — Sun, 18 Apr 2010 12:18:07 GMT

Zwei wichtige IDs eines Domänencontrollers (DC) sind der DC GUID (Globaly Unique Identifier) und der Datenbank GUID. Beide IDs sind wichtige Bestandteile bei der AD-Replikation. Mit dem Kommandozeilenbefehl Repadmin /Showrepl <DC> kann man sich beide IDs anzeigen lassen. Gibt man den <DC> nicht an, wird der Befehl gegen den DC ausgeführt, auf dem man den Repadmin Befehl ausführt. Führt man den Befehl auf einem Windows Server 2003 DC aus, so erhält man diese Ausgabe auf dem ersten DC einer Gesamtstruktur:

Auf einem Windows Server 2008 R2 DC sieht das Ergebnis auf dem ersten DC wie folgt aus:

Jeder DC besitzt eine eindeutige DC GUID innerhalb einer Gesamtstruktur, der auch als Directory Service Agent GUID (kurz DSA-GUID) bekannt ist. Mit der DC GUID der im Attribut objectGUID gespeichert ist, wird der DC in der Gesamtstruktur identifiziert. Dabei spielt es auch keine Rolle in welcher Domäne sich der DC innerhalb einer Gesamtstruktur befindet. Der DC GUID eines DCs ist in der Gesamtstruktur einmalig und ändert sich solange der DC existiert (im Gegensatz zu der invocationId) niemals! Es sei denn, der DC wird zuerst herunter- und anschließend wieder zum DC heraufgestuft. Denn der DC GUID eines DCs wird beim heraufstufen eines Servers zu einem DC erstellt und beim herunterstufen eines DCs entfernt. Natürlich ist das manuelle bearbeiten des DC GUIDs ebenso nicht möglich, weil das Attribut objectGUID system-only ist. Das Attribut objectGUID findet man in den Eigenschaften des „NTDS Settings“ Objekts unterhalb des entsprechenden DC-Objekts in der Konfigurationspartition und ist als ein Oktett-String gespeichert. Der LDAP-Pfad zum “NTDS Settings” Objekt lautet: CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne.

Die objectGUID wird unter anderem auch dazu verwendet, um die Reihenfolge der DCs einer ringförmigen Replikationstopologie zu bestimmen und ist außerdem bei der Wahl des Bridgeheadservers eines AD-Standorts von Bedeutung. Damit der DC für seine Replikationspartner erreichbar ist, erstellt dieser mit der objectGUID in der Forward Lookup Zone _msdcs.Root-Domäne im DNS einen CNAME Eintrag.

Beim heraufstufen eines Servers zu einem DC wird der AD-Datenbank (NTDS.dit) ebenfalls eine GUID zugeordnet, die als Datenbank GUID bezeichnet wird. Diese GUID wird dazu verwendet, um die AD-Datenbank eines DCs bei einem Replikationsaufruf zu identifizieren. Bei der Datenbank GUID handelt es sich um das Attribut invocationId und befindet sich so wie die objectGUID ebenfalls in der Konfigurationspartition, in den Eigenschaften des NTDS Settings Objekts eines DCs im LDAP-Pfad: CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne. Auch die invocationId wird wie die objectGUID beim heraufstufen eines Servers zu einem DC erstellt und beim herunterstufen eines DCs entfernt. Replikationspartner nutzen die invocationId und die Update Sequence Number (USN) um die aktuellen Änderungen für die AD-Replikation zu bestimmen.

Die invocationId des ersten DCs mit dem die Gesamtstruktur erstellt wurde, hat den gleichen Wert wie die objectGUID. Bei allen weiteren DCs einer Gesamtstruktur werden unterschiedliche Werte in den beiden Attributen objectGUID und invocationId gespeichert.

Im Gegensatz zur objectGUID ändert sich die invocationId wenn:

eine neue Anwendungsverzeichnispartition erstellt wird. Oder wenn eine bestehende Anwendungsverzeichnispartition entfernt und erneut erstellt wird.
der DC mit einer gültigen Sicherung und einer unterstützten Rücksicherungsmethode (supportet von Microsoft!) rückgesichert wird. Eine gültige Sicherung ist eine Sicherung die mit einer Sicherungssoftware durchgeführt wurde, dass das entsprechende API des Betriebssystems verwendet und somit das AD in Kenntnis setzt, dass eine Sicherung durchgeführt wurde. Nur wenn eine gültige und somit eine supportete Sicherung mindestens vom System State durchgeführt wird, erspart man sich je nach Umgebung größeren Schaden im Fall einer Rücksicherung! Ab Windows Server 2003 SP1 kann man mit dem Kommandozeilenbefehl Repadmin /Showbackup überprüfen, ob eine Verzeichnispartition jemals supportet gesichert wurde.

Eine unterstützte Rücksicherung findet in Abstimmung mit der AD-Replikation statt. Denn nur wenn das AD durch eine ordnungsgemäß durchgeführte System State Sicherung und einer supporteten Rücksicherungsmethode rückgesichert wird, erhält die invocationId auf dem rückgesicherten DC einen neuen Wert. Dadurch erkennen alle anderen DCs, dass die Metadaten für die AD-Replikation zu dem rückgesicherten DC hinfällig sind und das die AD-Replikation ab dem durchgeführten Sicherungsdatum mit dem der DC rückgesichert wurde, neu aufgebaut und durchgeführt werden muss. Einige Sicherungsprogramme (bis Windows Server 2003 NTBACKUP und ab Windows Server 2008 Wbadmin, ARCServe…) führen eine ordnungsgemäße Sicherung und Rücksicherung des System States durch und darauf kommt es an!

Das entscheidende bei der Rücksicherung ist nun mal, dass die invocationId einen neuen Wert erhalten muss! Das ist genau der Nachteil bei Image-Programmen. Beim klassischen Imagen zieht man sich eine eins zu eins Kopie des DCs. Sollte es nun zum Rückspielen des Images kommen, erhält die invocationId keinen neuen Wert und somit erfahren je nach Umgebung die Replikationspartner auch nicht, dass ein DC rückgesichert wurde und das die Replikation mit dem rückgesicherten DC neu aufgebaut werden muss. Beim rücksichern eines Images schafft man sich ein USN Rollback, was je nach Fall zu einem größeren Schaden für die AD-Umgebung bedeutet! Im günstigsten Fall hätte man sich lediglich den zurück-geimageten DC zerstört. Diesen müsste man dann gewaltsam herunterstufen und anschließend die Metadaten des AD bereinigen (siehe weiterführende Informationen). Im ungünstigsten Fall hätte man mindestens doppelte RIDs verteilt, nicht mehr gültige Computerkontokennwörter und keine funktionierende AD-Replikation mit diesem DC mehr!

Wenn eine unterstützte Rücksicherung stattgefunden hat, wird der nicht mehr gültige Wert aus dem Attribut invocationId in das Attribut retiredReplDSASignatures (das sich ebenfalls im NTDS Settings Objekt eines DCs befindet) gesetzt.

Auch eine IFM (Install from Media) Installation eines DCs kommt einer Rücksicherung eines DCs gleich. Denn bei einer IFM-Installation wird der Wert aus dem Attribut invocationId das von der Sicherung stammt, in das Attribut retiredReplDSASignatures auf dem neuen DC geschrieben. Der Grund dafür ist, wenn ein Verbindungsobjekt für die Replikation erstellt wird, überprüft der neue DC sein Attribut retiredReplDSASignatures um festzustellen ob das Attribut einen Wert enthält, der mit den invocationIds im Up-To-Dateness Vector (UTDV) des Ziel-DCs übereinstimmt. Durch diese Vorgehensweise ist sichergestellt, dass nur eine Teilmenge der AD-Datenbank, nämlich nur die Änderungen die ab der Sicherung durchgeführt wurden repliziert wird.

Durch die ausschließlich ordnungsgemäß durchgeführte Sicherung und der Rücksicherungsmethode wird ein USN Rollback und somit Schaden verhindert! Wenn man sich nicht sicher ist ob das eingesetzte Sicherungsprogramm eine unterstützte Sicherung sowie Rücksicherung durchführt, sollte man ein klärendes Telefonat mit dem Hersteller führen. Von ungültigen Sicherungsmethoden wie das Rücksichern eines Images, VM-Images und VM-Snapshots (mindestens auf Servern die transaktionale Datenbanken bereitstellen wie ein DC, Exchange und SQL) sollte man stets Abstand halten und wird seitens Microsoft auch nicht supportet!

Auf einem DC ist es Pflicht mindestens das System State zu sichern und das kann man bereits mit Windows-Bordmittel (NTBACKUP, Wbadmin) durchführen!

Weiterführende Informationen:
Domänencontroller-Installation von einer Sicherung
Images als Sicherung?
Das Active Directory gewaltsam vom DC entfernen
Die Metadaten des Active Directory unter Windows Server 2008 bereinigen
Der RID-Master und sein RID-Pool
Lingering Objects (veraltete Objekte)
How to detect and recover from a USN rollback in Windows Server 2003
How To Convert a String Formatted GUID to a Hexadecimal String Form For Use When Querying the Active Directory

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Der Container Deleted Objects

Yusuf Dikmenoglu — Sat, 01 Aug 2009 21:05:05 GMT

Wenn im Active Directory (AD) Objekte gelöscht werden, verschwinden diese nicht sofort aus der AD-Datenbank (NTDS.dit). Das AD markiert das Objekt als gelöscht, indem das Attribut Is-Deleted des Objekts auf den Wert TRUE (Wahr) gesetzt wird. Dabei werden von dem Objekt die meisten Attribute für immer entfernt. Anschließend wandert das Objekt in den Container „Deleted Objects“ (der in fast allen Verzeichnispartitionen existiert) und wird ab diesem Zeitpunkt als Tombstone (zu deutsch: Grabstein) bezeichnet. Im Container Deleted Objects erhält das Tombstone einen speziellen Distinguished Name (DN), der so aussieht: „CN=<alter RDN>\0ADEL:<Object-GUID>“. Der DN des gelöschten Benutzerobjekts „Yusuf Dikmenoglu“ sieht z.B. so aus: CN=Yusuf Dikmenoglu\0ADEL:4b506a93-d721-4cbf-87dc-565939cf07af,CN=Deleted Objects,DC=blog,DC=dikmenoglu,DC=de

Das gelöschte Objekt wandert deshalb zuerst in den Container Deleted Objects, damit jeder Domänencontroller (DC) z.B. in einer weltweit verteilten Umgebung von der Löschung des Objekts in Kenntnis gesetzt wird, ehe das Objekt endgültig aus dem AD gelöscht wird. Gerade in größeren AD-Umgebungen mit einem komplexen Replikationszeitplan, ist diese Vorgehensweise für das Löschen von Objekten zwingend. Denn würde das Objekt nach dem löschen direkt aus der AD-Datenbank entfernt werden, würden die anderen DCs von dieser Löschung nichts mitbekommen und es entständen Lingering Objects (zu Deutsch: herumlungernde Objekte).

Lingering Objects (veraltete Objekte)

Das gelöschte Objekt verbleibt im Container Deleted Objects so lange, bis die Tombstone Lifetime (TSL) abgelaufen ist. Die TSL beträgt standardmäßig bei einer ursprünglich erstellten Windows 2000 sowie Windows Server 2003 Gesamtstruktur 60 Tage. Beim erstellen einer Gesamtstruktur ab Windows Server 2003 SP1 oder ab Windows Server 2003 R2 SP2 beträgt die TSL 180 Tage. Erst nach Ablauf der TSL Zeit, wird das Objekt nun endgültig vom Garbage Collection Prozess der standardmäßig alle 12 Stunden auf jedem DC läuft, aus dem AD entfernt.

Die Tombstone Lifetime

Dabei können Objekte aus der Konfigurations-, Domänen- und Anwendungsverzeichnispartition (wie z.B. ForestDNSZones und DomainDNSZones) gelöscht werden, aber nicht aus der Schemapartition! Schemaobjekte (Attribute und Klassen) können nicht entfernt werden, höchstens deaktiviert.

Ab Windows Server 2003 kann ein gelöschtes Objekt, sprich das Tombstone mit wenigen Attributen reanimiert werden. Wurde ein Objekt gelöscht, wird der DN vom Ursprungsort des Objekts im Attribut lastKnownParent eingetragen. Ein Objekt das autoritativ wiederhergestellt wurde, enthält ebenfalls im Attribut lastKnownParent den Ursprungsort. Oder wenn ein Objekt in den Container LostAndFound verschoben wird (bei einem Konflikt), der in den Verzeichnispartitionen Konfigurationspartition, Domänenpartition und Anwendungsverzeichnispartitionen wie die beiden DNS-Partitionen ForestDNSZones und DomainDNSZones existiert, wird im Attribut lastKnownParent ebenso der Ursprungsort des Konfliktobjekts eingetragen. Beim verschieben oder kopieren eines Objekts wird kein Wert im Attribut lastKnownParent eingetragen.

Wenn nun in der Domäne blog.dikmenoglu.de der Benutzer „Yusuf“ der sich in der OU „IT“ befindet gelöscht wird, enthält das Attribut lastKnownParent des gelöschten Benutzerobjekts im Container Deleted Objects der Domänenpartition den folgenden Wert:
OU=IT,DC=blog,DC=dikmenoglu,DC=de

Dadurch lassen sich wiederhergestellte Tombstones, autoritativ wiederhergestellte Objekte oder Konfliktobjekte die sich im Container LostAndFound befinden ausfindig machen, in dem man eine Abfrage nach dem Attribut lastKnownParent durchführt und dabei diesen LDAP-Filter verwendet:
(&(objectclass=*)(lastKnownParent=*))

Möchte man sich lediglich Benutzerkonten anzeigen lassen, so kann man z.B. bei einer benutzerdefinierten gespeicherten Abfrage diesen Filter verwenden:
(objectcategory=person)(lastKnownParent=*)

Den Container Deleted Object mit LDP anzeigen

Der versteckte Container Deleted Objects wird weder in der MMC Active Directory-Benutzer und -Computer, noch in ADSIEdit.msc angezeigt. Stattdessen kann man sich mit LDP.exe oder z.B. dem AD Explorer den Container Deleted Objects anzeigen lassen. Wobei der Container in den Anwendungsverzeichnispartitionen lediglich mit LDP angezeigt werden kann und nicht mit dem AD Explorer. Natürlich können aber auch andere LDAP-Browser verwendet werden.

Das LDP.exe befindet sich unter Windows 2000 und Windows Server 2003 in den Windows Support Tools und ist bereits ab Windows Server 2008 on Bord.
Unter Start - Ausführen startet man als Erstes das LDP
Danach muss man sich mit einem DC verbinden. Dazu gilt es unter Windows Server 2003 im Menüpunkt Connection die Option Connect… aufzurufen und im darauffolgenden Fenster einen DC einzutragen. Unter Windows Server 2008 heißt der Menüpunkt Remotedesktopverbindung und die Option Verbinden…
Nun gilt es unter Connection/Remotedesktopverbindung - Bind…/Gebunden… ein entsprechendes Benutzerkonto (z.B. den Domänen-Admin) anzugeben, um sich mit diesem Benutzer an das AD zu „binden“.
Anschließend muss der Distinguished Name (DN) des entsprechenden Deleted Objects Container unter View/Ansicht - Tree/Struktur angegeben werden.

Der DN des Container Deleted Objects in der Konfigurationspartition lautet:
CN=Deleted Objects,CN=Configuration,DC=Root-Domäne

In der Domänenpartition lautet der DN von Deleted Objects wie folgt:
CN=Deleted Objects,DC=blog,DC=dikmenoglu,DC=de

Der DN von Deleted Objects in den beiden DNS-Anwendungsverzeichnispartitionen lautet folgendermaßen:
CN=Deleted Objects,DC=ForestDNSZones,DC=Root-Domäne
CN=Deleted Objects,DC=DomainDNSZones,DC=Domäne,DC=de
Nach dem man sich mit dem Container Deleted Objects verbunden hat, sieht man den Eintrag zwar auf der linken Seite im LDP-Fenster, jedoch erscheinen unter dem Eintrag keine weiteren Einträge, sprich die gelöschten Objekte bzw. Tombstones kommen nicht zum Vorschein. Diese erscheinen erst, wenn unter dem Menüpunkt Options/Optionen der Menüeintrag Controls/Steuerelemente ausgewählt und das LDAP-Control Return deleted objects (1.2.840.113556.1.4.417) als aktives Steuerelement eingecheckt wurde.
Um nun ein Tombstone mit LDP zu reanimieren, müssen zwei Attribute im Tombstone verändert werden. Dazu klickt man mit rechts auf das zu wiederherstellende Objekt und wählt die Option Modify/Ändern. Danach muss zum einen der Wert im Attribut isDeleted gelöscht werden (den Wert aus FALSE zu setzen reicht nicht aus) und zum anderen, muss der DN des Objekts geändert werden. Dabei muss das Tombstone auch nicht zwingend an seinem Ursprungsort, der im Attribut lastKnownParent eingetragen ist, wiederhergestellt werden. Mit einem Klick auf Run/Ausführen wird das Tombstone dann wiederhergestellt.
In größeren AD-Umgebungen kann es im Container Deleted Objects das sich in der Domänenpartition befindet, durch die vielen gelöschten Objekte sehr unübersichtlich werden. Um sich lediglich die gelöschten Objekte eines bestimmten Zeitraums auf der rechten Seite im LDP anzeigen zu lassen, muss nach einem bestimmten Attribut in den gelöschten Objekten (den Tombstones) gesucht werden. Das Attribut in dem das Löschdatum enthalten ist lautet whenChanged.

Möchte man sich z.B. die Objekte die in den letzten 10 Tagen gelöscht wurden anzeigen, so klickt man auf der linken Seite im LDP mit rechts auf den Eintrag CN=Deleted Objects,DC=Domäne,DC=de und wählt die Option Search/Suchen. Als Filter könnte dieser eingesetzt werden: (&(objectclass=user)(whenchanged>=20090724023000.0Z)). Im Feld Attribute können die gewünschten Attribute des Tombstones angegeben werden, die ebenfalls angezeigt werden sollen. Oder es wird ein Wildcard (das Sternchen *) angegeben, um alle Attribute die im Tombstone enthalten sind anzuzeigen.
Dabei muss der Wert, sprich das Datum und die Uhrzeit im Attribut whenChanged in folgender Notation angegeben werden:
2009(Jahr) 07(Monat) 24(Tag) 02(Stunden) 30(Minuten) 00(Sekunden).0Z

Man beachte bei der Zeitangabe, dass das Attribut whenChanged nicht zwischen den DCs repliziert wird.
Das bedeutet, dass der Wert im Attribut whenChanged sich von DC zu DC unterscheidet.
Schaut man sich die LDAP-Controls im LDP unter Windows Server 2008 R2 genauer an, entdeckt man zwei neue Einträge. Die beiden neuen Einträge sind:

Mit dem LDAP-Control Return deactivated links (1.2.840.113556.1.4.2065) werden die verknüpften Attribute bei aktiviertem AD-Papierkorb eines Objekts angezeigt (z.B. das memberOf Attribut eines Benutzerobjekts). Denn wenn der AD-Papierkorb im Windows Server 2008 R2 aktiviert wurde, werden die verknüpften Attribute (Forward- und Backlink) beim Löschen eines Objekts nicht entfernt. Somit ist auch das Geheimnis des AD-Papierkorbs entlüftet, wie es mit den verknüpften Attributen umgeht.

Weitere Informationen:
Last-Known-Parent Attribute (Windows)
When-Changed Attribute (Windows)
Der Active Directory-Papierkorb im Windows Server 2008 R2
Verknüpfte Attribute
Viewing deleted objects in Active Directory
How to let non-administrators view the Active Directory deleted objects container in Windows Server 2003 and in Windows 2000 Server
Searching for Deleted Objects
>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Der Active Directory-Papierkorb im Windows Server 2008 R2

Yusuf Dikmenoglu — Sun, 01 Feb 2009 12:03:55 GMT

Das versehentliche Löschen von Active Directory-Objekten ist in Active Directory (AD) bzw. Active Directory Domain Services (AD DS), als auch in Active Directory Lightweight Directory Services (AD LDS, ehemals Active Directory Application Mode, kurz ADAM) Umgebungen mehr als ärgerlich. Denn schnell sind mit zwei Mausklicks ein oder mehrere Objekte gelöscht. Hoffentlich existiert in so einem Fall eine aktuelle und vor allem funktionierende Sicherung, mit dem das verlorene Objekt wiederhergestellt werden kann. Bis jedoch das passende Sicherungsband gefunden, eingelegt und das Objekt letztenendes wiederhergestellt ist, können diese Arbeiten sehr zeitintensiv und aufwändig sein.

Die Möglichkeiten die einem bei der Wiederherstellung zur Verfügung stehen, sind unter:

Windows 2000 = Autoritative Wiederherstellung
Windows Server 2003 = Autoritative Wiederherstellung, Tombstone reanimieren
Windows Server 2003 R2 = Autoritative Wiederherstellung, Tombstone reanimieren
Windows Server 2008 = Autoritative Wiederherstellung, Tombstone reanimieren
Windows Server 2008 R2 = AD-Papierkorb, Autoritative Wiederherstellung, Tombstone reanimieren (bei deaktiviertem und aktiviertem AD-Papierkorb)

Die autoritative Wiederherstellung

Existiert eine aktuelle und funktionierende System State-Sicherung, kann mit einer autoritativen Wiederherstellung das Objekt mit all seinen Informationen die es zum Zeitpunkt der Sicherung hatte, wiederhergestellt werden. Dabei darf die Systemstatus-Sicherung (auf englisch: System State) nicht älter als die Tombstone-Lifetime (TSL) sein, denn ansonsten entstehen Lingering Objects. Die TSL einer Gesamtstruktur gibt das maximale Alter einer Systemstatus-Sicherung an, die für eine Rücksicherung verwendet werden darf.

Ein AD-Objekt wird in der Kommandozeile mit dem Befehl Ntdsutil-authoritative restorehergestellt. Dabei wird die Versionsnummer um 100.000 erhöht, damit das rückgesicherte Objekt nach der AD-Replikation auf die Replikationspartner erhalten bleibt und nicht von einem anderen DC direkt wieder gelöscht wird.

Problematisch ist allerdings die Wiederherstellung der Gruppenmitgliedschaften eines gelöschten Benutzers, die sogenannten Backlinks. Zur Wiederherstellung von Gruppenmitgliedschaften sind weitere aufwändige Schritte notwendig. Das hat sich zwar mit Windows Server 2003 SP1 etwas entschärft, jedoch ist weiterhin der Aufwand zum Rücksichern dieser Backlinks recht hoch.

Der Nachteil einer autoritativen Wiederherstellung wäre, dass der Domänencontroller (DC) im Modus Verzeichnisdienste wiederherstellen gestartet werden muss und dadurch zwei Neustarts notwendig sind. Somit würde der DC während der ganzen Zeit der Wiederherstellung nicht zur Verfügung stehen.

Diese Vorgehensweise ist seit der Einführung des Active Directory mit Windows 2000 gleich geblieben.

Weitere Details stehen in dem Artikel:

Active Directory Wiederherstellung

Ist eine Wiederherstellung in einer AD LDS-Umgebung notwendig, so ist es erforderlich die AD LDS-Instanz vorher zu stoppen. Allerdings muss für die Wiederherstellung der Server nicht im Modus Verzeichnisdienste wiederherstellen gestartet werden.

Wiederherstellen von AD LDS-Instanzdaten

Die Tombstone-Reanimierung

Eine andere Variante die seit Windows Server 2003 zur Verfügung steht, ist das reanimieren des Tombstones (zu Deutsch: Grabstein). Diese Art der Wiederherstellung hat den Vorteil, dass das Tombstone online ohne, dass der DC neu gestartet werden muss, jederzeit wiederhergestellt werden kann. Auch in einer AD LDS-Umgebung muss dazu die AD LDS-Instanz nicht offline genommen werden. Das gelöschte Objekt (das Tombstone) kann natürlich nur reanimiert werden, solange die Tombstone Lifetime nicht abgelaufen ist. Der Nachteil dieser Variante wiederum wäre, dass beim Wiederbeleben des Tombstones nicht alle Informationen eines Objekts automatisch wiederhergestellt werden.

Denn wenn ein Objekt gelöscht wird, verschwindet es nicht sofort aus der Active Directory-Datenbank (NTDS.dit). Das Objekt wird stattdessen vom Active Directory als gelöscht markiert, indem das Attribut Is-Deleted des Objekts auf den Wert True gesetzt wird. Aber es werden die meisten Attribute von dem Objekt für immer entfernt. Danach wird das Objekt in den versteckten Container Deleted Objects (der in jeder Verzeichnispartitionen existiert) verschoben und wird ab diesem Zeitpunkt als Tombstone bezeichnet. Wird also ein Benutzer gelöscht, so landet das Benutzerkonto mit wenigen Werten im Container „Deleted Objects“ der Domänenpartition und wird erst nach Ablauf der TSL vom Garbage Collection Prozess ein für allemal aus dem AD entfernt.

Landet das Tombstone im Container „Deleted Objects“, erhält es einen speziellen Relative Distinguished Name (RDN) der so aussieht: „CN=<Alter RDN>\0ADEL:<Object-GUID>“. Beim Wiederbeleben des Tombstone wird das Objekt dann nur noch mit einigen wenigen Werten (z.B. ObjectGUID oder ObjectSID) wiederhergestellt.

Der Container „Deleted Objects“ wird aber nicht in den AD Snap-Ins oder im ADSIEdit angezeigt. Stattdessen können die Tombstones mit ADRestore.Net, ADRestore oder LDP.exe angezeigt sowie wiederhergestellt werden.

ADRestore.NET

ADRestore

Die restlichen Werte die in einem wiederhergestellten Tombstone fehlen, könnten mit einem der folgenden Tools, von einem zuvor erstellten AD-Snapshot unter Windows Server 2008 bzw. Windows Server 2008 R2 wiederhergestellt werden.

Directory Service Comparison Tool 1.3.2.X

AD Explorer

Die Grabstein-Lebenszeit (Tombstone Lifetime)

Die Tombstone Lifetime wird mit dem Installieren des allerersten DCs für die komplette Gesamtstruktur festgelegt. Dabei ist es entscheidend welches Server-Betriebssystem mit welchem Service-Pack auf dem Server installiert ist, mit dem die Gesamtstruktur erstellt wird. Das Installieren eines Service-Packs auf bestehenden DCs, verändert niemals die Tombstone Lifetime. Es müsste schon die Gesamtstruktur neu installiert werden.

Wie und wo man die TSL überprüfen kann, steht neben weiteren Details in dem folgenden Artikel.

Die Tombstone Lifetime

Die Tombstone-Lifetime beträgt unter den Betriebssystemen:

Windows 2000 (mit allen SPs) = 60 Tage
Windows Server 2003 ohne SP = 60 Tage
Windows Server 2003 ab Service Pack 1 = 180 Tage
Windows Server 2003 R2 mit Service Pack 1, installiert mit beiden R2-CDs = 60 Tage
Windows Server 2003 R2 mit Service Pack 1, installiert nur mit der ersten R2-CD = 180 Tage
Windows Server 2003 R2 ab Service Pack 2 (installiert mit der ersten oder beiden R2-CDs) = 180 Tage
Windows Server 2008 (mit allen SPs) = 180 Tage
Windows Server 2008 R2 (mit allen SPs) = 180 Tage

Der Vorgang eines gelöschten AD-Objekts sowie seine Wiederherstellung unter Windows Server 2003/2003 R2, Windows Server 2008 und Windows Server 2008 R2, bei deaktiviertem AD-Papierkorb

Der Active Directory-Papierkorb unter Windows Server 2008 R2

Ein absolutes Highlight im Windows Server 2008 R2 ist der Papierkorb für gelöschte Active Directory-Objekte. Wird ein Active Directory-Objekt in den Active Directory Domain Services (AD DS) oder Active Directory Lightweight Directory Services (AD LDS) gelöscht, kann es Dank des AD-Papierkorbs schnell wiederhergestellt werden. Der AD-Papierkorb steht in AD DS und AD LDS-Umgebungen zur Verfügung. Der große Vorteil des AD-Papierkorbs ist, dass das Objekt mit all seinen Informationen die es zum Zeitpunkt der Löschung hatte wiederhergestellt wird. Das bedeutet, alle Attribute samt allen Backlinks und somit z.B. den Gruppenmitgliedschaften eines Benutzers, werden hergestellt. Nach der Wiederherstellung ist auch der Zugriff auf die bestehenden Objekte und Ressourcen wieder gegeben.

Dafür wird weder eine System-State Sicherung benötigt, noch muss der DC im Verzeichnisdienste wiederherstellen Modus gestartet werden. Die Wiederherstellung findet im laufenden Betrieb statt.

Diese neue Technik steht ausschließlich in den folgenden Server-Versionen zur Verfügung:

Windows Server 2008 R2 Standard
Windows Server 2008 R2 Enterprise
Windows Server 2008 R2 Datacenter

Der AD-Papierkorb steht in den folgenden Versionen nicht zur Verfügung:

Windows Server 2008 R2 für Itanium basierte Systeme
Windows Web Server 2008 R2

Jedoch ersetzt diese Funktion niemals eine regelmäßige System State-Sicherung von mindestens zwei DCs pro Domäne!

Die Voraussetzungen um den Active Directory-Papierkorb unter Windows Server 2008 R2 zu nutzen

Die Voraussetzungen um den AD-Papierkorb zu nutzen sind:

Der AD-Papierkorb steht in den AD DS und AD LDS-Umgebungen erst im Gesamtstrukturfunktionsmodus Windows Server 2008 R2 zur Verfügung. Es müssen also alle Domänencontroller aus allen Domänen der Gesamtstruktur oder alle Server auf denen eine AD LDS-Instanz konfiguriert ist, unter Windows Server 2008 R2 laufen!

Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen
Der AD-Papierkorb ist standardmäßig deaktiviert, sowohl bei einer Domänenaktualisierung oder dem neu Aufsetzen einer Windows Server 2008 R2 Gesamtstruktur im Gesamtstrukturfunktionsmodus „Windows Server 2008 R2“. Der AD-Papierkorb muss stets explizit in der AD-Powershell aktiviert werden. Dieser Schritt ist ein irreversibler Vorgang und kann danach nicht mehr rückgängig gemacht werden!

Nach dem Aktivieren des AD-Papierkorbs lässt sich dieses Feature mit Bordmitteln über die AD-Powershell und LDP.exe nutzen. Es existiert keine grafische Oberfläche in der man mit der Maus die Funktion aktivieren kann. Jedoch lassen sich mit dem Tool LDP oder den beiden Tools ADRestore.Net und ADRestore, ebenfalls die gelöschten Objekte im AD-Papierkorb anzeigen sowie wiederherstellen.
Der DC der die FSMO-Rolle des Domänennamenmasters innehat muss zur Verfügung stehen, da das aktivieren des AD-Papierkorbs zwingend auf dem Domänennamenmaster durchgeführt werden muss!

Kann der AD-Papierkorb für eine einzige Domäne in der Gesamtstruktur aktiviert werden?

So wie bei der Tombstone Lifetime ist es nicht möglich, den AD-Papierkorb „pro Domäne“ zu aktivieren. Wenn die Voraussetzungen erfüllt sind, kann diese Funktion nur auf der Gesamtstrukturebene mit „Organisations-Admin“ Rechten für alle Domänen aktiviert werden. Anschließend steht jeder Domäne sein eigener AD-Papierkorb zur Verfügung. Der AD-Papierkorb existiert also "pro Domäne" und nicht "pro Gesamtstruktur"!

Die Funktionsweise des Active Directory-Papierkorbs unter Windows Server 2008 R2

Der AD-Papierkorb baut auf der Technik der Tombstone-Reanimierung auf. Jedoch werden vom gelöschten Objekt dafür keine Attribute vom System entfernt und es bleiben alle Attribute erhalten. Das Objekt wird logisch gelöscht bzw. inaktiv gesetzt, was ein neues Stadium eines gelöschten Objekts ist, das mit Windows Server 2008 R2 eingeführt wurde. In der AD-Datenbank wurde dazu das Speicherformat der Objektlinks geändert. Wird ein Objekt gelöscht, so erhält das Attribut isDeleted im Objekt den Wert TRUE. Das gelöschte Objekt wird nach wie vor in den versteckten Container Deleted Objects verschoben und sein Distinguished Name (DN) erhält dadurch einen neuen Wert. Das Objekt in „Deleted Objects“ behält seinen logischen Löschzustand solange bei, bis die Deleted Object Lifetime (DOL) abgelaufen ist. Nach Ablauf der DOL wandelt sich das gelöschte Objekt zu einem "recycled Objekt". Das recycled Objekt wird dann endgültig vom Garbage Collection Prozess nach Ablauf der Recycled Object Lifetime (ROL) aus der AD-Datenbank entfernt. Unter Windows Server 2008 R2 gibt es nun neben der Tombstone Lifetime zusätzlich die Deleted Object Lifetime (kurz DOL) und Recycled Object Lifetime (kurz ROL).

Die Deleted Object Lifetime wird durch den Wert im neuen Attribut msDS-DeletedObjectLifetime bestimmt. Denn bei einer Domänenaktualisierung auf Windows Server 2008 R2 ist eines der Schema-Aktualisierungen mit Adprep /Forestprep (von der Windows Server 2008 R2 DVD) das Hinzufügen des neuen Attributs msDS-DeletedObjectLifetime. Wenn jedoch eine Gesamtstruktur auf Basis von Windows Server 2008 R2 erstellt wird, befinden sich bereits alle benötigten Attribute im Schema und das Adprep muss in keinster Weise ausgeführt werden. Die Recycled Object Lifetime hingegen, erhält seinen Wert aus dem Attribut tombstoneLifetime.

Ist die Zeit des im Attribut msDS-DeletedObjectLifetime definierten Werts abgelaufen, wandelt sich das logisch gelöschte Objekt zum „recycled Objekt“. Zusätzlich erhält das Attribut isRecycled im Objekt den Wert TRUE. Dabei werden die gleichen Attribute vom Objekt entfernt, wie es seit Windows Server 2003 bei einem Tombstone der Fall ist. Oder anders ausgedrückt, im recycled Objekt bleiben standardmäßig die gleichen Attribute erhalten wie bei einem Tombstone unter Windows Server 2003, Windows Server 2008 oder Windows Server 2008 R2 bei deaktiviertem AD-Papierkorb. Von der Begrifflichkeit her entspricht ein „recycled Objekt“ einem klassischen Tombstone.

Eine Besonderheit gibt es jedoch mit recycled Objects! Diese lassen sich nicht wie mit einem klassischen Tombstone reanimieren. Denn die API zum reanimieren eines recycled Objects ist bei aktiviertem AD-Papierkorb deaktiviert!

Das recycled Objekt bleibt weiterhin in dem Container Deleted Objects, bis die im Attribut tombstoneLifetime definierte Zeit abläuft. Anschließend wird das Objekt vom Garbage Collection Prozess unwiderruflich aus dem AD entfernt.

Das bedeutet im Klartext, bei aktiviertem AD-Papierkorb lässt sich ein gelöschtes Objekt nur während der DOL mit allen Werten wiederherstellen. Die Möglichkeiten zum Wiederherstellen sind dabei:

Das Wiederherstellen aus dem AD-Papierkorb mit der AD-Powershell, LDP, ADRestore.NET oder ADRestore.
Eine autoritative Wiederherstellung.

Achtung: Wird der AD-Papierkorb aktiviert, wandeln sich alle AD-Objekte die bis zum Aktivieren des AD-Papierkorbs gelöscht wurden (also alle Tombstones), zu recycled Objekten. Diese Objekte können in der AD-Powershell mit einem bestimmten Befehl angezeigt werden (siehe unten). Jedoch können diese Objekte nicht mit Hilfe des AD-Papierkorbs bzw. der Tombstone-Reanimierung wiederhergestellt werden. Die beiden Tools ADRestore.NET und ADRestore zeigen ebenfalls diese Tombstones nicht an. Das Tool LDP zeigt zwar ebenfalls die Objekte an, ist aber auch nicht in der Lage die Objekte wiederherzustellen. Der einzige Weg diese Objekte herzustellen, ist eine autoritative Wiederherstellung von einer Systemstatus-Sicherung, die vor dem aktivieren des AD-Papierkorbs durchgeführt wurde.

Die Deleted Object Lifetime (DOL) und Recycled Object Lifetime (ROL)

Standardmäßig enthält das Attribut msDS-DeletedObjectLifetime keinen Wert. Es ist <Nicht festgelegt>. In diesem Fall wird der Wert aus der Recycled Object Lifetime festgelegt. Man kann aber natürlich auch jederzeit manuell einen Wert im Attribut msDS-DeletedObjectLifetime definieren.

Die ROL wiederum erhält seinen Wert aus dem Attribut tombstoneLifetime, denn die ROL hat kein eigenes Attribut wie die DOL. Das bedeutet, wenn ein Objekt gelöscht wird und im Attribut msDS-DeletedObjectLifetime ist kein Wert definiert, behält das Objekt für 60/180 Tage seinen logischen Löschzustand bei und wird anschließend zum recycled Objekt umgewandelt. Nach weiteren 60/180 Tagen (nach Ablauf der Tombstone Lifetime) wird es dann endgültig vom Garbage Collection Prozess aus der AD-Datenbank entfernt. Das Objekt bleibt somit über den gesamten Zeitraum der DOL und ROL im AD erhalten, ehe es definitiv aus dem AD gelöscht wird.

Ist hingegen im Attribut msDS-DeletedObjectLifetime ein Wert definiert, so beträgt die DOL den eingetragenen Wert in Tagen und es wird nicht der Wert aus dem Attribut tombstoneLifetime angenommen. Wenn daher der Bedarf besteht, ein gelöschtes Objekt länger als die Zeit das im Attribut tombstoneLifetime eingetragen ist aus dem AD-Papierkorb wiederherzustellen, so gilt es einen eigenen Wert im Attribut msDS-DeletedObjectLifetime zu definieren.

Enthält z.B. das Attribut tombstoneLifetime als Wert 180 und ist im Attribut msDS-DeletedObjectLifetime kein Wert eingetragen, so wird ein gelöschtes Objekt erst nach 360 Tagen vom Garbage Collection Prozess für immer aus dem AD entfernt. >

Der Vorgang eines gelöschten AD-Objekts sowie seine Wiederherstellung, bei aktiviertem AD-Papierkorb unter Windows Server 2008 R2

Die Deleted Object Lifetime (DOL) und Recycled Object Lifetime (ROL) überprüfen und bearbeiten

Das Attribut msDS-DeletedObjectLifetime befindet sich im gleichen Container wie das Attribut tombstoneLifetime, nämlich in den Eigenschaften des Containers:
CN=Directory Services,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne
Kontrollieren kann man das Attribut msDS-DeletedObjectLifetime z.B. mit Dsquery.

Der Befehl lautet:

Dsquery * "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Domäne" -attr msDS-DeletedObjectLifetime

Falls kein Wert angezeigt wird, gilt der Standardwert aus dem Attribut tombstoneLifetime von 60/180 Tagen (sofern nicht manuell geändert). Ansonsten gilt der angezeigte Wert in Tagen.
Das Attribut tombstoneLifetime lässt sich mit Dsquery folgendermaßen abfragen:
Dsquery * "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne" -attr tombstoneLifetime

Falls kein Wert angezeigt wird, gilt als Wert 60 Tage. Ansonsten gilt auch hier der angezeigte Wert in Tagen.

>
Die DOL und das Attribut tombstoneLifetime lassen sich auch mit ADSIEdit überprüfen und bearbeiten. Dazu gilt es zuerst zum folgenden Container zu navigieren:

CN=Directory Services,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne

Dort befindet sich in den Eigenschaften des Containers zum einen das Attribut msDS-DeletedObjectLifetime und zum anderen das Attribut tombstoneLifetime. Ist im Attribut msDS-DeletedObjectLifetime ein Wert gesetzt, beträgt die DOL den eingetragenen Wert in Tagen. Steht im Attribut als Wert hingegen <Nicht festgelegt>, so beträgt die DOL den Wert aus dem Attribut tombstoneLifetime. Wenn im Attribut tombstoneLifetime als Wert <Nicht festgelegt> ist, so gilt als Wert 60 Tage. Ansonsten beträgt die Zeit den eingetragenen Wert in Tagen.

>
Die DOL lässt sich auch über die AD-Powershell bearbeiten. Dazu ist die AD-Powershell explizit als Administrator aufzurufen und der folgende Befehl einzugeben:

Set-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Domäne,DC=de” –Partition “CN=Configuration,DC=Domäne,DC=de” –Replace:@{“msDS-DeletedObjectLifetime” = Wert}

Das Attribut tombstoneLifetime lässt sich im Übrigen auch auf die gleiche Weise verändern:
Set-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Domäne,DC=de” –Partition “CN=Configuration,DC=Domäne,DC=de” –Replace:@{“tombstoneLifetime” = Wert}

Aktivieren und nutzen des AD-Papierkorbs in der Active Directory-Powershell

Nach Ausführen von Dcpromo steht die Active Directore-Powershell mit 76 AD-Cmdlets auf dem DC zur Verfügung. Mit den beiden AD-Powershell Cmdlets Get-ADObject und Restore-ADObject ist es möglich, gelöschte AD-Objekte anzuzeigen sowie wiederherzustellen. Dabei ruft man mit Get-ADObject das gelöschte Objekt auf und übergibt es durch die Pipeline dem Restore-ADObject Cmdlet.

Zum Aktivieren des AD-Papierkorbs ist die folgende Vorgehensweise notwendig:

Im ersten Schritt muss mit „Organisations-Admin“ Rechten der AD-Papierkorb auf dem DC der die FSMO-Rolle des Domänennamenmasters innehat und zwar für alle Domänen in der Gesamtstruktur aktiviert werden. Der Befehl dazu lautet:

Enable-ADOptionalFeature „Recycle Bin Feature“ -Scope ForestorConfigurationset -Target “Root-Domäne*” (*DNS- oder NetBIOS-Name der Root-Domäne)

Es folgt eine Warnung die besagt, dass bei Bestätigen der Meldung dieser Vorgang irreversibel ist. Nach dem Aktivieren des AD-Papierkorbs, lässt es sich nicht mehr deaktivieren!
Wenn der AD-Papierkorb aktiviert wurde, wird im Attribut msDS-EnabledFeature das sich in den Eigenschaften des Containers "CN=Partitions,CN=Configuration,DC=Root-Domäne" befindet, als Wert "CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne" eingetragen.
Der folgende Befehl zeigt detaillierte Informationen über die zur Verfügung stehenden Optional Feature im Active Directory an:
Get-ADOptionalFeature -Filter * oder Get-ADOptionalFeature -Filter {Name -Like "*"}
Wurde ein Benutzerkonto aus Versehen gelöscht, so kann man sich das Konto wenn der sAMAccountName bekannt ist, auf diese Art anzeigen lassen:
Get-ADObject -Filter {sAMAccountname –eq „Yusuf“} -Includedeletedobjects

Wiederherstellen lässt sich das Benutzerkonto dann mit diesem Befehl:

Get-ADObject -Filter {sAMAccountname –eq „Yusuf“} –Includedeletedobjects | Restore-ADObject
Ist der „Anzeigename“ eines Benutzerkontos bekannt, so lautet die Abfrage wie folgt. Aber Vorsicht, der „Anzeigename“ ist nicht der Name, der in der MMC Active Directory-Benutzer und -Computer in der Spalte „Name“ angezeigt wird. Denn dieser Wert wiederum, wird im Attribut name gespeichert.

Get-AdObject –Filter {displayname –eq “Yusuf Dikmenoglu”} –Includedeletedobjects

Wiederherstellen lässt sich das Benutzerkonto dann so:

Get-AdObject –Filter {displayname –eq “Yusuf Dikmenoglu”} –Includedeletedobjects | Restore-ADObject
Ein bestimmtes Benutzerkonto wird auf diese Weise angezeigt:

Get-ADObject -Filter {Name -Like “*Name*”} –Includedeletedobjects

Oder so:
Get-ADOject -Filter 'Name -Like "Yusuf*"' -Searchscope Subtree -Includedeletedobjects | ft -a

Wiederherstellen kann man dann das Benutzerkonto so:
Get-ADObject -Filter {Name -Like “*Name*”} –Includedeletedobjects | Restore-ADObject

>
>>
Dieser Befehl zeigt die gelöschten Objekte im Container "Deleted Objects" an:
Get-ADObject -ldapFilter:”(msDS-LastKnownRDN=*)" -Includedeletedobjects

Wiederherstellen kann man ein Benutzerkonto auch wie folgt:
Get-ADObject -ldapFilter:"(msDS-LastKnownRDN=<Benutzer>)" -Includedeletedobjects | Restore-ADObject
Der nachfolgende Befehl zeigt die gelöschten sowie recycelten Objekte mit detailierten Informationen an, die in einer bestimmten OU waren. Mit diesem Befehl können auch die recycelten Objekte angezeigt werden, die vor dem aktivieren des AD-Papierkorbs gelöscht wurden:
Get-ADObject -Filter {Lastknownparent -eq "OU=<OU>,DC=Domäne,DC=de"} -Searchbase "CN=Deleted Objects,DC=Domäne,DC=de" -includedeletedobjects -properties *
Mit dem folgenden Befehl kann man sich alle gelöschten Objekte, egal welcher Klasse, aus dem versteckten Container „Deleted Objects“ der Domänenpartition anzeigen lassen:
Get-ADObject –Searchbase „CN=Deleted Objects,DC=Domäne,DC=de“ –LdapFilter „(objectclass=*)“ –Includedeletedobjects | Format-List

>
>>
Oder wer die Objekte jeglicher Klassen im schnellen Überblick haben möchte, verwendet diesen Befehl:
Get-ADObject –Searchbase „CN=Deleted Objects,DC=Domäne,DC=de“ –LdapFilter „(objectclass=*)“ –Includedeletedobjects
Die gelöschten AD-Objekte der Klasse „User“ (z.B. Benutzerkonten) lassen sich wie folgt anzeigen:

Get-ADObject –Searchbase „CN=Deleted Objects,DC=Domäne,DC=de“ –LdapFilter „(objectclass=User)“ –IncludedeletedObjects
Wurde ausversehen eine OU mit etlichen Benutzern gelöscht, so muss zuerst die OU wiederhergestellt werden, ehe dann die Benutzer wiederhergestellt werden können. Doch bevor die OU wiederhergestellt werden kann, wird die GUID der gelöschten OU benötigt. Diese erfährt man durch das Attribut lastknownparent eines Benutzers, das sich in der OU befand. Der Befehl würde so aussehen:
Get-ADOject -filter 'name -like "Yusuf*"' -searchscope subtree -Includedeletedobjects -properties lastknownparent

Dann kann mit diesem Befehl zuerst die OU wiederhergestellt werden:
Restore-ADObject -identity <GUID der OU>

Alle Objekte die sich in der OU befanden, können mit diesem Befehl wiederhergestellt werden:
Get-ADObject -ldapfilter "(lastknownparent=OU=<OU>,DC=Domäne,DC=TLD)" -Includedeletedobjects | Restore-ADObject>
>>>> >>>

Die AD-Powershell im Windows Server 2008 R2

Anzeigen und Wiederherstellen der gelöschten Objekte aus dem AD-Papierkorb mit ADRestore.NET und ADRestore

Das Tool ADRestore.NET muss zuerst installiert werden, lässt sich dann aber sehr simpel mit der Maus bedienen und ist vor allem selbsterklärend. Die gelöschten Objekte lassen sich mit einem Mausklick anzeigen und mit einem weiteren wiederherstellen.

ADRestore.NET
Das Kommandozeilentool ADRestore lässt sich nach dem Download ohne eine Installation in einer Kommandozeile ausführen. Auch dieses Tool ist selbsterklärend.

ADRestore
Ein weiteres kostenloses Tool ist das ADRecycleBin. Es zeigt die gelöschten Objekte an und stellt diese wieder her.

ADRecycleBin

Anzeigen und Wiederherstellen der gelöschten Objekte aus dem AD-Papierkorb mit LDP

>>>>>>

>>>> >

Die gelöschten Objekte im Container Deleted Objects lassen sich ebenfalls mit dem im Betriebssystem integrierten LDAP-Tool LDP anzeigen sowie wiederherstellen lassen.

Die Vorgehensweise wäre wie folgt:

Zuerst gilt es auf dem DC unter Start-Ausführen-LDP.exe das Tool aufzurufen.
Unter Optionen ist dann in den Steuerelementen im Feld Vordefiniert laden die Option Return deleted objects auszuwählen. Wählt man an dieser Stelle stattdessen die Option Return recycled objects aus, kann man sich bei gleicher Vorgehensweise die „recycelten Objekte“ anzeigen lassen.
Danach wählt man unter Remotedesktopverbindung den Punkt Gebunden... aus. Grandiose Bezeichnungen.
Anschließend gibt man unter Ansicht-Struktur den Distinguished Name (DN) der entsprechenden (meistens) Domänenpartition an, z.B. DC=blog,DC=dikmenoglu,DC=de
Nun erweitert man zuerst auf der linken Seite die entsprechende Verzeichnispartition und erweitert auch den Eintrag Deleted Objects mit einem Doppelklick. Jetzt erscheinen die gelöschten Objekte.
Mit einem Rechtsklick auf das wiederzuherstellende Objekt, wählt man den Punkt Ändern aus.
Unter Eingabe bearbeiten gibt man im Feld Attribut isDeleted ein.
Das Feld Werte bleibt leer.
Unter Vorgang wählt man Löschen und klickt auf Eingabe.
Jetzt müssen die gleichen Schritte mit dem Attribut distinguishedName durchgeführt werden.
Im Feld Werte ist nun der original DN des Objekts einzugeben. Daher ist es stets sinnvoll, eine Liste mit allen Objekten und deren DN zu besitzen.
Unter Vorgang wählt man Ersetzen und klickt auf Eingabe.
Nach dem aktivieren von Erweitert führt man die Wiederherstellung mit einem Klick auf Ausführen durch.

Fallbeispiele

Wenn z.B. ein Benutzer Mitglied der Gruppe1 ist, beide Objekte nacheinander gelöscht werden, aber nur das Benutzerkonto aus dem AD-Papierkorb wiederhergestellt wird, befindet sich anschließend das Benutzerkonto logischerweise nicht mehr in der Gruppe1. Wird jedoch die Gruppe1 ebenfalls aus dem AD-Papierkorb wiederhergestellt, werden automatisch Forward- und Back-Link wiederhergestellt. Das Benutzerkonto ist wieder Mitglied der Gruppe1.
Existiert eine Gruppenverschachtelung, so das also GG1 Mitglied von GG2, diese wiederum Mitglied in GG3 ist und GG2 gelöscht wird, verschwinden ebenfalls die Gruppenzugehörigkeiten. Auch hier werden beim wiederherstellen der GG2 aus dem AD-Papierkorb, die Gruppenzugehörigkeiten und somit das Forward- und Back-Link automatisch wiederhergestellt.

Weitere Informationen:

2.175 Attribute msDS-DeletedObjectLifetime
2.109 Attribute isDeleted
2.112 Attribute isRecycled
2.179 Attribute msDS-EnabledFeature
The Active Directory database garbage collection process
Useful shelf life of a system-state backup of Active Directory
Viewing deleted objects in Active Directory

>>> >>> >>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Active Directory Wiederherstellung

Yusuf Dikmenoglu — Sat, 03 Nov 2007 23:12:21 GMT

Wer kennt das nicht. Man unterhält sich während der Benutzerpflege im Active Directory mit seinen Kollegen über
das gestrige Fußball-Spiel oder hängt während dessen am Telefon und versucht an einem kniffligen Problem Hilfe zu leisten,
so das man abgelenkt ist und dabei alte Benutzerkonten entfernt. Schnell wurden zwei-Klicks im Snap-In
Active Directory-Benutzer und -Computer am falschen Benutzer-Objekt getätigt und schon wurde der falsche Benutzer gelöscht.

Das ist ärgerlich. Zumal wenn es sich auch noch um das Benutzerkonto einer wichtigen Person (des CEO vielleicht?) handelt.
Oder es wird irrtümlich ein anderes Objekt gelöscht etc.

Was passiert nun genau im Hintergrund, mit dem aus Versehen gelöschten Objekt?
Welche Änderungen am Objekt während des Löschvorgangs durchgeführt werden oder welche Attribute
im Tombstone erhalten bleiben, zeigt der folgende Artikel:
Lingering Objects (veraltete Objekte)

Doch bevor das Objekt gelöscht wird und somit in den versteckten Container Deleted Objects
(in der Verzeichnispartition, in der das Objekt gelöscht wurde) wandert, wird anhand bestimmter Kriterien geprüft ob das Objekt
tatsächlich gelöscht werden darf. Diese Kriterien wären unter anderem:

Der Benutzer der das Objekt löschen möchte hat die benötigten Rechte
Das Objekt wurde nicht bereits gelöscht und somit befindet sich das Attribut Is-Deleted des Objekts, nicht auf dem gesetzten Wert True
Das System-Flags Attribut (0x80000000) des Objekts verhindert nicht das löschen
Das Objekt enthält keine untergeordneten Objekte (ansonsten erscheint eine Fehlermeldung, siehe: Computerkonto löschen)
Das Is-Critical-System Attribut des Objekts enthält nicht den Wert True
Es handelt sich nicht um ein Schemaobjekt, wie es Attribute und Klassen darstellen. Denn diese können weder
entfernt und somit auch nicht wiederhergestellt werden. Denn wenn das möglich wäre, könnten Inkonsistenzen in der
Active Directory-Datenbank (NTDS.dit) entstehen. Unter Umständen bestehen nämlich Abhängigkeiten z.B. auf das zu löschende Attribut.
Die einzige Möglichkeit wäre, dass Attribut Is-Defunct zu nutzen, um das entsprechende Attribut bzw. die Klasse zu deaktivieren

Wird nun das Objekt gelöscht, verschwindet es nicht sofort aus der Active Directory-Datenbank (NTDS.DIT).
Das Active Directory markiert das Objekt als gelöscht, indem das Attribut Is-Deleted des Objekts auf den Wert TRUE gesetzt wird.
Dabei werden von dem Objekt die meisten Attribute auf ewig entfernt. Anschließend wandert das Objekt in den Container
Deleted Objects (der in fast allen Verzeichnispartitionen existiert) und wird ab diesem Zeitpunkt als Tombstone (zu deutsch: Grabstein) bezeichnet.
Im Container Deleted Objects erhält das Tombstone einen speziellen Relative Distinguished Name (RDN),
der so aussieht: „CN=<alter RDN>\0ADEL:<Object-GUID>“.

Das gelöschte Objekt verbleibt in dem Container so lange, bis die Tombstone Lifetime (TSL) abgelaufen ist.
Die TSL beträgt standardmäßig bei einer ursprünglich erstellten Windows 2000 sowie Windows Server 2003 Gesamtstruktur 60 Tage.
Beim erstellen einer Gesamtstruktur mit Windows Server 2003 SP1, beträgt die TSL 180 Tage. Erst nach Ablauf der TSL Zeit,
wird das Objekt nun endgültig vom Garbage Collection Prozess (der alle 12 Stunden läuft) aus dem Active Directory entfernt.

Das gelöschte Objekt wandert deshalb zuerst in den Container Deleted Objects, damit die Replikation genug Zeit hat,
diese Information des Löschens auch wirklich an alle DCs zu kommunizieren.

Welche Möglichkeiten hätte man nun, um das Objekt wiederherzustellen?

Zum einen funktioniert das natürlich durch eine autoritative Wiederherstellung und zum anderen bietet das Active Directory
unter Windows Server 2003 die Möglichkeit, den Tombstone, der also noch im Active Directory existiert, wiederzubeleben.

Für eine autoritative Wiederherstellung ist es ratsam, eine möglichst aktuelle System State-Sicherung des entsprechenden DCs
zu verwenden (Stichwort: Registry). Es darf keine System State-Sicherung die älter als die TSL ist, verwendet werden.
Was auch noch wichtig ist und von vielen Administratoren nicht beachtet wird, ist der Pfad zum Objekt,
also der sogenannte Distinguished-Name (DN). Dieser muss bekannt sein.

Der Nachteil bei dieser Variante der Wiederherstellung wäre, der Domänencontroller muss im Modus
„Verzeichnisdienste wiederherstellen“ gestartet werden und wäre somit für die Dauer der Wiederherstellung offline.
Der Vorteil wiederum wäre, dass z.B. ein Benutzer-Objekt mit den Einstellungen die es zum Zeitpunkt der Sicherung hatte,
wiederhergestellt wird (Stichwort: Object-GUID und Object-SID).

Einen Kern des Problems, stellen beim rücksichern von Benutzer- sowie Gruppen-Objekten, die Gruppenmitgliedschaften dar.
Dieses wird aber im folgenden KB-Artikel ausführlich behandelt. Insbesondere mit Windows Server 2003 SP1 hat sich dieses
Verhalten verbessert, was das wiederherstellen von Backlinks betrifft.

How to restore deleted user accounts and their group memberships in Active Directory

Um in den Modus Verzeichnisdienste wiederherstellen zu gelangen, gilt es beim Starten des DCs auf die F8-Taste zu drücken,
damit diese Auswahlmöglichkeit überhaupt erscheint. Erst in diesem Modus ist das Active Directory offline und kann gewartet werden.
Dort angelangt, muss zuerst das System State rückgesichert und anschließend mit NTDSUTIL das gewünschte Objekt
autoritativ wiederhergestellt werden. Denn erst mit anwenden von NTDSUTIL wird die Versionsnummer
des Objekts um 100.000 erhöht. Damit wird sichergestellt, dass zum einen das Objekt von keinem anderen DC erneut gelöscht
und zum anderen, dieses Objekt auf alle anderen DCs repliziert wird. Viele Administratoren machen an dieser Stelle oftmals einen Fehler,
denn sie starten nach dem rücksichern des System States direkt den DC im normalen Modus ohne mit
NTDSUTIL das Objekt autoritativ wiederherzustellen.

Es sei denn, es handelt sich um eine Domäne mit nur einem DC (was ohnehin grob fahrlässig wäre).
Denn dann gäbe es keinen anderen DC, der die Rücksicherung überschreiben würde und man bräuchte NTDSUTIL nicht anzuwenden.

Einen Tombstone wiederbeleben

Das wiederbeleben eines Tombstones hat gegenüber einem neu erstellen eines Benutzer-Objekts einen großen Vorteil.
Im Tombstone ist nämlich (unter anderem) die Object-GUID sowie Object-SID enthalten. Somit wären beim wiederbeleben
die Verweise in den ACLs der Netzwerk-Ressourcen (z.B. Freigaben etc.) weiterhin gültig und müssten nicht neu vergeben werden.
Denn beim erstellen eines Sicherheitsprinzipals (so wie es ein Benutzer-Objekt darstellt), wird auch bei der Eingabe der
gleichen Benutzerdaten wie z.B. der gleiche Benutzeranmeldename etc. eine andere Object-GUID sowie Object-SID vergeben.
Deshalb ist das neue Objekt ein „anderes“, da es sich von der GUID und SID des originalen Objekts unterscheidet.

Des Weiteren ist es auch nicht notwendig, wie bei der autoritativen Wiederherstellung, den DC offline zu schalten.
Der Nachteil bei dieser Variante wiederum wäre, dass Objekt wird mit einigen wenigen Attributen wiederhergestellt
und die fehlenden Informationen z.B. bei einem Benutzer-Objekt, müssten erneut in den Benutzereigenschaften ein gepflegt werden.
Im Active Directory Schema ist vorgegeben, welche Attribute im Tombstone erhalten bleiben. Im Tombstone werden vor allem
keine Attribute der Gruppenzugehörigkeit oder das memberOf-Attribut eines Benutzer-Objekts gespeichert. Daher ist das
wiederbeleben eines Tombstones, zum wiederherstellen der Gruppenmitgliedschaften nicht geeignet.

Tipp: Genau an dieser Stelle, setzt das Skript Werding an.

Durch das vierte Bit im Search-Flags Attribut (in Dezimal 8) allerdings, lassen sich weitere Attribute im Tombstone speichern.
Somit lässt sich im Active Directory-Schema beeinflussen, welche zusätzlichen (neben den hartcodierten) Attribute im
Tombstone erhalten bleiben. Bei der Installation eines Exchange-Servers z.B. werden zusätzliche Attribute im Tombstone gespeichert.

Damit ein Tombstone zum Leben erweckt werden kann, muss zum einen das Attribut Is-Deleted regelrecht entfernt werden
(den Wert auf FALSE setzen reicht in diesem Fall nicht aus) und zum anderen, muss das Distinguished-Name-Attribut vom
Objekt geändert werden. Erst jetzt ist es möglich, dass Objekt in einen anderen Container zu verschieben. Doch auch bevor das
durchgeführt werden kann, wird überprüft, ob die notwendigen Kriterien für zum durchführen dieser Aufgabe erfüllt werden.

Diese wären unter anderem:

Das Benutzerkonto mit dem das Objekt wiederhergestellt werden soll, muss über das Recht des Wiederbelebens eines Tombstone verfügen
Natürlich kann der Benutzer nicht sein eigenes Benutzer-Objekt wiederherstellen
Das Attribut Is-Deleted des Objekts muss auf den Wert TRUE gesetzt sein

Um einen Tombstone wiederzubeleben, lässt sich das z.B. mit ADRestore (einem Kommandozeilen-Tool aus dem Hause Microsoft)
oder LDP.exe aus den Windows Support Tools erledigen. Im Internet gibt es noch eine Menge Dritt-Anbieter Tools mit denen ein
Tombstone wiederbelebt oder das Active Directory gesichert und wiederhergestellt werden kann.

Zum speichern und wiederherstellen wichtiger Attribute, könnte auch das in Windows Server 2003 integrierte LDIFDE verwendet werden.

Als weitere Möglichkeit, kann unter Windows Server 2003 eine API verwendet werden, um einen Tombstone wiederzubeleben.
Im ersten Schritt, wird das gelöschte Objekt abgerufen und im zweiten wieder hergestellt:

Retrieving Deleted Objects (Windows)
Restoring Deleted Objects (Windows)

Beispiel:

Damit eine OU autoritativ wiederhergestellt werden kann, müssen folgende Schritte durchgeführt werden:>

Der DC muss zuerst im Modus "Verzeichnisdienste wiederherstellen" gestartet werden (F8 beim starten)
Nach der Anmeldung ist ein aktuelles System State z.B. mit NTBACKUP vom DC rückzusichern
Anschließend darf kein Neustart durchgeführt werden
In der Kommandozeile muss NTDSUTIL aufgerufen und folgende Befehle eingegeben werden:

authotitative restore
restore subtree <Distinguished Name der gelöschten OU>
Der Distinguished Name (DN) für eine OU Benutzer direkt unter der Domäne intra.dikmenoglu.de würde so aus:
OU=Benutzer,DC=intra,DC=dikmenoglu,DC=de
Zu guter Letzt ist durch Eingabe von „quit“ (insgesamt zweimal) das NTDSUTIL und mit „exit“ die Kommandozeile zu verlassen.

Nach einem Neustart ist die OU erneut im Active Directory verfügbar.

Für eine autoritative Wiederherstellung eines Benutzer-Objekts, muss anstatt „restore subtree DN“,
dass Kommando „restore object DN“ verwendet werden.

Weitere Informationen:
Wie stelle ich das AD wieder her?
Notfallwiederherstellung: Active Directory-Benutzer und -Gruppen
Useful shelf life of a system-state backup of Active Directory
How To Use the Backup Program to Back Up and Restore the System State in Windows 2000
How to perform an authoritative restore to a domain controller in Windows 2000
How to Recover from a Deleted Domain Controller Machine Account in Windows 2000
How to perform a disaster recovery restoration of Active Directory on a computer with a different hardware configuration
Das Geheimnis der Tombstone Lifetime
The effects on trusts and computer accounts when you authoritatively restore Active Directory
HOW TO: Back Up the System State Data of a Remote Computer in Windows 2000

>>>>>>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Images als Sicherung?

Yusuf Dikmenoglu — Fri, 11 Aug 2006 14:21:06 GMT

Sichern mit Images ist bei vielen sehr gern gesehen, da man sich damit "scheinbar" gegen einen Crash schützen kann (oder vor einer Änderung).

Was bei einem Client evtl. noch zutrifft, trifft bei einem DC, Exchange oder SQL ... etc. schon gar nicht zu.

Daher mein Appell an alle:

Bitte lasst die Finger von Images auf DCs und Systemen die mit transaktionalen Datenbanken arbeiten.

Warum kann man DCs nicht imagen?

Weil es sich bei der Active Directory-Datenbank um ein verteiltes Datenbanksystem handelt!

Nur bei einer Onlinesicherung, kann die Konsistenz der Datenbanken geprüft werden. Mit Images
sichert man womöglich wochenlang eine defekte Datenbank mit und steht im Disasterfall dann ohne Backup da.

Würde man diese aber online sichern, so würde das System die Inkonsistenz im Form einer Warnung/Fehlermeldung melden.

Was wäre zum Beispiel, wenn auf der Festplatte ein Bad Sector/Block existieren würde?

Eine Exchange oder SQL Datenbank kann ziemlich groß werden, daher ist es möglich, dass der Bad Block damit die Datenbank inkonsistent werden lässt.

Was bei einem Offline-Image nicht auffällt, würde stattdessen bei einer Online-Sicherung sehr wohl auffallen.

Windows bemerkt aufgrund der Differenz zwischen den während der Sicherung kalkulierten Prüfsummen und den beim ursprünglichen Schreiben kalkulierten Prüfsummen, daß hier ein Datenverlust seit der letzten erfolgreichen Onlinesicherung eingetreten ist.

Wird das Image online erstellt, dramatisiert sich das ganze noch mehr.

Was ist zum Beispiel, wenn eine Datei sich über Eintausend Sektoren verteilt und das Imaging-Programm sichert von Sektor 1 bis 1000.

Es ist gerade bei Sektor 250, da wird die Datei erneut im laufenden Betrieb beschrieben.

Das Imaging-Programm bekommt davon nichts mit. Somit wird dann Sektor 1-250 von der alten Version und 251 bis 1000 von der neuen Version ins Image geschrieben.

Dann kommt noch der Aspekt der Computerkontokennwörter hinzu.

Denn unter Windows NT wird standardmäßig das Computerkontokennwort alle 7 Tage und unter Windows 2000/XP/Vista alle 30 Tage geändert.
Wird nun ein älteres Image zurückgesichert, können sich die Clients nicht mehr an der Domäne anmelden. Denn bei der Erstellung

des Server-Images werden natürlich auch die Computerkontokennwörter mit gesichert.

Hier ist ein schöner Artikel, den sich jeder mal zu Herzen nehmen sollte (Stichwort: USN-Rollback):

Warum Images nicht als Datensicherung taugen

Dieser sollte auch nicht fehlen:

http://www.msexchangefaq.de/verschiedenes/imagebackup.htm

Ein USN-Rollback unter Windows 2000

Ein USN-Rollback unter Windows 2003

Weitere Informationen:
Zwei wichtige IDs eines DCs: DC GUID und InvocationId

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Einen Server mit rücksichern des System State zum DC stufen

Yusuf Dikmenoglu — Sat, 15 Jul 2006 16:29:50 GMT

Das sichern des System State (Systemstatus) ist das mindeste,
was ein Administrator auf seinen Domänencontrollern sichern sollte, wenn nicht sogar "muss".

Denn dadurch kann man z.B. bei einem Servercrash in einer Domäne, in dem bloß ein einziger Domänencontroller existiert,
sich die „Domäne“ samt Active Directory rücksichern und braucht somit nicht erneut jeden User einzeln anlegen oder die Computer
aus der „alten“ Domäne zu entfernen und in die neue einzubinden. Alleine wegen der Ausfallsicherheit ist es empfehlenswert,
in jeder Domäne min. zwei DCs zu installieren. Der zweite DC könnte auch (wegen finanziellen Engpässen) auf eine
„ältere“ Client-Maschine installiert werden.

Weitere Informationen erhalten Sie unter: Wie stelle ich das AD wieder her?

Neben der Sicherung des System States, sollte natürlich ein Disaster-Recovery, Backup Konzept und ein Notfallplan
existieren und vor allem auch regelmäßig an die aktuellen Gegebenheiten angepasst werden.

http://www.microsoft.com/technet/community/events/windows2003srv/tnt1-94.mspx

Für Exchange:

http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/disrecopgde.mspx

Mit sichern des System States werden folgende Dateien gesichert:

- Die Active Directory Datenbank – NTDS.DIT
- SYSVOL
- Systemstart Dateien
- Registry
- COM+

Falls eine CA installiert wäre, dann auch diese.
Man sollte und muss auf das Alter des System States beim rücksichern achten, genauer auf das Alter des Attributs „TombstoneLifetime”.
Die Sicherung des Systemstatus darf nicht älter als der eingestellte Wert sein.

Den eingestellten Wert der „TombstoneLifetime“ kann man sich mit ADSIEdit
(aus den Windows Support Tools) im folgenden Pfad anschauen:
CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne,DC=TLD

Dort findet man in den Eigenschaften des Containers CN=Directory Service das Attribut tombstoneLifetime.
Ist dort ein Wert gesetzt, beträgt die Tombstone Lifetime (TSL) den eingetragenen Wert in Tagen.
Steht im Attribut als Wert hingegen <Not Set>, so beträgt die TSL den Standardwert von 60 Tagen.

Die TSL wird mit dem installieren des allerersten DCs in einer Gesamtstruktur und zwar für alle
Domänen festgelegt. Dieser Wert kann nicht pro Domäne konfiguriert werden. Er lässt sich aber manuell verändern. >

Die TSL beträgt unter:

- Windows 2000 (mit allen SPs) = 60 Tage

- Windows Server 2003 ohne SP = 60 Tage

- Windows Server 2003 mit Service Pack 1 = 180 Tage

- Windows Server 2003 R2 (mit SP1) = 60 Tage

- Windows Server 2003 mit Service Pack 2 = 180 Tage

- Windows Server 2003 R2 ab Service Pack 2 = 180 Tage

- Windows Server 2008 = 180 Tage
- Windows Server 2008 R2 = 180 Tage

Siehe folgenden Artikel: Das Geheimnis der Tombstone Lifetime >

Angenommen man hätte einen Festplatten - Crash in einem Domänencontroller der der einzigste DC der Domäne wäre,
dann gilt es den Server zu reparieren, in Form von Festplatten tauschen und anschließend neu installieren des Betriebssystems
„Windows Server 2003 R2“. Dabei spielt es keine Rolle welchen Computernamen sowie IP - Einstellungen man dem Server vergibt,
denn nach dem rücksichern des System State, bekommt der Server die Daten, die er beim sichern des System State hatte.
Nach dem installieren des Betriebssystems gilt es danach das Betriebssystemeigene Sicherungsprogramm „NTBACKUP“
über „Start - Ausführen - Ntbackup“ zu starten und eine Rücksicherung des System States zu starten (ausgegangen davon,
dass man das SYSTEM STATE über das NTBACKUP sichert). Dabei ist es auch egal auf was gesichert
wurde und welchen Laufwerksbuchstaben das Sicherungslaufwerk hatte.

Nach dem rücksichern und anschließendem neu starten des Servers fehlen die Active Directory - Snap - Ins
wie z.B. Active Directory Benutzer- und Computer oder „Standorte und Dienste“ etc. unter „Start - Programme - Verwaltung“.
Nun könnte man mit „Start - Ausführen - dsa.msc“ (für AD- Benutzer- und Computer) oder dssite.msc (für AD-Standorte- und Dienste)
die Snap - Ins aufrufen. Eine andere Alternative wäre, dass man sich selbst eine MMC erstellt und diese
ganzen Snap-Ins dort hinzufügt und speichert. Wer das alles nicht will und den gewohnten „Standard“ haben möchte,
sprich, die ganzen Snap-Ins unter „Start - Programme - Verwaltung“ haben möchte, der installiert sich das „Adminpack.msi“
aus %systemroot\system32\ und bekommt anschließend das gewohnte Bild unter „Start - Programme -Verwaltung“.

Zum Schluss müsste noch das DNS sowie DHCP installiert und konfiguriert werden.

Es gibt auch eine Möglichkeit, dass DCPROMO mit dem Schalter „/ADV“ auszuführen. Das wäre für den Fall ideal,
wenn man z.B. einen weiteren Server zum Domänencontroller promoten möchte, dieser aber an einem Standort mit einer
geringen Anbindung steht. Damit eben nicht die komplette Active Directory - Datenbank repliziert werden muss, sichert
man an einem bestehenden DC der Domäne, zu der der neue Server als weiterer DC heraufgestuft wird, dass System State
und kopiert dieses auf eine externe Fesplatte oder CD/DVD. Damit stuft man dann den neuen Server zum DC und anschließend
muss dann nur noch die Änderung seit der erstellten System State Sicherung repliziert werden.

Weitere Inforamtionen:
Domänencontroller-Installation von einer Sicherung
Install from Media

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.