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 restore hergestellt. 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 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.
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 in der Root-Domäne 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
Microsoft veröffentlicht im Herbst 2009 sein nächstes Serverbetriebssystem namens Windows Server 2008 R2. Das Minor Release wird ausschließlich in der x64-Bit Version und nicht mehr wie bisher in der 32-Bit Version erscheinen.
Ein Highlight-Feature im neuen Serverbetriebssystem stellt der Active Directory-Papierkorb dar, mit dem gelöschte Objekte samt allen Informationen (inklusive der Backlinks, wie z.B. die Gruppenmitgliedschaften eines Benutzers) wiederhergestellt werden können. Somit hat ein versehentliches löschen von Active Directory-Objekten in den Active Directory Domain Services (AD DS) und Active Directory Lightweight Directory Services (AD LDS, ehemals Active Directory Application Mode, kurz ADAM) keine weiteren Folgen. Weder entsteht bei der Wiederherstellung ein Verlust von Informationen, noch muss dafür der DC im Modus Verzeichnisdienstwiederherstellung gestartet werden.
Die Voraussetzung um dieses Feature nutzen zu können, ist der Gesamtstrukturfunktionsmodus Windows Server 2008 R2. Das bedeutet, alle Domänencontroller (DC) in allen Domänen einer Gesamtstruktur müssen unter Windows Server 2008 R2 betrieben werden.
Was ist möglich
-
Ein Windows Server 2008 R2 DC kann als zusätzlicher Domänencontroller zu einer Windows 2000 32bit Domäne hinzugefügt werden.
-
Ein Windows Server 2008 R2 DC kann als zusätzlicher Domänencontroller einer Windows Server 2003 bzw. Windows Server 2003 R2 Domäne hinzugefügt werden. Dabei können die bestehenden DCs sowohl unter einem 32bit, 64bit als auch iA64 Serverbetriebssystem betrieben werden.
-
Ein Windows Server 2008 R2 DC kann als zusätzlicher Domänencontroller einer Windows Server 2008 Domäne hinzugefügt werden. Die bereits existierenden DCs können ebenfalls unter 32bit, 64bit oder iA64 laufen.
-
Ein Windows Server 2003 ab SP2 64bit DC oder Windows Server 2003 R2 mit SP2 64bit DC kann per Inplace-Update auf Windows Server 2008 R2 aktualisiert werden.
-
Ein 64bit Windows Server 2008 DC kann per Inplace-Update auf Windows Server 2008 R2 aktualisiert werden.
-
Ein 64bit Windows Server 2008 Core DC kann per Inplace-Update auf einen Windows Server 2008 R2 Core aktualisiert werden.
Hinweis 1: Auch wenn die Mindestvoraussetzung für ein Inplace-Update ein Windows Server 2003 SP2 ist, sollte das System natürlich vor dem Update auf dem aktuellen Service Pack- sowie Patch-Stand sein. Wobei es ohnehin ratsam wäre, die Domänenaktualisierung durch einen zusätzlichen DC durchzuführen.
Hinweis 2: Vor einem Inplace-Update muss überprüft werden, ob auf dem DC die installierten Applikationen auch weiterhin unter Windows Server 2008 R2 noch funktionieren. Ein Telefonat mit dem Hersteller der Applikation sollte das schnell klären.
Was ist nicht möglich
- Ein Inplace-Update von Windows NT auf Windows Server 2008 R2 wird nicht unterstützt. Es müsste zuerst ein Inplace-Update des NT-PDCs auf Windows Server 2003 SP1/SP2/2003 R2 und anschließend auf Windows Server 2008 R2 durchgeführt werden. Oder man migriert mit ADMT in eine Windows Server 2008 R2 Domäne.
Durch die Änderung des Secure Channel (die Option "Secure channel: Require strong (Windows 2000 or later) session key" wurde nun mit Windwos Server 2008 R2 hard coded und lässt sich nicht mehr abschwächen wie es noch unter Windows Server 2008 möglich ist) zugunsten der Sicherheit ist es nicht mal möglich, Windows NT Clients sowie NT Mitgliedsserver in einer Windows Server 2008 R2 Domäne zu betreiben! Des Weiteren kann auch keine Vertrauensstellung zwischen einer Windows Server 2008 R2 und einer Windows NT Domäne erstellt werden.
- Ein DC älter als ein Windows Server 2003 SP2 x64-System, kann nicht per Inplace-Update auf Windows Server 2008 R2 aktualisiert werden.
- Ein Inplace-Update von Windows Server 2003 SP1/SP2/2003 R2 x64 oder Windows Server 2008 x64 Vollinstallation (kein Server Core), ist auf den Windows Server 2008 R2 Core nicht möglich.
- Ein Inplace-Update eines x64 Windows Server 2008 Core DCs kann nicht auf Windows Server 2008 R2 Vollinstallation durchgeführt werden.
Windows Server 2008 Core
- Ein Cross-Update von einem x86 auf x64 System wird nicht unterstützt. Ebenso wenig wie von einem iA64 auf x64 System. Das bedeutet, es ist nicht möglich auf einem 32bit Windows Server 2003 SP1/SP2/2003 R2/2008 DC eine Windows Server 2008 R2 DVD einzulegen, um das System per Inplace-Update zu aktualisieren.
- Ein Cross-Update auf eine andere Betriebssystem-Sprache wird nicht unterstützt. Als Beispiel: Auf einem deutschen Windows Server 2003 SP2 x64 DC wird die englische Windows Server 2008 R2 DVD eingelegt um den DC, auf einen englischen Windows Server 2008 R2 DC zu aktualisieren.
Die Voraussetzungen für eine Windows 2000/2003/2003 R2/2008 Gesamtstruktur, damit der erste Windows Server 2008 R2 DC hinzugefügt werden kann
- Die Domäne in der man den Windows Server 2008 R2 DC hinzufügen möchte, muss sich im einheitlichen Domänenfunktionsmodus (entweder Windows 2000 pur, Windows Server 2003 oder Windows Server 2008) befinden. Denn wenn sich die Domäne nicht im einheitlichen Domänenfunktionsmodus befindet, lässt sich der Befehl Adprep /Domainprep /Gpprep nicht ausführen. In welchem Modus sich der Gesamtstrukturfunktionsmodus befindet, spielt dabei keine Rolle.
- Ist jedoch der Einsatz eines Windows Server 2008 oder Windows Server 2008 R2 RODCs in der Gesamtstruktur geplant, so ist das erst ab der Gesamtstrukturfunktionsebene Windows Server 2003 möglich. Des Weiteren muss sich bereits ein Windows Server 2008 DC oder Windows Server 2008 R2 DC in der Domäne befinden, in der man den RODC hinzufügen möchte.
- Alle Domänencontroller in der Gesamtstruktur sollten sich mindestens auf Windows 2000 Server mit Service Pack 4 oder höher befinden.
Schritt für Schritt-Anleitung für eine 32bit oder x64 Windows 2000/2003/2003 R2/2008 Gesamtstruktur, damit der erste Windows Server 2008 R2 DC hinzugefügt werden kann
-
Zuerst muss das Active Directory Preparation Tool (kurz ADPREP), das sich auf der Windows Server 2008 R2 DVD im Verzeichnis <DVD-Laufwerk>:\Support\Adprep befindet, mit dem Parameter /Forestprep auf dem Schema-Master ausgeführt werden. Allerdings befinden sich im Adprep-Verzeichnis zwei ADPREP-Dateien. Eine „Adprep.exe“ für x64-DCs und eine „Adprep32.exe“ für 32bit-DCs. Mit ausführen von Adprep32 /Forestprep auf einem 32bit Schema-Master, wird die Gesamtstruktur auf Windows Server 2008 R2 aktualisiert. Befindet sich der Schema-Master auf einem x64 DC, so lautet der Befehl Adprep /Forestprep.
Hinweis: Im weiteren Verlauf des Artikels wird die x32Bit Version des Adpreps angegeben, da sicherlich in den meisten Unternehmen noch hauptsächlich 32bit DCs existieren.
Der Parameter /Forestprep muss und kann nur ein einziges Mal in der Gesamtstruktur ausgeführt werden. Dabei muss das Benutzerkonto mit dem das ADPREP ausgeführt wird, Mitglied der folgenden drei Gruppen sein:
- Organisations-Admins
- Schema-Admins
- Domänen-Admins in der Domäne, in der der Schema-Master Mitglied ist Ruft man das Adprep32 /Forestprep nicht auf dem Schema-Master auf, bringt das Tool den Hinweis, dass die Gesamtstrukturaktualisierung nur auf dem Schema-Master durchgeführt werden kann und bricht den Vorgang ab. Microsoft empfiehlt das Verzeichnis „Adprep“ (mit dem kompletten Inhalt!) vorher auf den DC zu kopieren, um z.B. Lesefehler des DVD-Laufwerks während der Ausführung von Adprep zu vermeiden.
An error occurs when you run the ADPREP/FORESTPREP command on a Windows Server 2003-based or Windows Server 2008-based computer: "An attribute with the same link identifier already exists"
-
Das Adprep32 /Forestprep aktualisiert die Gesamtstruktur auf Windows Server 2008 R2, in dem neue Attribute sowie Klassen dem Schema hinzugefügt bzw. bestehende (z.B. die Berechtigungen) geändert werden. Nach dem Aufruf von Adprep32 /Forestprep werden abhängig von der Schema-Version die LDF-Dateien, die zur Schema-Aktualisierung benötigt werden, aus dem Verzeichnis „Support\Adprep“ auf dem DC in das Verzeichnis „%windir%\system32“ kopiert.
In einer Windows 2000 Gesamtstruktur werden die LDF-Dateien ab sch14.ldf, in einer Windows Server 2003 ab sch31.ldf, in einer Windows Server 2003 R2 ab sch32.ldf und in einer Windows Server 2008 Umgebung ab sch45.ldf bis zur sch47.ldf in das Schema importiert. Das Schema wird somit auf die Version 47 aktualisiert.
Die Schema-Versionen sind (in Dezimal):
- Schema-Version 13 = Windows 2000 RTM mit allen Service Packs
- Schema-Version 30 = Windows Server 2003 RTM mit allen Service Packs
- Schema-Version 31 = Windows Server 2003 R2 RTM mit allen Service Packs
- Schema-Version 44 = Windows Server 2008 RTM mit allen Service Packs
- Schema-Version 47 = Windows Server 2008 R2 mit allen Service Packs
Die Schema-Version kann man sich auf jedem DC in der Gesamtstruktur zum einen in der Registry in dem folgenden Pfad ansehen:
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\<Schema Version> Zum anderen lässt sich im Attribut objectVersion, das sich in den Eigenschaften der Schema-Partition CN=Schema,CN=Configuration,DC=<Root-Domäne>,DC=<TLD> befindet, die Schemaversion anzeigen (z.B. mit ADSIEdit.msc oder LDP.exe).
Auch mit Dsquery lässt sich die Schema-Version abfragen. Der Befehl lautet wie folgt:
dsquery * CN=Schema,CN=Configuration,DC=Root-Domäne -Scope Base -attr objectVersion
-
Wenn das Adprep32 /Forestprep durchgeführt wurde, wird in der Konfigurationspartition der Container CN=ActiveDirectoryUpdate,CN=ForestUpdates,CN=Configuration,DC=<Root-Domäne> erstellt. Der Container selbst bleibt leer. Das Attribut Revision in den Eigenschaften des Containers CN=ActiveDirectoryUpdate erhält den Wert 5. Danach sollte sichergestellt werden, dass sich dieser Container zuerst auf alle DCs der Gesamtstruktur repliziert, um dann den nächsten Schritt mit Adprep durchzuführen.
In erster Linie sollten die DC`s der einzelnen Domänen die Aktualisierung empfangen haben, die die FSMO-Rolle des Infrastruktur-Master innehaben. Dazu gilt es den nächsten Punkt zu beachten.
Hinweis für Windows Server 2008 Umgebungen: Falls schon ein Windows Server 2008 DC in der (z.B. Windows 2000 oder Windows Server 2003) Domäne besteht oder es sich um eine reine Windows Server 2008 Umgebung handelt, existiert bereits der Container CN=ActiveDirectoryUpdate. Das Attribut Revision enthält dagegen als Wert 2. Wird nun das Adprep32 /Forestprep von der Windows Server 2008 R2 DVD ausgeführt, wird der Wert auf 5 geändert.
Hinweis: Im Gegensatz zu Windows Server 2008 Zeiten kann nun auch auf einem deutschen Schemamaster das ADPREP von einer englischen Windows Server 2008 R2 DVD ausgeführt werden. Zu Zeiten Windows Server 2008 gab es an dieser Stelle ein Sprach-Problem und nach dem Ausführen von ADPREP passierte einfach nichts, es erschien noch nicht einmal eine Fehlermeldung. Aber: Existiert ein englischer Schemamaster und man führt das ADPREP von einer deutschen Windows Server 2008 R2 DVD aus, besteht der Fehler weiterhin. Der Cursor blinkt in der nächsten Zeile ohne das irgendetwas passiert. Besteht ein englischer Schemamaster, kann man entweder den Schemamaster auf einen deutschen DC verschieben und danach das ADPREP von einer deutschen DVD ausführen oder man führt das ADPREP gleich von einer englischen DVD aus!
ADPREP "multi-language"
-
Im zweiten Schritt muss das Adprep32 mit den Parametern /Domainprep /Gpprep auf dem Infrastruktur-Master in der Domäne, in der man den Windows Server 2008 R2 als DC hinzufügen möchte, ausgeführt werden. Das Benutzerkonto, mit dem dieser Befehl ausgeführt wird, muss Mitglied der Sicherheitsgruppe Domänen-Admins sein. Mit Ausführen von /Domainprep /Gpprep wird die Domäne auf Windows Server 2008 R2 aktualisiert. Der Parameter /Domainprep bewirkt, dass neue Objekte erstellt sowie die ACLs an diversen Objekten in der Domänenpartition geändert werden. Der Parameter /Gpprep sorgt dafür, dass die Berechtigungen der Gruppenrichtlinienobjekte die sich im Sysvol-Verzeichnis befinden, angepasst werden. Führt man diesen Befehl aus, noch bevor die Gesamtstrukturaktualisierung auf den Infrastruktur-Master repliziert wurde, bricht der Vorgang ab. Dieser bricht auch dann ab, wenn der Befehl nicht auf dem Infrastruktur-Master ausgeführt wird. Durch Ausführen dieses Befehls wird der folgende Container in der Domänenpartition erstellt: CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System,DC=<Domäne>
Auch dieser Container bleibt leer. Das Attribut Revision das sich in den Eigenschaften des Containers CN=ActiveDirectoryUpdate befindet, bekommt ebenfalls den Wert 5. Es ist möglich zuerst das Adprep lediglich mit dem Parameter /Domainprep auszuführen und zu einem späteren Zeitpunkt die Berechtigungen der GPOs, mit Adprep /Domainprep /Gpprep zu aktualisieren. Empfehlenswert ist jedoch, beide Parameter in einem Schritt durchzuführen.
Hinweis für Windows Server 2008 Umgebungen: Wenn sich aber bereits ein Windows Server 2008 DC in der (z.B. Windows 2000 oder Windows Server 2003) Domäne befindet oder es sich um eine reine Windows Server 2008 Umgebung handelt, besteht bereits der Container CN=ActiveDirectoryUpdate in der Domänenpartition. Der Wert im Attribut Revision wird dann von 3 auf 5 geändert. In den Umgebungen wo bereits ein Windows Server 2008 DC existiert, ist es auch nicht notwendig den Parameter /Gpprep auszuführen, da bereits die Berechtigungen der GPOs im Sysvol-Verzeichnis angepasst wurden. Das gilt aber nur für die Umgebungen, in denen bereits beim hinzufügen des zusätzlichen Windows Server 2008 DCs der Parameter /Gpprep mit angegeben wurde. In einer Windows Server 2008 Domäne ist der Parameter /Gpprep ohnehin nicht notwendig. Es ist aber nicht weiter tragisch wenn der Parameter doch mit angegeben werden sollte, denn der Assistent bringt lediglich den Hinweis, dass die Berechtigungen der GPOs bereits angepasst wurden.
-
Wenn der Einsatz eines Read-Only Domain Controllers (RODC) in irgendeiner Domäne der Gesamtstruktur geplant ist, dann ist das Adprep32 mit dem Parameter /Rodcprep lediglich einmalig aufzurufen. Der DC, auf dem dieser Befehl ausgeführt wird, muss auch nicht der Träger der FSMO-Rollen sein. Beim Ausführen dieses Befehls werden die einzelnen Infrastruktur-Master der Domänen kontaktiert, um die Berechtigungen (Security Descriptor, SD) der Domänen- sowie Anwendungsverzeichnispartitionen DomainDNSZones und ForestDNSZones zu aktualisieren.
Es reicht völlig aus, diesen Befehl erst vor dem Hinzufügen des ersten RODC`s in der Gesamtstruktur auszuführen. Das Benutzerkonto, mit dem dieser Befehl ausgeführt wird, muss Mitglied in der Sicherheitsgruppe Organisations-Admins sein. Nach Ausführung von /Rodcprep wird der folgende Container, der ebenfalls leer bleibt, erstellt:
CN=ActiveDirectoryRodcUpdate,CN=ForestUpdates,CN=Configuration,DC=<Root-Domäne>.
Das Attribut Revision in den Eigenschaften des Containers, erhält als Wert 2.
Hinweis für Windows Server 2008 Umgebungen: Existiert bereits ein Windows Server 2008 DC in der (z.B. Windows 2000 oder Windows Server 2003) Domäne oder handelt es sich um eine reine Windows Server 2008 Umgebung, so kann ein Windows Server 2008 R2 als RODC zur Domäne hinzugefügt werden. Es ist nicht unbedingt notwendig, dass bereits ein Windows Server 2008 R2 DC in der Domäne besteht um einen Windows 2008 R2 als RODC zur Domäne hinzuzufügen. Denn die Voraussetzungen um einen RODC zur Domäne hinzuzufügen sind schließlich, dass sich der Gesamtstrukturfunktionsmodus mindestens auf „Windows Server 2003“ befindet, sich bereits ein Windows Server 2008 DC in der Domäne befindet und das Adprep32 /Rodcprep ausgeführt wurde.
Read-Only Domain Controller (RODC)
Die Installation eines RODC
-
Wird eine neue Gesamtstruktur unter Windows Server 2008 R2 erstellt, so ist das Ausführen von Adprep/Adprep32 keineswegs notwendig. Weder der Parameter /Forestprep, noch /Domainprep /Gpprep oder /Rodcprep müssen angewendet werden.
-
Es wird bei jedem Ausführen von Adprep im Verzeichnis %Systemroot%\Debug\Adprep\Logs ein Ordner erstellt, dass als Namen das aktuelle Datum sowie die Uhrzeit erhält. Darin befindet sich (neben anderen) das Adprep-Protokoll mit dem Namen ADPrep.log, welches einen detaillierten Bericht zum Vorgang liefert. Wenn Adprep abbrechen oder einen Fehler melden sollte, ist dieses Protokoll bei der Fehlersuche hilfreich.
Debug Protokollierung
-
Nach der Domänenaktualisierung auf Windows Server 2008 R2, kann nun der neue Server als "zusätzlicher DC der bestehenden Domäne" hinzugefügt werden. Während dem Heraufstufen zum DC sollte an entsprechender Stelle, dass DNS mit installiert und zusätzlich der globale Katalog aktiviert werden. Anschließend sollten noch die FSMO-Rollen auf den Windows Server 2008 R2 DC verschoben werden.
Globaler Katalog (Global Catalog – GC)
Der PDC-Emulator
Die FSMO-Rollen verschieben
Szenario 1
Eine Domänenaktualisierung von Windows 2000 auf Windows Server 2008 R2 durchführen
- In einer Windows 2000 Active Directory Umgebung kann die Domänenaktualisierung auf Windows Server 2008 R2 über einen zusätzlichen Windows Server 2008 R2 DC realisiert werden. Dazu ist zuerst die Schritt für Schritt-Anleitung die am Anfang dieses Artikels beschrieben ist durchzuführen. Anschließend kann ein Windows Server 2008 R2 als zusätzlicher Domänencontroller der bereits bestehenden Domäne hinzugefügt werden.
- Es ist zuerst ein Inplace-Update von Windows 2000 auf Windows Server 2003 mit mindestens dem Service Pack 2 (besser aktueller) durchzuführen. Erst dann kann per Inplace-Update auf Windows Server 2008 R2 aktualisiert werden, natürlich auch erst nach Ausführung der Schritt für Schritt-Anleitung.
Szenario 2
Eine Domänenaktualisierung von Windows Server 2003 auf Windows Server 2008 R2 durchführen
- Wie in einer Windows 2000 Gesamtstruktur sollte auch in einer Windows Server 2003 Gesamtstruktur die Domänenaktualisierung über einen zusätzlichen Windows Server 2008 R2 Domänencontroller erfolgen. Selbstverständlich auch nur dann, wenn die Schritt für Schritt-Anleitung durchgeführt wurde.
- Ist mindestens das Service Pack 2 für den Windows Server 2003 auf dem DC installiert, so kann mit einem Inplace-Update der Windows Server 2003 DC auf Windows Server 2008 R2 aktualisiert werden. Die Schritt für Schritt-Anleitung die am Anfang dieses Artikels beschrieben wird, ist dabei zuerst durchzuführen.
Szenario 3
Eine Domänenaktualisierung von Windows Server 2003 R2 auf Windows Server 2008 R2 durchführen
- Da in einem Windows Server 2003 R2 ein Windows Server 2003 mit mindestens dem Service Pack 2 enthalten ist, kann nach vorheriger Ausführung der Schritt für Schritt-Anleitung ein zusätzlicher Windows Server 2008 R2 DC zur bestehenden Domäne hinzugefügt werden.
- Des Weiteren kann ein Windows Server 2003 R2 SP2 DC per Inplace-Update auf Windows Server 2008 R2 aktualisiert werden, wenn vorher die Schritt für Schritt-Anleitung durchgeführt wurde.
Szenario 4
Eine Domänenaktualisierung von Windows Server 2008 auf Windows Server 2008 R2 durchführen
- Eine Domänenaktualisierung kann durch hinzufügen eines zusätzlichen Windows Server 2008 R2 DCs durchgeführt werden. Die Schritt für Schritt-Anleitung am Anfang des Artikels gilt es zuerst durchzuführen. Hier in Kurzform: Zuerst muss auf dem Schema-Master das Adprep32 /Forestprep und auf dem Infrastruktur-Master das Adprep32 /Domainprep ausgeführt werden.
- Ein Windows Server 2008 DC kann auch per Inplace-Update auf Windows Server 2008 R2 aktualisiert werden. Vorher muss ebenfalls auf dem Schema-Master das Adprep32 /Forestprep und auf dem Infrastruktur-Master das Adprep32 /Domainprep durchgeführt werden.
Szenario 5
Eine Domänenaktualisierung von einem x64Bit Windows Server 2008 Core auf Windows Server 2008 R2 Core durchführen
-
Die Domänenaktualisierung kann hier ebenfalls durch hinzufügen eines zusätzlichen Windows Server 2008 R2 Core DCs erfolgen. Natürlich muss auch in diesem Fall vorher das ausführen von Adprep32 /Forestprep auf dem Schema-Master und das Adprep32 /Domainprep auf dem Infrastruktur-Master erfolgen.
-
Der x64Bit Windows Server 2008 Core DC lässt sich per Inplace-Update auf einen Windows Server 2008 R2 Core aktualisieren. Auch hier gilt es im ersten Schritt auf dem Schema-Master das Adprep /Forestprep und im zweiten, auf dem Infrastruktur-Master das Adprep /Domainprep auszuführen.
Szenario 6
Eine Windows Server 2008 R2-Subdomäne in einer Windows 2000/2003/2003 R2/2008 Gesamtstruktur erstellen
- Soll in einer Gesamtstruktur die erste Windows Server 2008 R2-Domäne und somit der erste Windows Server 2008 R2-DC zur Gesamtstruktur hinzugefügt werden, so muss lediglich auf dem Schema-Master das Adprep /Forestprep ausgeführt werden. Anschließend kann mit dem Windows Server 2008 R2 die Subdomäne erstellt werden.
Befindet sich in einer Windows 2000 Umgebung die FSMO-Rolle des Domänennamenmasters auf einem Windows 2000 DC, wird das Attribut msDS-BehaviorVersion im entsprechenden crossRef-Objekt nicht aktualisiert, wenn eine Subdomäne bzw. eine neue Domänenstruktur (Tree) unter Windows Server 2008 oder Windows Server 2008 R2 erstellt wird. In diesem Fall kann es bei einigen Anwendungen zu Kompatibilitätsproblemen kommen. Insbesondere wenn mit DCDIAG die AD-Replikation überprüft werden soll, schlägt der Replikationstest fehl. Die Abhilfe dieses Problems ist, die Rolle des Domänennamenmasters entweder auf einen Windows Server 2003, Windows Server 2008 oder Windows Server 2008 R2 DC zu übertragen, bevor eine neue Subdomäne bzw. eine neue Domänenstruktur (Tree) erstellt wird.
Weitere Informationen:
Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen
Migration von Windows Server 2000 auf Windows Server 2003 (Inplace-Update)
Schemaupdate beim Windows Server 2003 R2
Einen zusätzlichen DC in die Domäne hinzufügen
Die AD-Powershell im Windows Server 2008 R2
Das Active Directory Preparation Tool – ADPREP
Domänen- und Gesamtstrukturfunktionsmodus
Windows Server 2008 R2 Upgrade Paths
Upgrading Active Directory Domains to Windows Server 2008 and Windows Server 2008 R2 AD DS Domains
Microsoft hat auf 563 Seiten den Active Directory Domain Services Operations Guide veröffentlicht.
Darin erhält man Informationen über die Administration und Verwaltung einer Active Directory Domain Services (AD DS) Umgebung unter Windows Server 2008.
Den Download zum Whitepaper findet ihr hier:
Active Directory Domain Services Operations Guide
Viel Spass beim lesen.
So einfach wie die Frage im ersten Moment klingt, so schwierig ist sie zu beantworten. Gleich vorweg, letztendlich lässt sich diese Frage nicht pauschal beantworten, denn es gibt keine Faustformel dazu, die Anzahl der benötigten Domänencontroller (DCs) zu berechnen.
Aber eins kann man mit Gewissheit empfehlen, jede Domäne muss wegen der Ausfallsicherheit und Verfügbarkeit mindestens zwei DCs enthalten!
Damit ist zumindest sichergestellt, dass bei einem DC-Crash der zweite DC die Domäne noch am Leben erhält. In vielen Umgebungen wird die Anzahl der DCs an der Ausfallsicherheit, der Standortverteilung oder der Anzahl der Benutzer pro Standort bestimmt. Die Bandbreitenanbindung bei bestehen von mehreren Standorten ist für die Anzahl an DCs, ebenfalls von elementarer Bedeutung.
Es kommt bei der Ermittlung der genauen Anzahl an DCs immer auf die Umgebung an.
Wie viele DCs in der Domäne benötigt werden, hängt außerdem von den Ansprüchen des Unternehmens ab. Natürlich hat ein großes Unternehmen mit vielen Standorten andere Ansprüche bzgl. der hohen Verfügbarkeit, Fehlertoleranz sowie Redundanz, als kleinere und mittlere Unternehmen (KMU) mit vielleicht nur einem Standort.
Die folgenden Kriterien helfen bei der Definition der Anzahl an DCs pro Domäne:
-
Wie viele AD-Standorte existieren?
-
In wie vielen Ländern?
-
Mit welcher (stabilen?) Bandbreite?
-
Wie viele Benutzer existieren pro Standort?
-
Wie viel Last besteht auf den DCs während der Benutzerauthentifizierungen?
-
Existiert eine Exchange-Umgebung?
-
Existieren Applikationen die vom AD abhängig sind?
-
Gibt es Standorte, die besonders AD-lastig arbeiten?
-
Existieren Standorte, in denen mehr gesamtstrukturweite Abfragen, sprich der globale Katalog überwiegend beansprucht wird?
-
Besteht aktuelle Hardware für die Domänencontroller?
Alle diese Faktoren helfen die Anzahl der DCs innerhalb einer AD-Domäne festzulegen. Jedoch schließt das Installieren von mehreren DCs natürlich keineswegs eine regelmäßige Datensicherung des System-State aus. Diese muss ohnehin durchgeführt werden. Die Sicherung des Systemstatus ist das Mindeste, was auf einem DC gesichert werden muss!
Bei der Hardware der DCs kommt es insbesonders auf die CPU (welcher Prozessor und wie viele existieren?), Festplattenspeicher und vor allem dem Arbeitsspeicher an. Denn idealerweise sollte die Active Directory-Datenbank „NTDS.dit“ in den Arbeitsspeicher geladen werden können. Dabei läuft das Active Directory in dem LSASS Prozess.
Microsoft stellt auf der folgenden Seite seine Tests dar, die sie vor einigen Jahren mit HP-Proliant Servern durchgeführt hatten. Dort gewinnt man ebenfalls einige Anhaltspunkte zu der benötigten Anzahl an DCs.
Determining the Minimum Number of Domain Controllers Required
Weitere Ansätze über die Anzahl und Hardwareausstattung der DCs, liefern diese Seiten:
Step B2: Determine the Number of Domain Controllers
Planning Domain Controller Capacity: Active Directory
Größere Unternehmen mit mehreren Standorten sollten sich dieses Whitepaper durchlesen:
Windows Server 2003 Active Directory Branch Office Guide
Oftmals ist es gerade in kleineren und mittleren Unternehmen so, das die Maschine die als einziger DC fungiert, nicht nur die Funktion eines DCs wahrnimmt. Dieser ist Datei- sowie Applikationsserver und wenn nicht sogar noch Mailserver zugleich (SBS). In diesen Umgebungen kann man sich oftmals keinen dedizierten zweiten DC leisten. Dabei reicht schon eine nicht ganz veraltete Client-Hardware aus, um auf diesem einen weiteren DC zu installieren (natürlich wird eine weitere Server-Lizenz benötigt). Falls dennoch kein zweiter DC installiert werden kann, ist umso mehr auf die regelmäßige und funktionierende System-State Sicherung zu achten.
Wenn es aber auf dem einzigen DC zu Performanceproblemen kommt, sollte eine Auslastungsanalyse über einen längeren Zeitraum durchgeführt werden (z.B. eine Woche). Dabei ist ein besonderes Augenmerk auf den Speicherverbrauch der Lsass.exe zu werfen. Erst nach der Analyse lässt sich ableiten, ob der DC überlastet bzw. die Hardware nicht ausreichend ist. Die Lösung könnte dann z.B. eine aktuelle Hardware, ein x64-DC oder ein weiterer DC sein. Wobei mit Blick auf das nächste Serverbetriebssystem, der Windows Server 2008 R2 ohnehin nur noch als x64-Bit Version ausgeliefert wird.
Weitere Informationen:
Memory usage by the Lsass.exe process on domain controllers that are running Windows Server 2003 or Windows 2000 Server
Die Unternehmen entwickeln sich und ihre Produkte weiter. Stetig müssen sich die Firmen an die Marktansprüche und an die Kundenwünsche anpassen, um ihr Business zu betreiben. So wie sich die Unternehmen an die Marktansprüche anpassen müssen, so muss sich auch die IT innerhalb eines Unternehmens anpassen, um den wirtschaftlichen Interessen des Unternehmens auch aus der IT-Sicht gerecht zu werden.
Die Firmen die bereits schon seit längerem eine Active Directory-Umgebung betreiben, denken vielleicht darüber nach ihre Gesamtstruktur zu verändern. Ihre schon in die Jahre gekommene Struktur spiegelt evtl. die heutigen Ansprüche des Unternehmens nicht wieder. Für die damalige Zeit war das gewählte Multidomänenmodell vielleicht notwendig und das richtige Domänenmodell. Aber heute ist das damals gewählte Domänendesign in die Jahre gekommen und genügt evtl. weder den heutigen Ansprüchen, noch ist es zeitgerecht.
Es kann viele Gründe dafür geben, warum eine Umstrukturierung der Gesamtstruktur sinnvoll wäre. Ein weiterer Grund für das Re-Design der Umgebung wäre z.B. der Domänenname. Eine Migration in eine neue Gesamtstruktur ist in vielen Umgebungen sinnvoller, als den Domänennamen zu ändern. Oder wenn Firmen fusionieren und die eine Firma in die andere migriert werden soll.
Ist erst mal die Entscheidung getroffen den Schritt einer Umstrukturierung zu gehen, sei es innerhalb einer Gesamtstruktur (Intra-Forest) oder in eine neue Gesamtstruktur zu migrieren (Inter-Forest, zwischen zwei Gesamtstrukturen), so gilt es als einer der nächsten Schritte das richtige Migrationswerkzeug zu wählen.
Auf der Suche im Internet nach einem Migrationstool stößt man recht schnell auf das kostenlose Werkzeug von Microsoft. Das Tool nennt sich Active Directory Migration Tool - ADMT. Aber neben dem ADMT stolpert man unter anderem über das kommerzielle Werkzeug aus dem Hause Quest. Der Quest Migration Manager for Active Directory (kurz QMMAD) ist das Pendant zu ADMT und kann einiges mehr als das wohlgemerkt kostenlose Tool von Microsoft. Aber neben Quest wäre noch das Migrationswerkzeug von NetIQ zu erwähnen (was hier jedoch nicht berücksichtigt wird).
Migrationsmöglichkeiten
Eine Domänenmigration kann auf verschiedene Wege mit verschiedenen Werkzeugen erfolgen. Viele Unternehmen nehmen eine Domänenmigration auch zum Anlass, ihre Daten neu zu organisieren. Denn durch die Jahre entstand auf manchen Fileservern evtl. diverser Daten-Wildwuchs, den es neu zu strukturieren gilt. Die Migration muss natürlich ohne größere Auswirkungen auf die produktiven Einheiten und möglichst unauffällig verlaufen.
1. Die Migration mit Hilfe von Skripten
Einige Unternehmen migrieren ihre Benutzer-, Gruppen- sowie Computerkonten mit ADMT in die neue Domäne. Die File- bzw. Ressourcenserver fügen sie händisch der Ziel-Domäne hinzu und führen anschließend das sogenannte Re-ACLing (=Rechte neu setzen) ihrer Netzwerkressourcen (Dateien, Drucker etc.), mit Skripten durch. Dabei kommt oft ein Computer-Startupskript zum Einsatz.
2. Die Migration mit der SIDHistory
Je nach Größe bzw. Dauer der Migration ist es evtl. notwendig, dass die bereits migrierten Benutzer noch auf die Ressourcen in der Quell-Domäne zugreifen können. Damit während der Migrationsphase die bereits migrierten Benutzer, sei es bei einer Intra- oder Inter-Forest Migration, weiterhin Zugriff auf die Ressourcen der alten Domäne haben, wäre einer der gängigsten Varianten die während einer Migration zum Einsatz kommen, die Migration mit der SIDHistory. Dadurch kann das neue Benutzerkonto aus der neuen Domäne, auf die Ressourcen der alten Domäne zugreifen. Das Attribut SIDHistory ist ein mehrwertiges Attribut in dem eine Liste der SIDs, die zuvor einem Benutzer oder einer Gruppe zugewiesen wurden, eingetragen wird.
Mit den entsprechenden Migrationswerkzeugen, wie z.B. den im weiteren Verlauf vorgestellten Tools, können die Benutzer- und Gruppenkonten mit ihrer SID migriert werden. Dabei wird ein neues Sicherheitsprinzipal (Benutzer- oder Gruppenkonto) in der neuen Domäne erstellt und die SID des alten Sicherheitsprinzipals an das neue Konto der neuen Domäne im Attribut SIDHistory hinzugefügt. Dadurch wäre das neue Benutzerkonto in der Lage, die alte SID als "Ausweis" vorzuzeigen, wenn die neue SID des Benutzerkontos keinen Zugriff bekommt. Möchte also das "neue" Benutzerkonto aus der neuen Domäne, auf die Ressourcen der "alten" Domäne zugreifen, tritt hier die SIDHistory in Aktion.
Wird ein Benutzer von einer Domäne in eine andere migriert, so wird seine SID nicht mit übernommen, denn der mittlere Part der SID ist die Nummer der Domäne. Bei der Benutzer-Migration mit den herkömmlichen Migrationswerkzeugen wird jedesmal ein neues Benutzerkonto mit einer neuen SID in der Ziel-Domäne eingerichtet. Da das neue Benutzerkonto eine neue SID bekommen hat, bekommt das Konto nicht die gleichen Berechtigungen wie es das alte Benutzerkonto hatte, auch wenn der Benutzername gleich lautet. Denn bekanntlich sind Namen in der IT "Schall und Rauch". Dank der SIDHistory aber, müssen die Berechtigungen in der alten Domäne nicht gleich angepasst werden, denn dadurch hat das neue Benutzerkonto Zugriff auf die Ressourcen der alten Domäne.
Die SIDHistory funktioniert sogar wenn die alte Domäne nicht mehr existiert! Wenn die Verbindung zur alten Domäne aufgelöst wurde (Domäne wurde entfernt oder die Verbindung ist getrennt), werden die Berechtigungseinträge auf den Ressourcen nicht mehr im Klartext als Namen angezeigt, sondern es erscheint die SID (S-1-5-21-…). Die Berechtigungen funktionieren aber wie bereits erwähnt weiterhin. Dafür erschwert sich aber die Administration, da man nicht mehr so einfach beurteilen kann, um welches Konto es sich dabei handelt. Wie denn auch, wenn niemand mehr weiß wie die Konten hießen.
Wenn die Migration abgeschlossen ist, wäre es ohnehin empfehlenswert die SIDHistory zu bereinigen. Nach dem bereinigen der SIDHistory kann der Benutzer lediglich mit der "neuen" SID auf die Ressourcen zugreifen. Die ACL-Umsetzung sollte natürlich zu diesem Zeitpunkt bereits abgeschlossen sein.
Denn wenn sich nämlich ein Benutzer anmeldet, bekommt er ein Access-Token in dem seine richtige SID, die SIDs der SIDHistory (samt der SIDHistory aller Gruppen) und die SID's aller Gruppen, denen der Benutzer angehört (direkt oder verschachtelt), enthalten ist. Das Access-Token kann aber max. 1024 Einträge enthalten und von daher, sollte nach einer Migration die SIDHistory stets bereinigt werden. Ansonsten könnte es bei zukünftigen Migrationen zu Problemen kommen.
Zum entfernen der SIDHistory kann dazu das folgende VBSkript verwendet werden.
How To Use Visual Basic Script to Clear SidHistory
Leider ist die Handhabung mit dem Skript eher umständlich, denn die Objekte bei denen die SIDHistory entfernt werden soll, müssen einzeln angegeben werden. Aber mit etwas Skriptingkenntnisse lässt sich das Skript an die eigenen Bedürfnisse anpassen. Alternativ lässt sich die SIDHistory auch mit ADModify entfernen.
3. Die Migration mit Dual-ACL
Neben der Variante mit der SIDHistory, kommt als weitere gängige Migrationsvariante Dual-ACL häufig zum Einsatz. Auch hierbei können während der Migrationsphase die bereits migrierten Benutzer, sei es bei einer Intra- oder Inter-Forest Migration, weiterhin auf die Ressourcen der alten Domäne zugreifen. Dadurch kann das neue Benutzerkonto aus der neuen Domäne, auf die Ressourcen der alten Domäne zugreifen.
Die in diesem Artikel erwähnten Migrationstools können auch die vorhandenen Berechtigungen auf Clients oder Servern bearbeiten. Die bereits migrierten „neuen“ Benutzer- und Gruppenkonten können zusätzlich zu den vorhandenen Berechtigungen eingetragen werden (Dual ACL) oder die alten Berechtigungen auf den Ressourcen ersetzen. Mit ADMT kann das der Assistent zur Computermigration durchführen, während im QMMAD das Ressource Updating dafür zuständig ist.
Weitere hilfreiche Tools für die Migration
Je nachdem welche Migrationsstrategie und welches Migrationswerkzeug man gewählt hat, können im Nachhinein die Tools wie SUBINACL oder SIDWALK dabei helfen, die Berechtigungen zu bereinigen. Auch das ADModify kann bei Massenänderungen, die bei einer Migration notwendig sein könnten, hilfreich sein.
Die SID-Filterung bei der Inter-Forest Migration
Die SID-Filterung ist dazu gedacht, die Benutzer an der Nutzung der im Attribut SIDHistory eingetragenen SIDs daran zu hindern, um auf Ressourcen einer separaten Gesamtstruktur zuzugreifen. Die SID-Filterung zu deaktivieren stellt aber ein gewisses Sicherheitsrisiko dar, denn ein Angreifer mit Administratorrechten könnte administrative SIDs in der vertrauenden Gesamtstruktur dem Attribut SIDHistory eines Sicherheitsprinzipals in der vertrauten Gesamtstruktur hinzufügen. Damit ist es dem Konto möglich, administrativen Zugriff auf die vertraute Gesamtstruktur zu erlangen.
Mit der SID-Filterung kann die Verwendung des Attributs SIDHistory in der gesamten Gesamtstrukturvertrauensstellung bzw. externen Vertrauensstellung blockiert werden. Wenn aber das neue Benutzerkonto auf die Ressourcen der alten Domäne zugreifen möchte, muss bei einer Inter-Forest Migration die SID-Filterung ausgeschaltet sein. Die SID-Filterung sollte aber nur für einen begrenzten Zeitraum deaktiviert werden.
Die SID-Filterung lässt sich mit NETDOM, welches sich in den Windows Support Tools befindet, deaktivieren. Der Befehl lautet wie folgt:
Netdom Trust TrustingDomainName /domain:TrustedDomainName /quarantine:No /userD:Domänen-Administrator /passwordD:Domänen-Admin-Kennwort
Disable SID filter quarantining
Es wäre auch möglich, die auf die Gesamtstrukturvertrauensstellung angewendete Standard-SID-Filterung mit der Option /enablesidhistory:yes abzuschwächen.
Der genaue Befehl lautet folgendermaßen:
Netdom Trust TrustingDomainName /domain:TrustedDomainName /enablesidhistory:Yes /usero:Domänenadministratorkonto /passwordo:Domänenadministratorkennwort
Was sind die Voraussetzungen für eine Migration mit ADMT oder dem QMMAD?
- Natürlich muss zuerst auf IP-Ebene das Routing zwischen der Quell- und Ziel-Domäne funktionieren.
- Als nächstes muss die Namensauflösung zwischen der Quell- und Ziel-Domäne sichergestellt sein. Dazu könnte man im DNS entweder eine sekundäre Zone der jeweils anderen Domäne einrichten oder ab Windows Server 2003 eine bedingte Weiterleitung einrichten. Neben der DNS-Namensauflösung könnte man zusätzlich noch die NetBIOS-Namensauflösung z.B. durch eine WINS-Replikation sicherstellen.
- Idealerweise sollte eine (einseitige oder bidirektionale) Vertrauensstellung zwischen der Quell- sowie Ziel-Domäne existieren.
- Die Ziel-Domäne muss sich sowohl bei einer Intra-Forest als auch Inter-Forest Migration im einheitlichen Modus befinden. Der Grund dafür ist, da das Attribut SIDHistory in Benutzer- sowie Gruppenkonten nur im einheitlichen Modus verfügbar ist. Nur wenn sich die Ziel-Domäne im Domänenfunktionsmodus „Windows 2000 pur“, „Windows Server 2003“ oder „Windows Server 2008“ befindet, kann die SIDHistory mit Werten gefüllt werden. Wobei eine Inter-Forest Migration auch ohne die SIDHistory stattfinden kann, jedoch stellt die SIDHistory eine Art doppelter Boden dar. Denn die Migration an sich ist kompliziert und aufwändig genug, wenn man da nicht an jede Berechtigung denkt erhöht sich der administrative Aufwand im nachhinein unnötig.
Die Migration mit dem Active Directory Migration Tool - ADMT
Das ADMT existiert in der Version 2.0, 3.0 sowie 3.1. Die Installation des ADMT v2.0 kann auf Windows 2000 Server oder Windows Server 2003 erfolgen. Wobei das ADMT v3.0 nur auf Windows Server 2003 und die ADMT v3.1 nur auf Windows Server 2008 (aber nicht auf einem RODC oder Server Core) installiert werden kann.
Während der Installation von ADMT wird auch die Microsoft SQL Server Desktop Engine (MSDE) mit installiert. Das Tool kann aber so konfiguriert werden, dass es entweder die MSDE oder einen bereits bestehenden SQL-Server verwendet. Das ADMT besteht aus einer Reihe von Assistenten, die für die Migration der Objekte verwendet werden können.
Nach der Installation steht das Tool als MMC unter Start-Programme-Verwaltung-Active Directory Migration Tool zur Verfügung.
Das Benutzerkonto mit dem das ADMT ausgeführt wird, sollte Administratorrechte in der Quell-sowie Ziel-Domäne haben. Es muss bei der Migration der Computerkonten ein Agent auf den Clients installiert werden und das funktioniert natürlich nur, wenn das Konto lokale Adminrechte hat.
Das ADMT kann für eine Intra-Forest (innerhalb der Gesamtstruktur) oder Inter-Forest (zwischen zwei Gesamtstrukturen) Migration eingesetzt werden. Das Werkzeug kann über die grafische Oberfläche oder als Kommandozeilentool eingesetzt werden. Es stellt auch eine Skriptingschnittstelle bereit.
Bevor es an die produktive Migration mit ADMT geht, gilt es unbedingt vorher das Whitepaper zum Tool zu lesen und idealerweise eine Testmigration in einer Testumgebung durchzuführen.
Active Directory Migration Tool v.2.0
Active Directory Migration Tool v3.0
ADMT v3 Migration Guide
Active Directory Migration Tool version 3.1
ADMT v3.1 Guide: Migrating and Restructuring Active Directory Domains
How to troubleshoot inter-forest sIDHistory migration with ADMTv2
You find that several custom attributes are missing when you use ADMT to migrate users between two forests
Quest Migration Manager for Active Directory - QMMAD
Der Hersteller wirbt mit den Worten Zero Impact für sein Werkzeug und in der Tat fallen einem je nach Migration die Vorteile recht fix ins Auge. Das Tool welches zur Zeit in der Version 8.3 zur Verfügung steht, lässt sich einfach bedienen und es fällt schnell auf das sich vieles bei einer Intra- oder Inter-Forest Migration im Hintergrund bereits migrieren lässt, ohne dass die Benutzer etwas davon merken. Egal welche Migration durchgeführt wird, die Arbeiten können weitestgehend und ohne große Auswirkungen auf die Benutzer, im laufenden Betrieb erfolgen.
Natürlich möchte Quest bei seinen Migrationswerkzeugen sicherstellen, dass ihre Werkzeuge nur von Fachleuten, am liebsten aber (verständlicherweise) von seinen eigenen Consultants oder qualifizierten Partnern eingesetzt wird. Letztenendes aber möchte Quest seine Software schließlich an den Kunden bringen. Daher kommt es auf das Gespräch mit Quest an. Quest verkauft seinen QMMAD auch ohne Dienstleistung, möchte vorher aber vom Kunden schriftlich bestätigt bekommen, dass dieser das Werkzeug ausgiebig getestet hat. Es ist auch möglich, mit dem Hersteller einen privaten interaktiven Webcast über das Werkzeug zu veranstalten.
Damit man das Tool einsetzen kann, wird ein Lizenzfile benötigt. Das Lizenzfile kostet pro zu migrierender Benutzer 13 Euro. Je nach Anzahl sind ca. 10% Rabatt möglich. Es zählen nur die zu migrierenden Benutzerkonten. Gruppen- bzw. Computerkonten sind davon nicht betroffen. Nach einer Registrierung auf der Quest-Webseite kann man sich ein Test-Lizenzfile (begrenzt für einen bestimmten Zeitraum und für eine begrenzte Anzahl an Benutzer) zumailen lassen.
Der QMMAD setzt eine Active Directory Application Mode (ADAM)-Instanz und den IIS für ausführlichere Statistiken voraus. Bei der Standardinstallation wird ADAM gleich mit installiert und konfiguriert. Wird bei der Installation des QMMAD die benutzerdefinierte Variante gewählt, so kann eine bereits bestehende und vorbereitete ADAM-Instanz angegeben werden.
Das Quest-Tool kann sowohl bei einer Intra- als auch Inter-Forest Migration eingesetzt werden. Im Gegensatz zu ADMT kann dieses Werkzeug weitaus mehr Objekte migrieren und ist in der Anwendung komfortabler. Die ohnehin stressige Migration wird dadurch für den Administrator effizienter und flexibler. Bei den einzelnen Migrationsphasen kann ein entsprechendes Benutzerkonto das die benötigten Rechte für die jeweils auszuführende Aufgabe besitzt hinterlegt werden.
Active Directory Migration managed with Active Directory Migration Tools from Quest Software
ADMT vs. QMMAD
|
Funktion |
ADMT |
QMMAD |
Bemerkung |
|
Intra- und Inter-Forest Migration |
Bei einer Intra-Forest Migration werden die Objekte aus der Quell-Domäne entfernt. Das Objekt existiert nach der Migration nur noch in der Ziel- und nicht zusätzlich in der Quell-Domäne. Bei der Inter-Forest Migration bleiben die Objekte hingegen weiterhin in der Quell-Domäne bestehen, die deaktiviert werden können. |
Die Objekte bleiben sowohl bei einer Intra-als auch bei einer Inter-Forest Migration in der Quell-Domäne bestehen. Die Quell-Objekte können hier bei der Intra- sowie Inter-Forest Migration deaktiviert werden. |
Bei der Migration mit dem QMMAD ist man flexibler und kann vieles im Hintergrund bereits durchführen. |
|
Migration von Benutzer- und Gruppenkonten |
Ist bei einer Intra- sowie Inter-Forest Migration möglich. |
Das Quest-Tool kann ebenfalls beide Arten von Konten bei der Intra- als auch Inter-Forest Migration migrieren. |
Die Migration von Benutzer- und Gruppenkonten gehört bei beiden Tools zu den grundlegendsten Funktionen. |
|
Gesperrte Benutzerkonten migrieren |
Der Zustand eines gesperrten Benutzerkontos wird mit ADMT mit migriert. |
Nach der Migration eines gesperrten Benutzerkontos mit dem QMMAD ist das Konto anschließend nicht mehr gesperrt. |
Hierbei hat der QMMAD einen klaren Nachteil. |
|
SIDHistory |
Bei der Intra-Forest Migration ist die SIDHistory erforderlich und wird automatisch übernommen. Die SIDHistory ist bei der Inter-Forest Migration optional. |
Auch der QMMAD kann bei einer Intra- und Inter-Forest Migration mit der SIDHistory migrieren. |
Auch diese Funktion gehört zu den grundlegendsten Funktionen beider Tools. |
|
Entfernen der SIDHistory |
Das ADMT kann die SIDHistory von den Objekten nicht entfernen. |
Mit dem QMMAD kann recht einfach die SIDHistory von den Objekten entfernt werden. |
Mit dem QMMAD kann mit wenigen Mausklicks die SIDHistory von den Objekten entfernt werden (durch einen extra Durchlauf). |
|
Das lösen von Konflikten |
Mit ADMT ist die Konfliktlösung abhängig ob Intra- oder Inter-Forest Migration sehr beschränkt. |
Der QMMAD kann Konflikte z.B. durch hinzufügen eines Präfix lösen. |
Bei der Konfliktlösung (z.B. doppelter sAMAccountName) löst der QMMAD gegenüber dem ADMT einen Konflikt eleganter durch hinzufügen eines Präfix. |
|
Migration von Computerkonten |
Die Migration von Computerkonten ist bei der Intra- und Inter-Forest Migration möglich. |
Auch der QMMAD kann Computerkonten bei einer Intra- und Inter-Forest Migration migrieren. |
Auch die Migration von Computerkonten ist bei beiden Tools eines der grundlegendsten Funktionen. Beide Tools können Clients und Mitgliedsserver migrieren, aber KEINE DCs. DCs müssen aus der alten Domäne herunter- und in der neuen Domäne heraufgestuft werden. |
|
Migration der OU Hierarchie |
Das ADMT kann die OU Hierarchie aus der Quell-Domäne nicht migrieren. Die OUs müssen in der Ziel-Domäne manuell erstellt werden. Delegierungen müssten neu eingerichtet werden. |
Das Quest-Tool kann die OU Hierarchie, optional sogar mit dem Security Descriptor (sprich den Delegierungen), mit migrieren. |
Der QMMAD kann an dieser Stelle mehr als das ADMT. |
|
Verändern von Objekteigenschaften während der Migration |
ADMT kann während der Migration keine zusätzlichen Daten zu den Objekten einbinden. |
Der QMMAD kann während der Migration zusätzliche Daten zu den Objekten einbinden. |
Mit dem QMMAD könnten während der Migration zusätzliche Informationen z.B. in die Benutzerkonten eingepflegt werden. |
|
Migration der Active Directory Standort-Topologie |
AD-Standorte können mit dem ADMT nicht migriert werden. |
Mit dem QMMAD können AD-Standorte, Subnetze sowie Standortverknüpfungen migriert werden. |
Auch hier können mit dem Quest Werkzeug mehrere Objekte migriert werden. |
|
Migration der Benutzerkennwörter |
Die Kennwörter bleiben automatisch bei der Intra-Forest Migration erhalten, jedoch wird der Benutzer bei der ersten Anmeldung in der neuen Domäne aufgefordert, sein Kennwort zu ändern. Oder das Kennwort wird mit dem Password Export Server (PES) ebenfalls migriert, dann bleibt das alte Kennwort erhalten. Bei einer Inter-Forest Migration können die Kennwörter mit dem Password Export Server optional migriert werden. |
Die Benutzerkennwörter können mit dem QMMAD bei einer Intra- oder Inter-Forest Migration einfach migriert werden. |
Die Migration der Benutzerkennwörter lässt sich mit dem QMMAD einfacher als mit dem ADMT bzw. PES durchführen. |
|
Benutzerprofile |
Die Benutzerprofile bleiben erhalten. |
Die Profile der Benutzer bleiben auch hier ebenfalls erhalten. |
Die Profile werden bei der Migration der Clients übernommen. |
|
Komfortable Auswahl der Objekte |
Mit ADMT ist die Auswahl der Objekte eher eingeschränkt. |
Der QMMAD bietet starke Filtermöglichkeiten um die entsprechenden Objekte auszuwählen. |
Auch hier spielt das Quest-Werkzeug seine Stärken aus. |
|
Statistiken über Fortschritt |
Keine. |
Der QMMAD bringt ein Statistikportal mit. |
Mit dem QMMAD werden detaillierte Informationen über das Statistikportal geliefert. |
|
Undo Funktion |
Das ADMT kann nur den letzten Directory-Lauf rückgängig machen (Migration von AD-Objekten), aber nicht das Ressource Updating (RE-ACLing). |
Das Quest-Tool bietet komplette Undo-Funktionen. Jede Aktion kann rückgängig gemacht werden. |
Auch hierbei ist das Quest Werkzeug umfangreicher. |
|
Kontinuierliche Synchronisation |
Ist mit ADMT so nicht möglich. Höchstens aufwändig und eher umständlich mit Skripten und der ADMT-Skriptingschnittstelle. |
Mit dem QMMAD kann eine Synchronisation zwischen dem alten und neuen Objekt eingerichtet werden. Somit kann bei einer lang andauernden Migration ein Abgleich zwischen dem alten und neuen Objekt stattfinden. |
Gerade bei längeren Migrationsphasen ist die kontinuierliche automatische Echtzeitsynchronisation bei längeren Koexistenzphasen sehr wichtig. |
|
Konsolidiertes Ressourcen Updating |
Nicht möglich. |
Ist mit dem QMMAD möglich. |
Beim zusammenfügen von mehreren Quell-Domänen benötigt der QMMAD nur einen Durchlauf, während das ADMT pro Domäne einen Durchlauf benötigt. |
|
Client Update |
Eingeschränkt. |
Der QMMAD aktualisiert sogar die geplanten Tasks und Zertifikate auf dem Client. Zusätzlich wird die default Domäne für die Anmeldung umgestellt (im Anmeldefenster das Feld „Anmelden an“). |
Ein weiterer Vorteil bei dem Quest Werkzeug. |
|
Mitgliedsserver Aktualisierung |
Das ADMT kann das Ressource Updating für Exchange 5.5 durchführen. |
Der QMMAD kann die Berechtigungen von den folgenden Applikationen anpassen: Exchange 5.5/2000/2003. IIS. SQL 6.5/7.0/2000. SMS 2.3/2003. System Center 2007. NAS/SAN. Sharepoint 2003 und 2007. |
Das Quest-Tool kann die Berechtigungen von mehreren Applikationen anpassen. |
|
Test-Migration |
Seit ADMT 3.0 ist die Testmigration nicht mehr möglich. |
Mit dem QMMAD kann man die Migrationseinstellungen vor der produktiven Migration in einem Testlauf testen. |
Mit der Testmigration können Konfigurationsfehler aufgedeckt werden. Dies erleichtert die Fehlersuche. |
|
Auswahl von
Objekten |
Das ADMT bietet einen Standard Dialogfenster, in dem die Benutzer und Gruppen als flache Liste angezeigt werden. Die Filterung nach deaktivierten, abgelaufenen oder Systemkonten ist nicht möglich. |
Der QMMAD bietet erweiterte Filtermöglichkeiten bei der Auswahl der Objekte. Z.B. können deaktivierte und/oder abgelaufene Benutzerkonten von vornherein ausgeblendet werden. |
Gerade in größeren Umgebungen gestaltet sich die Auswahl der zu migrierenden Objekte einfacher als mit ADMT. |
|
Berechtigungen anpassen |
Das ADMT kann die folgenden Berechtigungen anpassen:
NTFS-Berechtigungen, Freigabeberechtigungen, Drucker, Registry, Profile. |
Der QMMAD kann folgende Berechtigungen anpassen:
Lokale Gruppenmitgliedschaften, Benutzer Berechtigungen, Dienste, Geplante Tasks, Registry, lokale und servergespeicherte Profile, Freigaben, Drucker, NTFS-Berechtigungen, DCOM, COM+ |
Die nötigsten Berechtigungen können beide Werkzeuge anpassen, wobei der QMMAD einiges mehr anpassen kann. |
|
Migration von Vertrauensstellungen |
Nicht möglich. |
Ist möglich. |
Ein weiteres nettes Feature des QMMAD. |
|
Fehler Analyse während der Migration |
Mit ADMT kann nach der Migration manuell ein Bericht über Konflikte erstellt werden. |
Der QMMAD gibt einen detaillierten Bericht über fehlgeschlagene Objekte, Verzeichnis Fehler, Konflikte, nicht aufgelöst Objekte (z.B. Gruppenmitglieder) sowie abgeschlossene Migrationen und Synchronisationen. |
Der detaillierte Bericht beim QMMAD erleichtert im Fehlerfall dem Administrator die Fehlersuche. |
Fazit
Mit dem ADMT lässt sich jede Umgebung, egal wie groß sie ist, sowohl bei einer Intra- als auch Inter-Forest Migration über jeden Zeitraum migrieren. Die einzelnen Migrationsschritte mit ADMT müssen insbesonders bei der Intra-Forest Migration genauer geplant werden. Zwar hat das ADMT gegenüber dem Quest-Werkzeug klar seine Einschränkungen, jedoch ist dafür das ADMT kostenlos! Die Restarbeiten können mit etwas Handarbeit (oder mit Skripten) durchgeführt werden.
Das Quest-Werkzeug bietet gerade in seinem Umfang mehr Vorteile als das ADMT. Es kann weitaus mehr Objekte migrieren als das ADMT und man kann vieles im laufenden Betrieb migrieren, ohne das die Benutzer etwas davon merken. Auch bei länger andauernden Migrationen spielt der QMMAD dank seiner Synchronisation seine Stärken aus. Des Weiteren kann dieses Werkzeug die Berechtigungen von mehreren Applikationen anpassen.
Weitere Informationen:
Microsoft Online Migration Toolkit
NetIQ Migration Suite
|
Copyright © 2012 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|