Windows-Verwaltung
Notfallwiederherstellung: Active Directory-Benutzer und -Gruppen
Gil Kirkpatrick
Kurz zusammengefasst:
- Funktionsweise der Replikation und Objektverknüpfung
- Verwenden von NTDSUTIL zum Sichern und Wiederherstellen
- Autorisierende und nicht autorisierende Wiederherstellungen
Active Directory ist einer der wichtigsten Dienste in einem Windows-Netzwerk. Um Ausfälle und Produktivitätsverluste zu vermeiden, benötigen Sie effektive Notfallwiederherstellungspläne für Probleme, die mit Active Directory auftreten können. Dies scheint ganz offensichtlich zu sein, allerdings ist es
erstaunlich, wie viele Administratoren nicht über einen Plan für eines der am häufigsten vorkommenden Fehlerszenarien bei Active Directory® verfügen: das versehentliche Löschen von Daten.
Das versehentliche Löschen von Objekten ist eine der Hauptursachen für den Ausfall von Diensten. Ich frage bei Seminaren und Konferenzen oft, wer schon einmal einen Active Directory-Fehler aufgrund eines versehentlichen Löschens von Daten hatte. Immer wieder ist das bei fast allen Anwesenden der Fall.
Um zu verstehen, warum die Datenwiederherstellung so komplex ist, müssen Sie zunächst Folgendes wissen: Wie werden Objekte in Active Directory gespeichert, repliziert und gelöscht, und wie funktionieren autorisierende und nicht autorisierende Wiederherstellungen?
Speichern von Objekten
Active Directory ist eine spezialisierte Objektdatenbank, die das Datenmodell X.500/LDAP implementiert. Der Datenspeicher (Directory Information Tree, DIT) basiert auf der Extensible Storage Engine (ESE), einem ISAM (Indexed Sequential Access Method)-Datenbankmodul. Active Directory speichert die DIT-Datenbank in zwei Tabellen: In der Datentabelle (die die Active Directory-Objekte und -Attribute enthält) und in der Verknüpfungstabelle (die die Beziehungen zwischen Objekten enthält).
Jedes Active Directory-Objekt wird in einer einzelnen Zeile in der Datentabelle mit einer Spalte pro Attribut gespeichert. Die Datentabelle enthält alle Einträge für alle auf dem Domänencontroller (DC) gespeicherten Replikate. Bei einem regulären DC enthält die Datentabelle Einträge zum Domänennamenskontext, Konfigurationsnamenskontext und zum Schemanamenskontext. Bei einem normalen Katalog enthält die Datentabelle Einträge für jedes Objekt in der Gesamtstruktur.
Active Directory verwendet das Distinguished Name Tag (DNT), eine 32-Bit-Ganzzahl, um jede Zeile in der Datentabelle eindeutig zu identifizieren. Das DNT wird zum internen Verweis auf Objekte verwendet und ist viel kleiner als andere Bezeichner wie z. B. Distinguished Name (DN) oder objectGUID (eine 16-Byte-Binärstruktur). Aber im Unterschied zur objectGUID ist das DNT eine lokale Kennung, die bei jedem DC anders ist.
So verknüpft Active Directory Objekte
Active Directory verwaltet zwei Arten von Beziehungen zwischen Objekten in der DIT-Datenbank: Die Beziehung zwischen über- und untergeordneten Elementen (auch als Containerbeziehung bezeichnet) und die Verweisbeziehung (auch als Verknüpfungsbeziehung bezeichnet). Zur Implementierung der Beziehung zwischen über- und untergeordneten Elementen speichert Active Directory eine zusätzliche Spalte in der Datentabelle, die als Parent Distinguished Name Tag oder PDNT bezeichnet wird. Diese Spalte enthält immer das DNT des dem Objekt übergeordneten Elements.
Jedes Attribut in Active Directory wird von einem attributeSchema-Objekt im Schemacontainer von Active Directory definiert. Bestimmte Attribute in Active Directory werden als Verknüpfungsattribute definiert. Sie werden durch einen geraden Wert ungleich Null im linkID-Attribut des attributeSchema-Objekts bestimmt. Durch Verknüpfungsattribute wird eine Beziehung zwischen Objekten im Verzeichnis eingerichtet. Sie können einen oder mehrere Werte haben. Das Mitgliedsattribut eines Gruppenobjekts ist ein Beispiel für ein Verknüpfungsattribut mit mehreren Werten – es stellt eine Verknüpfung zwischen dem Gruppenobjekt und seinen Mitgliedsobjekten her.
Das Mitgliedsattribut einer Gruppe scheint zwar die DNs der Mitglieder zu enthalten (wie beispielsweise im Active Directory-Benutzer- und -Computer-Snap-In aufgeführt), aber in Wirklichkeit werden die DNs von Active Directory anders gespeichert. Wenn Sie den DN eines Mitgliedsobjekts dem Mitgliedsattribut einer Gruppe hinzufügen, speichert Active Directory das DNT des Objekts, nicht den DN. Da sich das DNT selbst bei Neubenennung eines Objekts nicht ändert, können Sie ein Benutzerobjekt umbenennen, ohne dass Active Directory alle Gruppen im System durchsuchen muss, um den DN in jedem der Mitgliedsattribute zu aktualisieren. Auf diese Weise behält Active Directory die referenzielle Integrität innerhalb der DIT bei. Abbildung 1 enthält eine stark vereinfachte Darstellung der Beziehungen zwischen der Datentabelle und der Verknüpfungstabelle. Diese Tabellen zeigen, dass die drei Benutzerobjekte – Molly Clark, Alexander Tumanov und Makoto Yamagishi – alle Mitglieder der Gruppe Senior Engineers sind.
Figure 1 Beziehungen zwischen Daten und Verknüpfungstabellen
| Datentabelle | |||
| DNT | PDNT | Objektklasse | Cn |
| 14529 | 14401 | Organisationseinheit | Engineers |
| 14530 | 14529 | Gruppe | Senior Engineers |
| 14531 | 14529 | Benutzer | Molly Clark |
| 14532 | 14529 | Benutzer | Alexander Tumanov |
| 14533 | 14529 | Benutzer | Makoto Yamagishi |
| Verknüpfungstabelle | |||
| Attribut | DNT | Forwardlink | |
| Mitglied | 14530 | 14531 | |
| Mitglied | 14530 | 14532 | |
| Mitglied | 14530 | 14533 |
Diese Verknüpfungen werden als Forwardlinks bezeichnet. Dementsprechend stellt Active Directory auch Backwardlink-Attribute zur Verfügung. Die Backwardlink-Attribute liefern einen Bezug vom verknüpften Objekt zurück zu dem damit verbundenen Objekt, also zu dem Objekt mit dem Forwardlink. Das memberOf-Attribut für Benutzer und Gruppen ist ein Beispiel für ein Backwardlink-Attribut. Das attributeSchema-Objekt, das ein Backwardlink-Attribut beschreibt, hat einen linkID-Wert, der um 1 größer ist als der geradzahlige linkID-Wert des dazugehörigen Forwardlink-Attributs. Beispiel: Das Mitgliedsattribut im Windows Server® 2003 R2-Schema hat den linkID-Wert 2, das memberOf-Attribut, das als Backwardlink fungiert, hat dann den Wert 3. In Abbildung 2 finden Sie zur weiteren Information eine Liste der verlinkten Attribute, die standardmäßig im Windows Server 2003 R2-Schema definiert sind.
Figure 2 Verknüpfungsattribute im Windows Server 2003 R2-Schema
| Forwardlink-Attribut | linkID | Backwardlink-Attribut | Verknüpftes |
| Mitglied | 2 | memberOf | 3 |
| manager | 42 | directReports | 43 |
| owner | 44 | ownerBL | 45 |
| siteObject | 46 | siteObjectBL | 47 |
| nonSecurityMember | 50 | nonSecurityMemberBL | 51 |
| queryPolicyObject | 68 | queryPolicyBL | 69 |
| privilegeHolder | 70 | isPrivilegeHolder | 71 |
| managedBy | 72 | managedObjects | 73 |
| hasPartialReplicaNCs | 74 | ||
| hasMasterNCs | 76 | masteredBy | 77 |
| syncMembership | 78 | ||
| serverReference | 94 | serverReferenceBL | 95 |
| bridgeheadTransportList | 98 | bridgeheadServerListBL | 99 |
| netbootServer | 100 | netbootSCPBL | 101 |
| frsComputerReference | 102 | frsComputerReferenceBL | 103 |
| fRSMemberReference | 104 | fRSMemberReferenceBL | 105 |
| fRSPrimaryMember | 106 | ||
| siteLinkList | 142 | ||
| siteList | 144 | ||
| msCOM-PartitionLink | 1040 | msCOM-PartitionSetLink | 1041 |
| msDS-NC-Replica-Locations | 1044 | ||
| msFRS-Hub-Member | 1046 | ||
| msCOM-UserPartitionSetLink | 1048 | msCOM-UserLink | 1049 |
| msDS-SDReferenceDomain | 2000 | ||
| msDS-HasInstantiatedNCs | 2002 | ||
| msDS-NonMembers | 2014 | msDS-NonMembersBL | 2015 |
| msDS-MembersForAzRole | 2016 | msDS-MembersForAzRoleBL | 2017 |
| msDS-OperationsForAzTask | 2018 | msDS-OperationsForAzTaskBL | 2019 |
| msDS-TasksForAzTask | 2020 | msDS-TasksForAzTaskBL | 2021 |
| msDS-OperationsForAzRole | 2022 | msDS-OperationsForAzRoleBL | 2023 |
| msDS-TasksForAzRole | 2024 | msDS-TasksForAzRoleBL | 2025 |
| msDS-HasDomainNCs | 2026 | ||
| msSFU30PosixMember | 2030 | msSFU30PosixMemberOf | 2031 |
| msDS-hasMasterNCs | 2036 | msDs-masteredBy | 2037 |
| msDS-ObjectReference | 2038 | msDS-ObjectReferenceBL | 2039 |
| msDFSR-ComputerReference | 2050 | msDFSR-ComputerReferenceBL | 2051 |
| msDFSR-MemberReference | 2052 | msDFSR-MemberReferenceBL | 2053 |
Backwardlink-Attribute haben immer mehrere Werte und werden automatisch von Active Directory verwaltet. Sie können ein Backwardlink-Attribut nicht direkt ändern. Zwar scheint es, als könnten Sie das memberOf-Attribut eines Benutzers oder einer Gruppe über das MMC-Snap-In des Active Directory-Benutzers und -Computers ändern, allerdings ändert das Snap-In nur das Mitgliedsattribut der entsprechenden Gruppe, und Active Directory aktualisiert das memberOf-Attribut im Hintergrund. Darum benötigen Sie keine Berechtigungen für das Benutzerobjekt, um den Benutzer zu einer Gruppe hinzuzufügen. Sie ändern eigentlich nur das Mitgliedsattribut des Gruppenobjekts. Da jeder DC seine Backwardlink-Attribute lokal verwaltet, werden Änderungen an Backwardlinks nie repliziert. Nur die Änderung am Forwardlink-Attribut, z. B. dem Mitgliedsattribut einer Gruppe, werden repliziert.
Auf einem normalen DC enthält die Datentabelle Einträge für Domänenobjekte und für Objekte aus den Konfigurations- und Schemacontainern. Einige Gruppentypen können jedoch Bezüge auf Objekte enthalten, die sich in einer anderen Domäne befinden. Wie speichert Active Directory ein DNT für ein Objekt, das sich nicht in seiner Datentabelle befindet? Die Antwort liegt beim Besitzer der Rolle Infrastrukturmaster FSMO (Flexible Single Master Operations) und bei einem so genannten Phantomobjekt.
Phantomobjekte
Wenn Sie ein Mitglied einer Domäne einer Gruppe in einer anderen Domäne hinzufügen, erstellt Active Directory automatisch ein spezielles Objekt in der Datentabelle, das als Phantom bezeichnet wird. Dieses Phantom enthält die objectGUID, objectSid, und den DN des neuen Mitglieds. Dadurch wird ein DNT bereitgestellt, das im Mitgliedsattribut der Gruppe gespeichert werden kann. Wenn es sich bei einem Domänencontroller um einen globalen Katalog handelt, muss kein Phantom erstellt werden, da sich bereits ein Eintrag in der Datentabelle für jedes Objekt in der Gesamtstruktur befindet.
Der DC mit der Rolle Infrastruktur FSMO vergleicht die Einträge in seiner Datentabelle regelmäßig mit einem globalen Katalog. Wenn er feststellt, dass ein Objekt verschoben, umbenannt oder gelöscht wurde, aktualisiert er die Phantome in der Datentabelle und repliziert die Änderung für die anderen DCs in der Domäne. In Folge einer Verweiszählung kann der Infrastrukturmaster auch Phantome entfernen, auf die sich keine Forwardlink-Attribute in der Domäne mehr beziehen.
Mit Phantomen können DCs Verweise auf Objekte in anderen Domänen innerhalb der Gesamtstruktur verwalten. Allerdings können Forwardlink-Attribute auch auf Objekte verweisen, die sich außerhalb der Gesamtstruktur befinden – z. B. in einer vertrauenswürdigen Domäne. In diesem Fall erstellt Active Directory im CN=ForeignSecurityPrincipals-Container im Domänennamenskontext ein Objekt, das als Foreign Security Principal (FSP) bezeichnet wird. Der FSP enthält die Sicherheits-ID (SID) und weitere Attribute, die das Objekt in der fremden Domäne identifizieren. Es gibt jedoch keinen Prozess, der sicherstellt, dass der FSP aktuell bleibt. Zur Datenwiederherstellung werden FSPs wie jedes andere Active Directory-Objekt behandelt.
Löschen von Objekten
An dieser Stelle befasse ich mich hauptsächlich mit der Wiederherstellung von Benutzern und ihren Gruppenmitgliedschaften. Allerdings gelten dieselben Prinzipien für die Wiederherstellung anderer verknüpfter Attribute.
Wenn Active Directory ein Objekt löscht, löscht es das Objekt nicht physisch aus der DIT. Stattdessen wird das Objekt als gelöscht markiert, indem das isDeleted-Attribut auf True (Wahr) gesetzt wird. Dadurch wird das Objekt für normale Verzeichnisvorgänge unsichtbar. Active Directory entfernt alle Attribute, die nach Definition im Schema nicht gespeichert werden sollen, und ändert den Relative Distinguished Name (RDN) des Objekts auf <alter RDN>\0aDEL:<objectGUID>. Danach wird das Objekt in den CN=Deleted Objects-Container für das Namenskonzept verschoben. (Es gibt einige Objektklassen im Konfigurationsnamenskontext, die Active Directory nicht in den Container für gelöschte Objekte verschiebt.) Active Directory entfernt alle Forwardlinks des gelöschten Objekts auf andere Objekte. Dadurch wird die Verweisanzahl in der Verknüpfungstabelle reduziert. Wenn es andere Objekte gibt, die Forwardlinks auf das gelöschte Objekt enthalten, entfernt Active Directory diese Verknüpfungen ebenfalls.
Das entstehende Objekt wird als Tombstone (Grabstein) bezeichnet. Active Directory repliziert diesen Tombstone für andere DCs, bei denen dieselben Änderungen durchgeführt werden. Beachten Sie, dass Active Directory nicht die Änderungen an Forwardlinks repliziert, die auf das gelöschte Objekt verweisen. Jeder DC führt die entsprechende Änderung lokal aus, sodass das Replizieren nicht notwendig ist. Dies wirkt sich auf das Wiederherstellen von Gruppenmitgliedschaften aus, worauf ich später in diesem Artikel noch eingehen werde.
Active Directory behält Tombstone-Objekte in der DIT wie durch das tombstoneLifetime-Attribut des CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<Stammdomänen>-Objekt festgelegt. Durch den Sammlungsprozess für veraltete Objekte auf jedem DC werden Tombstones entfernt, die älter als die konfigurierte Gültigkeitsdauer für Tombstones sind. Standardmäßig liegt die Gültigkeitsdauer für Tombstones bei Windows® 2000, Windows Server 2003 und Windows Server 2003 R2 bei 60 Tagen. Bei Windows Server 2003 SP1 liegt sie bei 180 Tagen.
Die Gültigkeitsdauer von Tombstones hat bedeutende Auswirkungen auf den Wiederherstellungsprozess. Sie können mit einer Sicherung, die älter als die Gültigkeitsdauer der Tombstones ist, keine Wiederherstellung durchführen. Da es für Objekte, die von der Domäne gelöscht und gesammelt wurden, keine Tombstones mehr gibt, kann der Löschvorgang für den wiederhergestellten DC nicht nochmals repliziert werden. Die gelöschten Objekte verbleiben als veraltete Objekte auf dem wiederhergestellten DC, weshalb keine ordnungsgemäße Abstimmung mit anderen DCs in der Domäne durchgeführt werden kann.
Replizieren von Objekten
Wenn ein Domänencontroller eine Aktualisierung durchführt – z. B. ein Objekt hinzufügt oder ein Attribut ändert – weist der DC dem Aktualisierungsvorgang eine eindeutige 64-Bit-Nummer zu. Diese Nummer wird als Update Sequence Number (USN) bezeichnet. Active Directory kennzeichnet die aktualisierten Objekte und Attribute mit der USN, um festzustellen, ob sie repliziert werden müssen.
Active Directory repliziert Objekte Attribut für Attribut. Wenn Sie also das Attribut eines Objekts ändern, repliziert Active Directory nur dieses Attribut, und nicht das ganze Objekt. Hierfür verfolgt Active Directory die Änderungen, die es an jedem Attribut vornimmt, mithilfe von Replikationsmetadaten zurück. Die Replikationsmetadaten für ein Attribut umfassen:
- Die lokale USN, die den Änderungsvorgang auf dem lokalen DC identifiziert.
- Die Aufrufkennung des DC, der die Änderung vorgenommen hat (speziell das invocationID-Attribut des entsprechenden nTDSSettings-Objekts des DC). Diese Kennung identifiziert eine bestimmte Generierung der DIT auf einem Domänencontroller.
- Die USN des ursprünglichen Vorgangs, die auf dem Ursprungs-DC vorhanden ist.
- Ein Zeitstempel, der die Systemzeit des DC für den Zeitpunkt enthält, an dem die ursprüngliche Änderung durchgeführt wurde.
- Eine sequenzielle Versionsnummer mit 32 Bit, die bei jeder Änderung des Werts erhöht wird.
Wenn ein Ziel-DC Änderungen von seinem Quell-DC-Partner anfordert, sendet er die USN der letzten erfolgreich replizierten Änderung zusammen mit einem Aktualitätsvektor an die Quell-DC. Der Aktualitätsvektor enthält die größte Ursprungs-USN, die dem Ziel-DC von jedem DC vorliegt, der ein Replikat des replizierten Namenskontexts enthält. Der Quell-DC verwendet diese Information, um nur die Aktualisierungen zu senden, die dem Ziel-DC noch nicht vorliegen.
Während der Ziel-DC die eingehenden Attributsaktualisierungen verarbeitet, prüft er die Versionsnummer jedes Attributs. Wenn die Versionsnummer eines eingehenden Attributs größer ist als die Version, die dem DC für dieses Attribut bereits vorliegt, speichert der DC den eingehenden Wert. Wenn die eingehende Versionsnummer mit der Version übereinstimmt, die dem DC bereits vorliegt, vergleicht der DC die Zeitstempel und verwendet das Attribut mit dem aktuellen Stempel. Wenn die Zeitstempel gleich sind, wählt der Ziel-DC den Wert mit der größten Aufrufkennung. Dadurch wird sichergestellt, dass alle DCs nach und nach denselben Wert für jedes replizierte Attribut haben.
Replizieren von verknüpften Werten
Unter Windows 2000 hat Active Directory Attribute mit mehreren Werten auf dieselbe Weise wie Attribute mit einem Wert repliziert. Dies führte zu Problemen bei großen dynamischen Gruppenobjekten, deren Mitgliedsattribute mit mehreren Werten regelmäßig auf verschiedenen DCs geändert werden konnten. Wenn ein Administrator einer Gruppe auf einem DC einen Benutzer hinzufügt und ein anderer Administrator einer Gruppe auf einem anderen DC innerhalb des Replikationswartezeit-Fensters einen anderen Benutzer hinzufügt, wählt Active Directory immer den zweiten (späteren) Wert und ignoriert den früheren Wert. Microsoft hat sich mit diesem Problem unter Windows Server 2003 mit einem Vorgang, der als Linked Value Replication (LVR) bezeichnet wird, befasst.
Auf der Funktionsebene bzw. der vorläufigen Funktionsebene der Gesamtstruktur von Windows Server 2003 repliziert Active Directory die individuellen Werte von Forwardlink-Attributen mit mehreren Werten separat. Dabei hat jeder Wert seine eigenen Replikationsmetadaten. Dadurch wird das unter Windows 2000 gefundene Problem, bei dem beinahe gleichzeitige Aktualisierungen von Gruppenmitgliedschaften auf verschiedenen DCs zu Datenverlusten führen konnten, effektiv gelöst.
Allerdings sollte man einen Punkt beachten. Durch Anheben der Funktionsebene der Gesamtstruktur werden bereits bestehende Verknüpfungsattribute mit mehreren Werten nicht automatisch mit den neuen Replikationsmetadaten ausgestattet. Nur Werte, die nach dem Anheben der Gesamtstrukturfunktionsebene hinzugefügt wurden, verfügen über die neuen Metadaten. Dies hat erhebliche Auswirkungen auf die Wiederherstellung von Gruppenmitgliedschaften, wie Sie im Folgenden feststellen werden.
Erstellen von Sicherungen
Zu Windows gehört das sehr einfache NT-BACK-UP-Dienstprogramm, das zum Durchführen der Systemstatussicherung eines DC verwendet werden kann. Der Systemstatus eines Domänencontrollers beinhaltet seine Registrierung, SYSVOL, Active Directory-DIT-Dateien und wichtige Systemdateien. Die meisten Sicherungsdienstprogramme von Drittanbietern können ebenfalls Sicherungen und Wiederherstellungen des Systemstatus eines DC vornehmen.
Mit dem folgenden Befehl führen Sie eine Systemstatussicherung in eine Datenträgerdatei durch:
NTBACKUP backup systemstate /F “<filename>”
Hierbei ist <filename> der Name der zu erstellenden Sicherungsdatei. Die Datei sollte die Erweiterung .bkf erhalten.
Durchführen einer nicht autorisierenden Wiederherstellung.
Das Wiederherstellen gelöschter Active Directory-Objekte aus einer Sicherung erfolgt in zwei Schritten. Starten Sie zunächst den DC im Wiederherstellungsmodus für Verzeichnisdienste (Directory Services Restore Mode, DSRM) neu. Stellen Sie danach die gesamte Active Directory-DIT aus der Systemstatussicherung wieder her, indem Sie das Windows-Dienstprogramm NTBACKUP oder ein ähnliches Produkt eines Drittanbieters verwenden. Durch diesen Prozess wird die gesamte DIT überschrieben.
Es gibt zwei Möglichkeiten, einen DC im DSRM zu starten. Wenn Sie Zugriff auf die Systemkonsole des DC haben, fahren Sie den DC herunter, und starten Sie ihn neu. Drücken Sie bei Aufforderung F8, um das Windows-Startmenü anzuzeigen. Wählen Sie aus dem Menü „Verzeichnisdienste wiederherstellen“ aus, und geben Sie das DSRM-Kennwort ein.
Wenn Sie den Server von einem Remotestandort aus verwalten, haben Sie keinen Zugriff auf das Windows-Startmenü. Stattdessen können Sie die Startoptionen für das System ändern, indem Sie vom Arbeitsplatz „Eigenschaften“ auswählen, auf die Registerkarte „Erweitert“ klicken und dann unter „Starten und Wiederherstellen“ auf die Schaltfläche „Einstellungen“ klicken. Klicken Sie im Bereich „Systemstart“ auf die Schaltfläche „Bearbeiten“, um die Datei „boot.ini“ zu bearbeiten, und fügen Sie den Switch „/SAFEBOOT:DSREPAIR“ am Ende der Zeile hinzu, wie in Abbildung 3 gezeigt. (Weitere Informationen zu boot.ini-Switches finden Sie unter microsoft.com/technet/ sysinternals/information/bootini.mspx.)
Abbildung 3** Einstellen von Startoptionen für DSRM **(Klicken Sie zum Vergrößern auf das Bild)
Der Server startet bei einem Neustart im DSRM. Denken Sie daran, den /SAFEBOOT-Switch aus der Datei „boot.ini“ zu entfernen, wenn Sie den DC im normalen Modus neu starten möchten.
Stellen Sie nach dem Anmelden mit dem DSRM-Kennwort die Systemstatussicherung mit dem Befehl NTBACKUP wieder her, geben Sie dabei jedoch keine Parameter an. (Sie können keine Wiederherstellung durchführen, indem Sie den Befehl NTBACKUP von der Befehlszeile ausführen.) Wenn sich der Assistent öffnet, wählen Sie „Dateien und Einstellungen wiederherstellen“, und klicken Sie auf „Weiter“. Wählen Sie dann die Sicherungsdatei aus, und aktivieren Sie das Feld „Systemstatus“, wie in Abbildung 4 gezeigt.
Abbildung 4** Verwenden des Sicherungs- oder Wiederherstellungs-Assistenten zur Wiederherstellung des Systemstatus **(Klicken Sie zum Vergrößern auf das Bild)
Wenn Sie an dieser Stelle den DC wieder im normalen Modus starten würden, würde der Active Directory-Replikationsvorgang den wiederhergestellten Domänencontroller mit den anderen DCs in der Domäne synchronisieren, und alle wiederhergestellten Daten würden mit aktuellen Daten überschrieben. Das soll jedoch keinesfalls passieren. Stattdessen müssen Sie eine Möglichkeit finden, die wiederhergestellten Objekte dazu zu bringen, sich auf die anderen Domänencontroller in der Domäne zu replizieren.
Durchführen einer autorisierenden Wiederherstellung
NTDSUTIL erhöht außerdem die Versionsnummer jedes Attributs um 100.000 für jeden Tag zwischen dem Datum der Sicherung und dem Datum der Wiederherstellung. Die Versionsnummer der wiederhergestellten Attribute ist daher sehr viel größer als die Versionsnummern der anderen DCs (es sei denn, es gibt Attribute, die über 100.000 mal täglich aktualisiert werden, was ziemlich unwahrscheinlich ist), wodurch sich das autorisierend wiederhergestellte Objekt auf die anderen DCs repliziert. Die anderen, nicht autorisierend wiederhergestellten Objekte aus der Sicherung werden letztendlich durch vorhandene Daten von den anderen Domänencontrollern überschrieben.
Verwenden Sie nach Beenden der nicht autorisierenden Wiederherstellung und vor dem Neustart im normalen Modus das Programm NTDSUTIL, um eine autorisierende Wiederherstellung der Objekte durchzuführen, die Sie wiederherstellen möchten. Bei der autorisierenden Wiederherstellung wird das Objekt nicht wiederhergestellt, sondern einfach sichergestellt, dass Active Directory das Objekt auf die anderen DCs repliziert. Hierfür weist NTDSUTIL der lokalen USN der Attribute des Objekts die nächste verfügbare USN zu. Dadurch wird das Objekt bei der nächsten Synchronisierung an Replikationspartner gesendet. Stellen Sie zum Wiederherstellen eines einzelnen Objekts sicher, dass der DC im DSRM gestartet wurde, und führen Sie die folgenden Schritte aus:
- Öffnen Sie ein Befehlsfenster, und geben Sie Folgendes ein:
ntdsutil
- Geben Sie in der ntdsutil-Eingabeaufforderung Folgendes ein:
authoritative restore
- Geben Sie in der Eingabeaufforderung für die autorisierende Wiederherstellung Folgendes ein:
restore object “<DN of object to be restored>”
- Beispiel: Wenn Sie das Konto „Molly Clark“ aus der Organisationseinheit „Eng“ in der Domäne DRNET wiederherstellen möchten, geben Sie Folgendes ein:
restore object “CN=Molly Clark,OU=Eng,DC=DRNET,DC=com”
- Wenn Sie eine komplette Unterstruktur eines Verzeichnisses autorisierend wiederherstellen möchten, z. B. eine Organisationseinheit, geben Sie stattdessen Folgendes ein:
restore subtree “OU=Eng,DC=DRNET,DC=com”
- NTDSUTIL stellt auch einen Befehl zur Wiederherstellung einer Datenbank zur Verfügung, mit dem die gesamte Domäne und die Konfigurations- und Schemanamenskontexte autorisierend wiederhergestellt werden. Das Wiederherstellen der gesamten Domäne birgt einige Gefahren. Ich empfehle die Verwendung dieser Option nicht. Wenn Sie eine gesamte Domäne wiederherstellen müssen, sollten Sie einen Domänencontroller wiederherstellen und die anderen DCs in der Domäne wieder höher stufen, wie unter Planung der Wiederherstellung einer Active Directory-Gesamtstruktur beschrieben.
- Bestätigen Sie bei der entsprechenden Aufforderung, dass durch die autorisierende Wiederherstellung die Versionsnummern der entsprechenden Objekte und ihrer Attribute erhöht werden sollen.
- Beenden Sie ntdsutil (Sie müssen zweimal „quit“ eingeben).
- Starten Sie den DC im normalen Active Directory-Modus neu.
Das nächste Mal, wenn der DC mit seinen Partnern repliziert, wird der von Ihnen wiederhergestellte Benutzer repliziert. Aber das Wiederherstellen des Benutzerobjekts ist nur die eine Hälfte des Problems. Wenn Sie Objektverknüpfungen einführen, wie die zwischen einer Gruppe und deren Mitgliedern, wird die Situation ein wenig komplizierter. Es können während und nach der Wiederherstellung einige grundlegende Probleme auftreten, auf die ich im Folgenden eingehen möchte.
Überprüfen wir zunächst, was geschieht, wenn Sie ein Objekt löschen, das über Backwardlinks verfügt. Angenommen, Sie löschen ein Benutzerobjekt, das Mitglied einer oder mehrerer Gruppen ist. Jeder Domänencontroller, der eine Kopie des Benutzerobjekts hat, konvertiert dieses in einen Tombstone und entfernt alle Verweise aus der Verknüpfungstabelle. Dabei wird das Benutzerobjekt aus allen Gruppenmitgliedschaften in der Domäne des Benutzers entfernt. (Denken Sie daran, dass das Entfernen des Benutzers aus Gruppenmitgliedschaften keine replizierte Änderung ist, da jeder DC die Gruppenmitgliedschaft lokal repliziert. Die Versionsnummer und die lokale USN des Mitgliedsattributs der Gruppe bleiben unverändert). Kurz darauf werden die Phantomobjekte aus den Verknüpfungstabellen in anderen Domänen entfernt. Auch hier kommt es nicht zu einer Aktualisierung der Replikationsmetadaten der Mitgliedsattribute der Gruppe.
Wenn Sie die DIT auf einem Domänencontroller in der Domäne des Benutzers nicht autorisierend wiederherstellen, stellen Sie das Benutzerobjekt zusammen mit allen Gruppenmitgliedschaften in Gruppen in der Domäne wieder her, sodass der wiederhergestellte DC in sich konsistent ist. Nach Einsatz des Dienstprogramms NTDSUTIL für eine autorisierende Wiederherstellung des Benutzers repliziert sich das Benutzerobjekt in alle anderen DCs der Domäne.
Da jedoch die Replikationsmetadaten der aktuellen Gruppen in der Domäne unverändert bleiben, sind die Mitgliedsattribute der Gruppen auf dem wiederhergestellten DC inkonsistent mit denen auf den anderen DCs. Es gibt keine Möglichkeit, diese Inkonsistenz aufzuheben. Folglich werden die Mitgliedschaften des Benutzers auf den anderen DCs in der Domäne nicht wiederhergestellt.
Problem: Gruppenmitgliedschaften innerhalb der Domäne können nicht wiederhergestellt werden
Durch die autorisierende Wiederherstellung des Benutzerobjekts werden die Gruppenmitgliedschaften des Benutzers nicht wiederhergestellt. Warum nicht? Weil die Mitgliedschaftsbeziehung unter Verwendung des Mitgliedsattributs des Gruppenobjekts (Forwardlinks) gespeichert und repliziert wird, und nicht unter Verwendung des memberOf-Attributs des Benutzers (Backwardlink). Das Problem liegt darin, die alten Gruppenmitgliedschaften des Benutzers zu finden und diese ordnungsgemäß wiederherzustellen.
Microsoft hat schrittweise Verbesserungen für den Vorgang der Wiederherstellung einer Gruppenmitgliedschaft eines Benutzers eingeführt. Die zu verwendende Methode hängt also von Ihrer Version von Active Directory ab. Der folgende Abschnitt trifft in erster Linie auf Windows 2000 Active Directory zu.
Die Bestimmung der alten Gruppenmitgliedschaften des Benutzers ist relativ unkompliziert: Prüfen Sie einfach das Backwardlink-Attribut auf dem wiederhergestellten DC, in diesem Fall das memberOf-Attribut des Benutzerobjekts. Das memberOf-Attribut enthält alle Mitgliedschaften in lokalen und globalen Gruppen in der Domäne des Benutzers. Sie können das MMC-Snap-In „Active Directory-Benutzer und -Computer“ (ADUC) oder das in Windows Server enthaltene Dienstprogramm LDIFDE verwenden, um die wiederhergestellten Gruppenmitgliedschaften des Benutzers aufzuführen.
Die folgende LDIFDE-Befehlszeile führt die Gruppen in der Domäne DRNET auf, bei denen Molly Clark Mitglied ist. Die Ergebnisse werden in der Datei „output.ldf“ gespeichert.
C:\> ldifde –r “(distinguishedName=CN=Molly Clark,
OU=Engineering,DC=DRNET,DC=Local)” –l memberOf –p Base –f output.ldf
Beachten Sie, dass Sie den DC im normalen Modus starten müssen, um LDAP-Werkzeuge zu verwenden. Außerdem müssen Sie die eingehende Replikation deaktivieren, da sonst die wiederhergestellten Daten überschrieben werden. Am einfachsten können Sie die eingehende Replikation mit dem Befehl REPADMIN deaktivieren:
REPADMIN /options <dcname>+DISABLE_INBOUND_REPL
Hier ist <dcname> der Name des DC, auf dem die Wiederherstellung stattfindet. Vergessen Sie nicht, die Replikation wieder zu aktivieren, indem Sie –DISABLE_INBOUND_REPL verwenden, wenn Sie fertig sind.
Wenn Sie nur ein paar Benutzer wiederherstellen, ist das einfache manuelle Hinzufügen der Benutzer zu den Gruppen mit ADUC recht einfach. Wenn Sie eine größere Anzahl Benutzer wiederherstellen, gibt es ein paar Tools, mit denen der Vorgang teilweise automatisiert werden kann. Das Microsoft-Dienstprogramm GROUPADD (erhältlich beim Microsoft-Produktsupport) akzeptiert die von Ihnen zum Auflisten der alten Gruppenmitgliedschaften des Benutzers erstellte LDIF-Datei und erstellt eine LDIF-Datei, die diese Mitgliedschaften wiederherstellt. Sie können den Befehl GROUPADD beispielsweise dazu verwenden, die LDIF-Datei, die wir im früheren Beispiel für Molly Clark erstellt haben, zu verarbeiten:
C:\> groupadd /after_restore output.ldf
Der Befehl erstellt eine neue LDIF-Datei mit dem Namen „groupadd_<domain>.ldf“ für jede Domäne, in der Molly Clark Gruppenmitgliedschaften hatte (wobei <domain> der vollqualifizierte Domänenname der Domäne ist, deren Gruppen aktualisiert werden). Mit dem folgenden Befehl können Sie die so erstellte LDIF-Datei importieren:
C:\> ldifde –i –k –f groupadd_child.drnet.net.ldf
Unter Windows Server 2003 hat Microsoft NTDSUTIL verbessert, sodass die zusätzlichen Metadaten aus dem Mitgliedsattribut verwendet werden können, um die Linked Value Replication (LVR) zu unterstützen. Wenn das wiederhergestellte Benutzerobjekt ein Mitglied einer Gruppe in der Domäne war und die Gruppenmitgliedschaft des Benutzers mit LVR-Metadaten gespeichert wurde, erhöht NTDSUTIL die Versionsnummer des entsprechenden Werts des Mitgliedsattributs. Dadurch repliziert sich die wiederhergestellte Mitgliedschaft.
Bei der Windows Server 2003 SP1-Version von NTDSUTIL sind die GROUPADD-Funktionen integriert. Dadurch werden während der autorisierenden Wiederherstellung des Benutzerobjekts automatisch LDIF-Dateien erstellt. In Abbildung 5 ist die neue Version von NTDSUTIL dargestellt, in Abbildung 6 der Inhalt der automatisch erstellten LDIF-Datei.
Figure 6 Inhalt der von NTDSUTIL erstellten LDIF-Datei
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
Abbildung 5** Neue NTDSUTIL-Version mit integrierten GROUPADD-Funktionen **(Klicken Sie zum Vergrößern auf das Bild)
Wenn Sie eine ganze Organisationseinheit wiederherstellen, die eine Reihe von Benutzern und Gruppen enthält, ist das Hinzufügen von Benutzern zu ihren Gruppen eine recht langwierige Angelegenheit. Eine andere Möglichkeit, die wiederhergestellten Gruppenmitgliedschaften wieder hinzuzufügen, ist das autorisierende Wiederherstellen der Gruppen selbst.
Allerdings gibt es beim autorisierenden Wiederherstellen von Gruppen zwei Probleme. Das erste Problem ist ziemlich offensichtlich: Wenn Sie eine Gruppe wiederherstellen, wird die Mitgliedschaft in dieser Gruppe im Zustand zum Zeitpunkt der Sicherung wiederhergestellt. Das bedeutet, dass alle Änderungen, die Sie seit der letzten Sicherung an der Gruppe durchgeführt haben, erneut auf die Gruppe angewendet werden müssen. Das zweite Problem ist nicht ganz so offensichtlich und hat mit der Funktionsweise der Active Directory-Replikation zu tun. Nach einer autorisierenden Wiederherstellung von Benutzern und Gruppen kann nicht bestimmt werden, in welcher Reihenfolge diese repliziert werden. Wenn sich ein Gruppenobjekt auf einem DC vor dem wiederhergestellten Benutzerobjekt repliziert, entfernt der replizierende Domänencontroller automatisch den Benutzerverweis aus der Gruppe, da das Benutzerobjekt auf diesem DC noch nicht existiert. Wenn sich das Benutzerobjekt später repliziert, wird es der Gruppe nicht hinzugefügt.
Das Problem lässt sich am einfachsten durch nochmaliges Durchführen der autorisierenden Wiederherstellung der Gruppen beheben. Starten Sie nach der Durchführung der ersten autorisierenden Wiederherstellung im normalen Modus, und stellen Sie sicher, dass die Replikation korrekt durchgeführt wird. Starten Sie dann nochmals im DSRM, und führen Sie NTDSUTIL aus, um eine autorisierende Wiederherstellung der Gruppen durchzuführen, in denen der Benutzer Mitglied war. Wenn Sie jetzt wieder im normalen Modus starten, hat sich das Benutzerobjekt repliziert, bevor sich die entsprechenden Gruppenobjekte replizieren.
Problem: Gruppenmitgliedschaften in anderen Domänen lassen sich nicht wiederherstellen
Das Problem, in welcher Gruppe dieser Benutzer Mitglied war, ist eigentlich etwas komplizierter als oben beschrieben. Der Benutzer, den Sie wiederherstellen, war eventuell Mitglied in lokalen und universellen Gruppen in anderen Domänen. Diese Gruppenmitgliedschaften werden nicht wiederhergestellt, wenn Sie eine nicht autorisierende Wiederherstellung durchführen. Wie können Sie also herausfinden, zu welchen Gruppen der Benutzer in anderen Domänen gehörte? Die Antwort finden Sie im globalen Katalog. Zusammen mit den Daten seiner eigenen Domäne enthält der globale Katalog eine schreibgeschützte Kopie der Daten der anderen Domänen in der Gesamtstruktur.
Um die Gesamtstrukturdaten des globalen Katalogs nutzen zu können, müssen Sie eine nicht autorisierende Wiederherstellung auf einem globalen Katalog durchführen. Das bedeutet, dass Sie eine Sicherung eines globalen Katalogs haben müssen. Wenn Sie LDIFDE ausführen, um die Gruppenmitgliedschaften des Benutzers zu identifizieren, können Sie auch die universellen Gruppenmitgliedschaften in anderen Domänen feststellen.
Verbinden Sie sich, wenn Sie die Gruppenmitgliedschaften des wiederherzustellenden Benutzers auflisten, mit dem globalen Katalogport 3268 anstelle des Standardports 389, und geben Sie die Stammdomäne der Gesamtstruktur als Grundlage für die Suche an. LDIFDE zeigt die wiederhergestellten Gruppenmitgliedschaften des Benutzers an, inklusive der Mitgliedschaft in universellen Gruppen in allen Domänen der Gesamtstruktur. So gehen Sie vor:
C:\> ldifde –r “(distinguishedName=CN=Don Clark,
OU=Engineering,DC=DRNET,DC=Local)” -t 3268 –l memberOf –p Base –f output.ldf
Wenn Sie GROUPADD oder die neue NTDSUTIL-Version auf einem globalen Katalog ausführen, wird eine LDIF-Datei für die Domäne des Benutzers und eine LDIF-Datei für jede Domäne erstellt, in der der wiederhergestellte Benutzer Mitglied einer universellen Gruppe war. Wenn Sie diese LDIF-Dateien importieren, stellen Sie alle Gruppenmitgliedschaften des Benutzers wieder her. Jedenfalls fast alle, was uns zum nächsten Problem führt.
Problem: Wiederherstellen von Mitgliedschaften in lokalen Domänengruppen anderer Domänen
In einer Windows Active Directory-Umgebung gibt es drei Arten von Gruppen. Globale Gruppen können nur Mitglieder in derselben Domäne enthalten, sie können jedoch als Mitglied in lokalen Domänengruppen in der eigenen Domäne und anderen Domänen in der Gesamtstruktur verwendet werden. Das Mitgliedsattribut globaler Gruppen wird im globalen Katalog nicht angezeigt, das ist jedoch kein Problem, da globale Gruppen nur Mitglieder ihrer eigenen Domäne enthalten. Universelle Gruppen können Mitglieder jeder Domäne enthalten. Außerdem können sie als Mitglieder in anderen universellen Gruppen in der Gesamtstruktur und in lokalen Domänengruppen in ihrer eigenen und anderen Domänen in der Gesamtstruktur verwendet werden. Das Mitgliedsattribut universeller Gruppen wird in globalen Katalogen repliziert. Lokale Domänengruppen können Mitglieder aus jeder Domäne der Gesamtstruktur enthalten. Sie können jedoch nicht als Mitglieder in Gruppen in anderen Domänen verwendet werden. Außerdem wird das Mitgliedsattribut von lokalen Domänengruppen, wie das globaler Gruppen, nicht im globalen Katalog angezeigt. Daher gibt es keine einfache Möglichkeit, die Mitgliedschaft des Benutzers in lokalen Domänengruppen in anderen Domänen wiederherzustellen.
Vor Windows Server 2003 SP1 war die einzige Möglichkeit, Mitgliedschaften in lokalen Domänengruppen in fremden Domänen wiederherzustellen, einen DC in jeder Domäne wiederherzustellen, die Domänendaten für jede lokale Domänengruppe, die den wiederhergestellten Benutzer enthielt, manuell zu suchen, und dann den Benutzer den identifizierten Gruppen wieder hinzuzufügen. In einer großen Umgebung mit vielen Domänen ist diese Vorgehensweise viel zu zeitaufwändig.
Mit der Windows Server 2003 SP1-Version von NTDSUTIL geht das einfacher. Wenn Sie NTDSUTIL auf einem Domänencontroller ausführen, erstellt das Dienstprogramm eine Textdatei, die den DN und die GUID der wiederhergestellten Benutzerobjekte enthält. Sie können dann für jede fremde Domäne einen einzelnen DC nicht autorisierend wiederherstellen, die Textdatei auf den DC kopieren und NTDSUTIL ausführen, um eine neue, domänenspezifische LDIF-Datei zu erstellen, die den wiederhergestellten Benutzer wieder zu den lokalen Domänengruppen hinzufügt, bei denen er Mitglied war.
Führen Sie hierfür die folgenden Schritte auf einem DC in jeder fremden Domäne durch:
- Starten Sie den DC in der fremden Domäne im DSRM.
- Verwenden Sie NTBACKUP, um eine Kopie der DIT wiederherzustellen, die die wiederhergestellten Gruppenmitgliedschaften des Benutzers enthält.
- Kopieren Sie die von NTDSUTIL erstellte .txt-Datei auf den aktuellen DC.
- Öffnen Sie ein Befehlsfenster, und geben Sie „ntdsutil“ ein.
- Geben Sie „authoritative restore“ ein.
- Geben Sie „create LDIF file(s) from <Dateiname>“ ein (wobei <Dateiname> der Name der Textdatei ist).
- Geben Sie zweimal „quit“ ein, um „ntdsutil“ zu beenden.
- Starten Sie den DC neu im normalen Active Directory-Modus.
- Geben Sie „ldifde –i –f <ldif-Dateiname>“ ein (wobei <ldif-Dateiname> der Name der soeben erstellten LDIF-Datei ist).
Jetzt haben Sie alle gelöschten Gruppenmitgliedschaften des Benutzers wiederhergestellt.
Schritt für Schritt
Das Wiederherstellen von Active Directory-Benutzern und ihren Gruppenmitgliedschaften ist kompliziert, besonders in einer Umgebung mit mehreren Domänen. Die zur korrekten Wiederherstellung von Gruppenmitgliedschaften erforderlichen speziellen Schritte hängen von Ihrer Windows-Version ab.
Unter Windows 2003 SP1 gehen Sie wie folgt vor:
- Starten Sie einen globalen Katalog im DSRM, und führen Sie eine Wiederherstellung des Systemstatus mit einer Sicherung durch, die den gelöschten Benutzer enthält.
- Verwenden Sie NTDSUTIL, um eine autorisierende Wiederherstellung des gelöschten Benutzers durchzuführen. NTDSUTIL erstellt eine Textdatei mit den DNs und GUIDs des wiederhergestellten Objekts sowie mindestens eine LDIF-Datei, um die Gruppenmitgliedschaften des Benutzers wiederherzustellen.
- Verwenden Sie „LDIFDE –i –f <LDIF-Dateiname>“ (wobei <LDIF-Dateiname> der Name der in Schritt 2 erstellten LDIF-Datei ist), um die Gruppenmitgliedschaften in die aktuelle und andere Domänen zu importieren.
- Starten Sie den globalen Katalog im normalen Modus neu.
- Starten Sie einen DC in jeder Domäne im DSRM, und führen Sie eine Wiederherstellung des Systemstatus mit einer Sicherung durch, die die Gruppenmitgliedschaften des wiederhergestellten Benutzers enthält.
- Führen Sie NTDSUTIL aus, indem Sie den Befehl „create ldif files“ verwenden.
- Starten Sie den DC im normalen Modus neu.
- Verwenden Sie „LDIFDE –i –f <Dateiname>“ (wobei <Dateiname> der Name der von Ihnen in Schritt 6 erstellten LDIF-Datei ist), um die Gruppenmitgliedschaften in der fremden Domäne wiederherzustellen.
- An dieser Stelle können Sie optional die Replikation mit „REPADMIN /syncall“ erzwingen.
Wenn Sie eine Version von Windows Server 2003 ohne SP1 bzw. Windows 2000 verwenden, müssen Sie einige zusätzliche Schritte ausführen. Da die ältere Version von NTDSUTIL keine LDIF-Dateien erstellt, verwenden Sie das Dienstprogramm GROUPADD für deren Erstellung. So gehen Sie vor:
- Starten Sie einen globalen Katalog im DSRM, und führen Sie eine Wiederherstellung des Systemstatus mit einer Sicherung durch, die den gelöschten Benutzer enthält.
- Deaktivieren Sie den NIC, oder ziehen Sie das Kabel heraus, um die eingehende Replikation zu verhindern.
- Starten Sie den globalen Katalog im normalen Modus neu.
- Verwenden Sie „LDIFDE –r "(distinguishedName=<dn>)" -t 3268 -l memberOf –p Base -f membership.ldf“, um die Mitgliedschaft des Benutzers mit dem eindeutigen Namen <dn> zu sichern.
- Verwenden Sie „GROUPADD /after_restore membership.ldf“, um LDIF-Dateien zu erstellen.
- Verwenden Sie „LDIFDE –i –f <Dateiname>“ (wobei <LDIF-Dateiname> der Name der von GROUPADD in Schritt 5 erstellten LDIF-Datei ist), um die Gruppenmitgliedschaften in die aktuelle Domäne und andere Domänen zu importieren.
- Verwenden Sie „REPADMIN /options <dcname> -DISABLE_INBOUND_REPL“, um die eingehende Replikation wieder zu aktivieren.
- Starten Sie einen DC in jeder Domäne im DSRM, und führen Sie eine Wiederherstellung des Systemstatus mit einer Sicherung durch, die die Gruppenmitgliedschaften des wiederhergestellten Benutzers enthält.
- Starten Sie den DC im normalen Modus neu.
- Verwenden Sie „LDIFDE –i –f <Dateiname>“ (wobei <Dateiname> der Name der von GROUPADD in Schritt 5 erstellten LDIF-Datei ist), um die Gruppenmitgliedschaften in der fremden Domäne wiederherzustellen.
- An dieser Stelle können Sie optional die Replikation mit „REPADMIN /syncall“ erzwingen.
Jetzt müssen Sie in einer Vorumgebung von Windows Server 2003 SP1 nur noch die lokalen Gruppenmitgliedschaften fremder Domänen für den wiederhergestellten Benutzer wiederherstellen. Sie können die lokalen Gruppenmitgliedschaften der Domänen entweder manuell wiederherstellen oder einen DC aus einer Sicherung wiederherstellen und die lokalen Domänengruppen autorisierend wiederherstellen.
Zusammenfassung
Es kann leicht passieren, dass versehentlich Benutzer oder sogar Organisationseinheiten in Active Directory gelöscht werden. Die richtige Wiederherstellung der gelöschten Benutzer und ihrer Gruppenmitgliedschaften ist jedoch überraschend komplex, zeitaufwändig und fehleranfällig. Um nach diesen Notfällen Daten so schnell wie möglich wiederherstellen zu können, müssen Sie die Funktionsweise von Objektverknüpfung, Replikation, Löschen und autorisierender Wiederherstellung verstehen.
Meinen Sie wirklich, dass Sie das heute Gelernte bei einem Notfall ohne Weiteres in Ihrer Produktionsumgebung anwenden können? Sind Sie wirklich gut darauf vorbereitet, das Benutzerobjekt des Geschäftsführers schnell wiederherzustellen? Verfassen Sie einen schriftlichen Plan zur Wiederherstellung gelöschter Objekte. Führen Sie diesen Plan vor dem Ernstfall mindestens ein- oder zweimal zur Probe durch. Ihr Chef (und der Geschäftsführer) wird dies zu schätzen wissen.
Weitere Ressourcen
- Wiederherstellen gelöschter Benutzerkonten und ihrer Gruppenmitgliedschaften in Active Directory
- Microsoft-Produktsupport
- Schritt-für-Schritt-Anleitung für Active Directory
Gil Kirkpatrick ist CTO von NetPro und entwickelt seit 1996 Software für Active Directory. Zusammen mit Guido Grillenmeier von HP bietet er die beliebten Workshops zur Active Directory-Notfallwiederherstellung an. Gil ist darüber hinaus Gründer der Directory Experts Conference (www.dec2007.com).
© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.