Freigeben über

Gesichert - Sicher? Auch wieder hergestellt?

  • Artikel

Hallo, hier ist wieder einmal der Herbert.

Das Wunschthema des Gewinners unserer Umfrage war "Disaster Recovery". Nun gibt es von Familienfesten über Parteitage zu Fußballspielen verschiedene Arten von Desastern. Im AD-Bereich haben Desaster in den meisten Fällen mit dem Verlust oder Korruption von AD Daten oder Domain Controllern zu tun, weniger oft mit dem Verlust von DCs oder ganzer Domains.

Ich möchte mich dieses Mal dem etwas schmerzhaften Thema Sichern und Wiederherstellen von Active Directory Daten widmen. Der Verlust von Objekten durch unbeabsichtigtes Löschen oder Datenverlust durch ein wild gewordenes Script oder Provisioning System ist bei uns der häufigste Auslöser von Anfragen, bei denen AD Daten verloren gegangen sind.

Als schmerzhaft empfinden viele besonders das Thema Restore, weil der Vorgang als sehr umständlich empfunden wird und nicht sehr gut beschrieben. Ein sicheres Anzeichen dafür ist die Länge dieses KB Artikels:
840001 How to restore deleted user accounts and their group memberships in Active Directory
https://support.microsoft.com/default.aspx?scid=kb;EN-US;840001

Wer nun die Vorgehensweise nicht regelmäßig übt, wird im Falle des Falles (fehlende Objekte oder falsche Daten), sich bei der Durchführung des Restores sehr unsicher fühlen und zur Vermeidung von weiteren Fehlern Hilfe brauchen. Schließlich steht der Betrieb für viele Benutzer, und das darf nicht länger dauern als nötig.

Bei der richtigen Vorbereitung und Systemversion könnt ihr Euch heutzutage auf Methode 1 aus Artkel 840001 beschränken, die besonders für Umgebungen mit einer Domain relativ gut zu "bedienen" ist. Dieser Ansatz ist auch der einzige, der einen vollständigen Restore der Objektlinks über Domain Grenzen hinweg sicherstellt.

Ihr könnt das durch die richtige Vorbereitung erreichen:
1. Verwenden der Windows 2003 Forest Modes und Links im LVR-Format.

Dies erlaubt das Verfolgen der gelöschten Links durch NTDSUTIL und späteren Import in anderen Domains des Forests.

2. Umwandeln der alten Gruppenmitgliedschaften (LEGACY) in Linked Value Mitgliedschaften.

Dazu müssen leider die Gruppenmitglieder entfernt und wieder hinzugefügt werden. Mit den Kommandozeilentools zur AD-Objektbearbeitung ist das aber recht einfach:

dsget group CN=GroupX,OU=Groups,DC=contoso,DC=com /members | dsmod group CN=GroupX,OU=Groups,DC=contoso,DC=com /chmbr

Mit dem Kommando werden in einem Rutsch die Mitglieder ausgetauscht.
Ihr solltet darauf achten, dass nicht zu viele Gruppen in zu kurzer Zeit umgestellt werden, denn die WAN Leitungen glühen sonst unter der Replikationslast. Es sollte auf den Replikationspartnern nicht zu beobachten sein, dass die Gruppenmitgliedschaften kurz weg waren. Die Änderung wird in einem Stück repliziert.

Nun gibt es folgende Probleme:

  1. Die Version von DSGET in Windows Server 2003 holt maximal 1500 Mitglieder aus einer Gruppe ab. Das heißt, ihr würdet die Mitgliedschaft auf 1500 Mitglieder verkürzen. Ich habe auch eine Testumgebung, in der DSGET gar keine Mitglieder anzeigt. Die Version von DSGET aus Windows 2008 hat diese Probleme aber nicht.
  2. Wenn eine Gruppe viele Mitglieder hat, wird bei der Ausführung von DSMOD der Version Store ausgereizt und das Hinzufügen der Mitglieder im LVR-Modus schlägt fehl. Nun ist das Umwandeln der Mitgliedschaften für jede Gruppe eine einmalige Angelegenheit.
    Eine Idee für das Thema ist, erst einmal alle Mitgliedschaften in Dateien zu exportieren. Ich beschreibe das nachfolgend.
  3. Verwendung der richtigen Systemsoftware Version (siehe unten).

Gruppen auf LVR umwandeln

Ihr könnt den Zustand der Gruppenmitgliedschaft sehen, wenn in repadmin /showobjmeta bei den Links als „Type“ LEGACY gelistet wird:

Type Attribute Last Mod Time Originating DC Loc.USN Org.USN Ver
======= ============ ============= ================= ======= ======= ===
Distinguished Name
=============================
LEGACY member
CN=test-user1,OU=Test-OU,DC=contoso,DC=com
PRESENT member 2008-09-16 18:22:29 HQ\contoso-DC1 175379684 175379684 1
CN=test-user2,OU=Test-OU,DC=contoso,DC=com

Die Zeile LEGACY hat keine Daten zur letzten Änderung, die ist mit den normalen Attributen gelistet.
Hinweis: Ich verwende für Schleifen CMD und das Kommando „For“ in der Syntax für direkte Ausführung. Bei Ausführung in CMD-Skripts braucht ihr doppelte Prozent bei den Variablen, also „%%f“.

Die Schritte sind nun:

Zunächst sollten Änderungen an Gruppen eingefroren werden.

Zum Exportieren der Gruppenliste bietet sich an:

Dsquery group dc=contoso,dc=com /limit 0 > Gruppenliste.txt

Ihr solltet aus dieser Liste die Gruppen im Builtin Container entfernen, und die „Domain Admins“ und andere Default Gruppen. Aus diesen Gruppen können nicht alle Mitglieder entfernt/getauscht werden, was weiter unten gemacht wird. Aber diese Gruppen können auch nicht gelöscht werden.

Nun holen wir die Mitglieder aller Gruppen auf Windows Vista mit RSAT oder 2008:

For "delims=§" %f in (Gruppenliste.txt) do DSGET %f /members > Gruppenmitglieder\%f

Wichtig: Die Gruppen-DNs sollten keine Zeichen “§:\/*?” enthalten. Bei "§" könnt ihr auch ein anderes Dummy-Trennerzeichen verwenden. Gruppen mit diesen Zeichen sollten vorübergehend umbenannt werden (nur anderer CN nötig).

Nun zählen wir die Mitglieder:

For "delims=§" %f in (Gruppenliste.txt) do wc Gruppenmitglieder\%f >> Mitgliederzahl.txt

In Mitgliederzahl.txt ist die erste Spalte die Anzahl der Mitglieder der Gruppe. Alle Gruppen mit mehr als 5000 Mitgliedern bekommen eine Sonderbehandlung. Ihre Mitgliederlisten verschiebt ihr in ein Verzeichnis "Gruppenmitglieder-gross1".

Für den Rest führt ihr aus:

Dir /b Gruppenmitglieder >Gruppenliste-Klein.txt
For /f "delims=§" %f in (Gruppenliste-Klein.txt) do dsmod group "%f" /chmbr < "Gruppenmitglieder\%f"

Hinweis: "%f" ist hier in doppelten Hochkommas, da die Ausgabe von "dir /b" keine enthält.

Dann sind diese Gruppen schon einmal versorgt.

Nun zu den großen Gruppen

Bei den großen Gruppen teilt ihr die Mitgliederliste einfach in mehrere Dateien auf nach jeweils 5000 Zeilen und legen die Abschnitte in eigene Verzeichnisse, wieder mit dem DN der Gruppe als Name:

Dir /b Gruppenmitglieder-gross1 >Gruppenliste-gross1.txt
For /f "delims=§" %f in (Gruppenliste-gross1.txt) do dsmod group "%f" /chmbr < "Gruppenmitglieder-gross1\%f"

Dir /b Gruppenmitglieder-gross2 >Gruppenliste-gross2.txt
For /f „delims=§“ %f in (Gruppenliste-gross2.txt) do dsmod group "%f" /chmbr < "Gruppenmitglieder-gross2\%f"

Ihr könnt von einigen Gruppen zur Kontrolle die Meta-Daten holen:

For "delims=§" %f in (Gruppenliste.txt) do repadmin /showobjmeta . %f > Gruppen-Meta\%f

In den Exportdateien sollte "LEGACY" dann nur noch für andere verlinkte Attribute gelistet sein.

Puh, das war schon ein schönes Stück Arbeit. Wenigstens brauchen wir uns um die primäre Gruppe nicht zu kümmern. :-)
Ich empfehle, dass Ihr erst einmal mit ein paar Testgruppen übt (auch wenn die Mitglieder dann schon im LVR Mode sind). Und danach macht Ihr mit kleinen OU-Bäumen weiter um dann mit mehr Erfahrung das für die ganze Domain und schließlich für alle Domains durchzuziehen.

Empfohlene Fixes

Leider gab es in letzter Zeit zwei Probleme, die die Replikation nach einem (Authoritative) Restore betroffen haben:

937855 After you restore deleted objects by performing an authoritative restoration on a Windows Server 2003-based domain controller, the linked attributes of some objects are not replicated to the other domain controllers
https://support.microsoft.com/default.aspx?scid=kb;EN-US;937855

943576 Active Directory objects may not be replicated from the restored server after an authoritative restore on a Windows Server 2003-based domain controller
https://support.microsoft.com/default.aspx?scid=kb;EN-US;943576

Wenn Ihr den Fix 943576 auf den DCs habt die regelmäßig gesichert werden, sollte es keine Probleme geben. Langfristig sollte der Hotfix auf alle Domain Controller im Unternehmen präsent sein.

Als würde das nicht reichen, kommen noch Probleme mit dem Tool zum Wiederherstellen von AD Daten dazu, dem NTDSUTIL.EXE. Da sind zunächst Probleme beim Umgang mit Objekten mit erweiterten Zeichen (jenseits 7 Bit ASCII) im Objektnamen:
886689 The Ntdsutil authoritative restore operation is not successful if the distinguished name path contains extended characters in Windows Server 2003 and in Windows 2000
https://support.microsoft.com/default.aspx?scid=kb;EN-US;886689

910823 Error message when you try to import .ldf files on a computer that is running Windows Server 2003 with Service Pack 1: "Add error on line LineNumber: No such object"
https://support.microsoft.com/default.aspx?scid=kb;EN-US;910823

Darüber hinaus gibt es noch das Problem, dass bereits vor dem Backup gelöschte Links restauriert werden:
951320 The ntdsutil.exe utility in Windows Server 2003 writes out too many links to .ldf files during an authoritative restore process
https://support.microsoft.com/default.aspx?scid=kb;EN-US;951320

Die gute Nachricht ist, dass mit Fix 951320 auf den regelmäßig gesicherten DCs auch diese Klippe umschifft ist, und man sich nur noch um das Problem 910823 per Hand kümmern muss.

UPDATE:

Es gibt einen neuen Fix für NTDSUTIL.EXE, der es erlaubt ein Folgeproblem bei der Replikation nach authoritativen Restores zu beheben:

974803 The domain controller runs slower or stops responding when the garbage collection process runs

https://support.microsoft.com/default.aspx?scid=kb;EN-US;974803

Ungewollte Löschungen verhindern

Die meisten Fälle von Restores in unserer Support Praxis betreffen unabsichtlich gelöschte Objekte, meist ganze OUs mit Benutzer- und Gruppen-Konten. Das Thema hat Microsoft in Windows 2008 und Vista RSAT (Remote Server Administration Toolkit) angegangen. Die neue Version der Admin Tools bietet im Reiter Allgemein (General) eine Option zum Schützen vor unbeabsichtigter Löschung einer OU.

Damit werden auf der OU selbst und der Parent OU ACEs (Access Control Entries) eingetragen, die "Jeder" das Löschen des Objekts bzw. Kindobjekts verbietet. Das funktioniert auch schon mit Windows 2003, und auch mit selbst geschriebenen Tools und Scripts, solange die ACEs so beschaffen sind, wie vom Administrationstool geschrieben.

Somit kann die OU mehr unabsichtlich gelöscht werden, denn der (delegierte) Admin muss zuerst den Haken entfernen. Er wird dann kaum sagen können, dass es keine Absicht war.

Die Zukunft

In der Zukunft will Microsoft einen Schritt weiter gehen und einen Papierkorb für AD Objekte anbieten, in der Version die Windows 2008 R2 heißen wird. Es gibt bereits erste Informationen dazu, in diesem Release steht vor allem die Grundfunktionalität im Vordergrund, eine schöne Benutzerschnittstelle wird nachgeliefert.

Für den Papierkorb ändert sich das Speicherformat der Objektlinks in der Datenbank, deswegen wird es nötig sein, im Windows 2008 R2 Forest Mode zu sein. Es müssen dann auch alle Domain Controller dieses Betriebssystem verwenden.

Bis dieser Forest Mode erreicht ist, bleibt erst einmal die Restores richtig vorzubereiten und zu üben...

Comments

  • Anonymous
    January 01, 2003
    Hallo Michel, Danke für das Lob!

Hallo Tom, Ich wollte den Blog Beitrag für Windows 2003 und 2008 verfassen. Datenbank-Snapshots gibt es aber nur bei Windows 2008. Da Microsoft selber kein solches Snapshot-Vergleichstool mit Synchronisier-Funktion hat, habe ich diese Möglichkeit nicht erwähnt. Dass es jenseits von NTDSTUIL und LDIFDE verschiedene, auch kostenpflichtige, Lösungen gibt, dürfte ja bekannt sein. Eine solche Objekt-Wiederherstellung kann zum Beispiel auch Teil eines Provisioning Tools sein. Schöne Grüße, Herbert

  • Anonymous
    January 01, 2003
    Hallo Roland! Ein solches Objektverzeichnis kann hilfreich sein um sicher zu stellen, dass man auch alle Objekte restauriert hat. Das Problem ist aber meistens, dass ohne größere Verrenkungen (siehe die verschiedenen Ansätze in Artikel 840001) teilweise Objektdaten fehlen. Schöne Grüße Herbert

  • Anonymous
    January 01, 2003
    Es gibt einen neuen Hotfix für NTDSUTIL, der in der Folge von großen authoritativen Restores benötigt wird: 974803 The domain controller runs slower or stops responding when the garbage collection process runs http://support.microsoft.com/default.aspx?scid=kb;EN-US;974803

  • Anonymous
    February 06, 2009
    Hallo Herbert, Fabian & co Schön ausgearbeiteter Artikel! Finde ihr habt den "harten Brocken" AD Restore sehr gut gemeistert ;-) Grüsse aus der Schweiz Michel

  • Anonymous
    February 09, 2009
    Was meint ihr denn hierzu: http://lindstrom.nullsession.com/?page_id=11

  • Anonymous
    March 19, 2009
    The comment has been removed