Mit Windows Server 2008 führte Redmond den Read Only Domänencontroller (kurz RODC) ein. Der RODC der für Außenstellen die eine geringe bis keine physikalische Sicherheit den Servern bieten können konzipiert wurde, ist ein Domänencontroller (DC) der ausschließlich einen lesenden Zugriff auf die Active Directory-Domänendienste (AD DS) hat. Der RODC kann keine Änderungen in den AD DS und im AD-integrierten DNS vornehmen (RODNS). Clients oder Applikationen die einen Lesezugriff auf die AD DS benötigen erhalten Zugriff auf den RODC, während Clients oder Applikationen die einen Schreibvorgang in die AD DS durchführen wollen, diesen nicht auf dem RODC durchführen können sondern vom RODC an einen beschreibbaren DC verwiesen werden.
Der RODC besitzt ein vollständiges Replikat der AD-Datenbank, mit allen Attributen und Objekten die sich auch auf einem beschreibbaren DC befinden. Neben dem Unterschied das der RODC lediglich das Leserecht auf die AD-Datenbank hat, werden im Gegensatz zu einem beschreibbaren DC standardmäßig auch keine Benutzer- oder Computeranmeldeinformationen auf dem RODC gespeichert, außer das eigene Computerkonto sowie ein besonderes krbtgt-Konto für diesen RODC. Damit die Anmeldeinformationen der entsprechenden Benutzer-, Computer- und Dienstkonten auf dem RODC gespeichert werden können, muss das explizit in der Kennwortreplikationsrichtlinie (Password Replication Policy, kurz PRP) auf einem beschreibbaren DC gestattet werden, damit der RODC Authentifizierungs- und Dienstticketanforderungen eigenständig verarbeiten kann. Mit der Kennwortreplikationsrichtlinie wird bestimmt, ob die Anmeldeinformationen eines Benutzer- oder Computerkontos von einem beschreibbaren DC auf den RODC repliziert werden können.
Weitere Informationen zum RODC bekommt man in den folgenden beiden Artikeln:
Read-Only Domain Controller (RODC)
Die Installation eines RODC
Der gefilterte Attributsatz vom RODC
Diverse Applikationen könnten die AD-Domänendienste als Datenspeicher verwenden und sensible Daten darin speichern. Oder evtl. möchte man einfach nicht, dass bestimmte Daten von Benutzern (z.B. die Adressdaten oder die Personalnummer) auf einen RODC repliziert werden. Natürlich sollen diese kritischen Daten ebenfalls geschützt sein und nicht auf einem RODC gespeichert werden, falls der RODC kompromittiert, gestohlen oder die Sicherheit gefährdet wird. Und für genau diesen Anwendungstyp gibt es den gefilterten Attributsatz. Der gefilterte Attributsatz (auf Englisch: Filtered Attribute Set, kurz FAS) ist ein dynamischer Attributsatz, die nie auf einen RODC in der Gesamtstruktur repliziert werden da sie sensible oder vertrauliche Daten enthalten. Der gefilterte Attributsatz kann aber erst ab Windows Server 2008 konfiguriert werden.
Damit ein Attribut das wichtige Daten enthält nicht auf einen RODC repliziert wird, sollten die folgenden Schritte durchgeführt werden:
-
Das entsprechende Attribut sollte zu dem gefilterten Attributsatz (FAS) hinzugefügt werden. Damit wird verhindert, dass das Attribut an die RODCs in der Gesamtstruktur repliziert wird. Die Konfiguration des gefilterten Attributsatzes betrifft die Gesamtstruktur und kann nicht pro Domäne konfiguriert werden!
-
Des Weiteren sollte das Attribut als vertraulich gekennzeichnet werden. Dies ist eine weitere Sicherheitseinstellung das konfiguriert werden sollte, wenn man nicht möchte das ein sensibles Attribut zu einem RODC repliziert werden soll! Ein Attribut wird als vertraulich gekennzeichnet, in dem die Leseberechtigung für das entsprechende Attribut für die Gruppe Authentifizierte Benutzer entfernt wird. Somit können diese Attribute von den Mitgliedern der Gruppe Authentifizierte Benutzer (das betrifft alle Benutzer- sowie Computerkonten, inklusive RODCs) nicht mehr gelesen werden. Auch die Konfiguration eines vertraulichen Attributs betrifft die Gesamtstruktur und kann nicht pro Domäne konfiguriert werden! Doch bevor ein Attribut als vertraulich gekennzeichnet wird, sollte der Vorgang in einer Testumgebung ausgiebig getestet werden!
-
Der Gesamtstrukturfunktionsmodus sollte sich aus Sicherheitsgründen mindestens auf Windows Server 2008 befinden. Denn die Attribute die sich im gefilterten Attributsatz befinden, werden nur von DCs die mindestens unter Windows Server 2008 laufen berücksichtigt! Windows Server 2003 DCs ignorieren die Konfiguration das ein Attribut geschützt ist und replizieren die Attribute die sich in dem gefilterten Attributsatz befinden trotzdem auf einen RODC. Die Domänenpartition in der sich der RODC befindet wird zwar erst ab einem beschreibbaren Windows Server 2008 DC auf den RODC repliziert, doch wenn auf dem RODC der globale Katalog (ROGC) aktiviert wird, baut sich eine eigene Replikationstopologie für die Replikation des GCs auf. Existieren in der Gesamtstruktur noch weitere Domänen mit Windows Server 2003 GCs in denen ebenfalls ein gefilterter Attributsatz konfiguriert wurde, ist es durchaus möglich das ein Windows Server 2003 GC den gefilterten Attributsatz aus seiner Domäne zu einem RODC repliziert.
-
Das Hinzufügen eines systemkritischen Attributs zum gefilterten Attributsatz ist nicht möglich! Ein systemkritisches Attribut ist ein Attribut, das z.B. für die ordnungsgemäße Funktion der AD DS oder für das Kerberos-Authentifizierungsprotokoll benötigt wird. Erst wenn in den Eigenschaften des entsprechenden Attributs im Attribut schemaFlagsEx, das aus einer Bitmaske besteht, das Flag FLAG_ATTR_IS_CRITICAL aktiviert ist, handelt es sich um ein systemkritisches Attribut. Dieses Flag existiert aber erst seit Windows Server 2008 und Windows Server 2003 DCs würden diese Einstellung ignorieren. Daher ist es umso mehr wichtig, dass sich nicht nur der Schemamaster auf mindestens einem Windows Server 2008 DC, sondern der Gesamtstrukturfunktionsmodus sich zwingend im Modus Windows Server 2008 oder höher befindet. Denn wäre der Schemamaster ein Windows Server 2003 DC, würde sich ein systemkritisches Attribut dem gefilterten Attributsatz scheinbar erfolgreich hinzufügen lassen. Aber da ein Windows Server 2003 DC die Konfiguration eines gefilterten Attributsatzes sowieso nicht kennt, sollte in einer Gesamtstruktur in der ein gefilterter Attributsatz genutzt wird ein Windows Server 2003 DC ohnehin nicht mehr existieren!
Die technische Umsetzung wie ein Attribut zum gefilterten Attributsatz hinzugefügt wird, findet wie folgt statt
-
Um ein Attribut zum gefilterten Attributsatz hinzuzufügen und somit die Replikation des entsprechenden Attributs zu einem RODC zu verwehren, muss im zu schützenden Attribut das zehnte Bit (also Bit 9) im searchFlags Attribut gesetzt werden. Im searchFlags Attribut kann unter anderem bestimmt werden, dass ein Attribut zum gefilterten Attributsatz hinzugefügt wird und das es vertraulich ist. Im searchFlags Attribut das aus einer Bitmaske besteht, muss im zehnten Bit als Wert in Hexadezimal 0x200 und in Dezimal 512 eingetragen werden. Anschließend wird das entsprechende Attribut zu keinem RODC in der Gesamtstruktur repliziert.
-
Im Attribut searchFlags liegt auch das Geheimnis, warum ein Windows Server 2003 DC die Attribute im gefilterten Attributsatz nicht berücksichtigt. Denn das zehnte Bit, also Bit 9 in searchFlags ist erst mit Windows Server 2008 und der Einführung des RODCs hinzugekommen.
-
Soll ein Attribut zum gefilterten Attributsatz hinzugefügt werden, sollte es auch als vertraulich deklariert werden. Als vertraulich deklariert und somit die Leseberechtigung den Authentifizierten Benutzern entzogen, wird ein Attribut durch das Setzen des achten Bits (Bit 7) ebenfalls im searchFlags Attribut. Dieses Flag kam mit Windows Server 2003 SP1 hinzu. Daher sollte darauf geachtet werden, dass wenn mit diesem Flag Attribute als vertraulich definiert werden, alle DCs in der Gesamtstruktur mindestens unter Windows Server 2003 SP1 installiert sind. Alle älteren Serverversionen ignorieren die Kennzeichnung als vertraulich! Im achten Bit des searchFlags Attributs muss als Wert in Hexadezimal 0x080 und in Dezimal 128 eingetragen werden.
-
Demnach erhält also searchFlags als Wert 640 in Dezimal (in Hexadezimal 0x280), damit zum einen das gewünschte Attribut zum gefilterten Attributsatz hinzugefügt und zum anderen, als vertraulich definiert wird. Trägt man als Wert 641 ein, wird zugleich das Attribut indiziert. Sollten bereits andere Flags im searchFlags Attribut konfiguriert sein, müssen die Werte addiert werden!
Den gefilterten Attributsatz abfragen
Standardmäßig befinden sich die folgenden Attribute ab Windows Server 2008 im gefilterten Attributsatz:
ms-FVE-KeyPackage
ms-FVE-RecoveryPassword
ms-PKI-AccountCredentials
ms-PKI-DPAPIMasterKeys
ms-PKI-RoamingTimeStamp
ms-TPM-OwnerInformation
Um die Attribute die sich im gefilterten Attributsatz befinden abzufragen, muss eine Abfrage nach dem Attribut searchFlags mit dem Wert 512 (das zehnte Bit in searchFlags) durchgeführt werden.
Die Abfrage mit der AD-PowerShell könnte wie folgt lauten
Get-ADObject -LDAPFilter "(objectClass=attributeSchema)" -Searchbase "CN=Schema,CN=Configuration,DC=Root-Domäne" -Properties searchFlags | Where {$_.searchFlags -band 512} | Select Name,searchFlags | Sort Name | FT -Autosize -Wrap
Auch mit diesem AD-PowerShell Befehl lassen sich die gefilterten Attribute anzeigen:
Get-ADObject -LDAPFilter "(&(ObjectClass=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=512))" -SearchBase “CN=Schema,CN=Configuration,DC=Root-Domäne” -SearchScope Subtree | Select Name | Sort Name | FT -Autosize -Wrap
Mit LDP lässt sich der gefilterte Attributsatz folgendermaßen anzeigen
Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN die Schemapartition und als Filter (searchFlags:1.2.840.113556.1.4.803:=512) angeben.
Weitere Informationen:
How to mark an attribute as confidential in Windows Server 2003 Service Pack 1
Anhang D: Schritte zum Hinzufügen eines Attributs zu einem Attributsatz mit RODC-Filter
Search-Flags Attribute
Das Active Directory (AD) speichert seine Daten bekanntermaßen in einer Datenbank. Das Herzstück des AD ist die Datenbankdatei, die standardmäßig im Verzeichnis %windir%\NTDS\ gespeichert wird. Diese transaktionale Datenbank und die zugehörige Datenbank-Engine „Extensible Storage Engine (ESE)“, trägt den Namen NTDS.DIT. Dabei steht das „NTDS“ für New Technology Directory Services und das „DIT“ für Directory Information Tree.
Jeder Domänencontroller (DC) in einer Einzel- und Multidomänen-Gesamtstruktur hält seine eigene Kopie dieser AD-Datenbank (NTDS.dit), die kontinuierlich durch lokale Änderungen und durch die Replikationspartner aktualisiert wird. Die AD-Datenbank verändert sich in der Größe zum einen durch die lokalen Änderungen auf dem DC selbst und zum anderen durch die Änderungen die von den Replikationspartnern repliziert werden. Es ist zwingend notwendig, dass die AD-Daten konsistent zwischen den DCs durch die AD-Replikation gehalten werden. Aber die AD-Datenbankdatei ist ohnehin nie bis auf das letzte Bit zwischen mehreren DCs identisch.
Es gibt AD-Daten, die nicht zwischen den DCs repliziert werden. Denn z.B. werden die Indizes die eine performante LDAP-Suche ermöglichen lokal auf jedem DC erstellt. Dies kann bereits zu einem gewissen Maß an Größenunterschied in jeder AD-Datenbankdatei führen. Das einzige was repliziert wird ist die Anweisung, dass ein Attribut im AD indiziert werden soll. Wird in den Eigenschaften eines Attributs im Schema Snap-In die Option Attribut in Active Directory indizieren markiert, repliziert sich diese Änderung bei der nächsten Replikation der Schemapartition auf alle DCs in der Gesamtstruktur.
Die Gründe warum auf zwei DCs die AD-Datenbank unterschiedlich groß ist, sind:
-
Der Whitespace oder zu Deutsch: Der freie Speicherplatz in der AD-Datenbank. Dies trifft dann zu, wenn ein weiterer DC zur Domäne hinzugefügt wird. Wenn ein Server als zusätzlicher DC zu einer Domäne hinzugefügt wird kann es durchaus sein, das die AD-Datenbank des neuen DCs wesentlich kleiner ist als auf den bestehenden DCs. Das ist dann ein klares Indiz für den Whitespace der in der AD-Datenbank auf den bestehenden DCs existiert. Denn wird ein weiterer DC zur Domäne hinzugefügt, wird selbstverständlich nur die Nettokapazität der AD-Datenbank auf den neuen DC repliziert und nicht zusätzlich der unnötige Whitespace.
-
AD-Replikationsprobleme. Bestehen auf einem DC Replikationsprobleme, sei es mit einer oder mit allen Verzeichnispartitionen, bekommt dieser keine Aktualisierungen von seinen Replikationspartnern mehr mit.
-
In einer Multidomänen-Gesamtstruktur ist auf einem DC der globale Katalog (GC) aktiviert und auf dem anderen nicht. Oder auf einem DC wurde der GC „unbemerkt“ deaktiviert.
Die Ursachen in der Praxis sind in der Regel der Whitespace und AD-Replikationsprobleme, die den Unterschied zwischen den AD-Datenbankdateien ausmachen.
Der Whitespace in der AD-Datenbank
Der Whitespace in der AD-Datenbank entsteht folgendermaßen.
Wenn ein AD-Objekt gelöscht wird, verschwindet es nicht sofort aus der AD-Datenbank. Das AD markiert das Objekt als gelöscht, indem das Attribut Is-Deleted des Objekts auf TRUE gesetzt wird. Dabei werden von dem Objekt die meisten Attribute für immer entfernt und wandert anschließend in den Container „Deleted Objects“ (der in fast allen Verzeichnispartitionen existiert). Ab diesem Zeitpunkt wird das gelöschte Objekt als Tombstone (zu deutsch: Grabstein) bezeichnet.
Die gelöschten Objekte bleiben nun so lange im Container „Deleted Objects“ und somit in der AD-Datenbank erhalten, bis die Tombstone-Lifetime (TSL) abgelaufen ist. Erst wenn ein gelöschtes Objekt die TSL überschritten hat wird es endgültig vom Garbage Collection Prozess aus der AD-Datenbank entfernt. Der Garbage Collection Prozess läuft standardmäßig im 12-Stunden-Takt auf jedem DC in der Gesamtstruktur. Die Zeit lässt sich zwar verändern, jedoch ist das beim täglichen Betrieb nicht notwendig.
Ändern könnte man die Zeit durch das Attribut garbageCollPeriod, welches sich in den Eigenschaften des folgenden Containers befindet (die Angabe der Zeit muss in Stunden erfolgen):
CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne
Wenn die Objekte unwiderruflich aus dem AD entfernt wurden, entsteht freier Speicherplatz (der sogenannte Whitespace) in der AD-Datenbank. Die Datenbankseiten auf denen die Objekte gespeichert waren, werden als frei markiert. Physikalisch wird aber dadurch die AD-Datenbank auf der Festplatte nicht kleiner. Stattdessen werden beim Hinzufügen neuer AD-Objekte diese auf den freien Datenbankseiten geschrieben, ohne dabei eine Speicheroptimierung bei späteren Abfragen dieser Objekte zu berücksichtigen. Durch das wiederbeschreiben der freien Datenbankseiten wird die Gesamtgröße der AD-Datenbank nicht größer. Zwar findet standardmäßig alle 12-Stunden durch den Garbage Collection Prozess auf jedem DC eine Onlinedefragmentierung der AD-Datenbank im laufenden Betrieb statt, jedoch wird dabei die AD-Datenbank ebenfalls nicht kleiner. Ob die Onlinedefragmentierung zweimal am Tag auch wirklich stattfindet, kann im Verzeichnisdienstprotokoll auf jedem DC kontrolliert werden. Denn beim Starten der Onlinedefragmentierung wird die EventID 700 und wenn sie abgeschlossen wurde, die EventID 701 protokolliert.
Bei der Onlinedefragmentierung werden lediglich die leeren Datenbankseiten neu angeordnet um einen zusammenhängenden freien Speicherplatz in der AD-Datenbank zu schaffen. Somit wird die durch die endgültige Löschung der AD-Objekte bedingte Fragmentierung der AD-Datenbank beseitigt und dadurch der Zugriff auf das AD optimiert bzw. beschleunigt. Bei den heutigen Festplattenpreisen ist es aber auch keineswegs tragisch das die AD-Datenbank physikalisch nicht kleiner wird. Dennoch ist es aus Performancegründen empfehlenswert, dass die AD-Datenbank „nur“ so groß ist, damit sie noch in den Arbeitsspeicher des DCs geladen werden kann.
Wie viel freier Speicherplatz in der AD-Datenbank tatsächlich existiert, kann durch eine Registry-Einstellung herausgefunden werden. Dazu gilt es im folgenden Registry-Schlüssel diese Einstellung vorzunehmen:
HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics
"6 Garbage Collection" = 1 (REG_DWORD)
Anschließend wird beim nächsten Durchlauf des Garbage Collection Prozesses, im Verzeichnisdienstprotokoll des DCs die EventID 1646 protokolliert. In dem Eintrag wird der freie Speicherplatz neben der Gesamtgröße der AD-Datenbank angegeben.
Es reicht in der Regel aus diese Registry-Einstellung nur auf einem DC in der Domäne zu konfigurieren, da sicherlich der freie Speicherplatz auf allen bestehenden DCs (bei gleicher DC Konfiguration) gleich ist.
Eine andere Variante mit der man sich einen tieferen Einblick über die Größe des freien Speicherplatzes in Form von leeren Datenbankseiten sogar der einzelnen Indizes in der AD-Datenbank verschaffen kann, wäre mit Esentutl. Dazu muss jedoch das AD offline sein. Bis einschließlich Windows Server 2003 muss hierzu der DC im Modus Verzeichnisdienstwiederherstellung gestartet werden. Unter Windows Server 2008 lässt sich dagegen der Dienst Active Directory-Domänendienste samt den abhängigen Diensten im laufenden Betrieb mit dem Kommandozeilenbefehl net stop ntds /y anhalten. Danach wird mit dem Befehl Esentutl /ms <Pfad zur Ntds.dit> oder durch das Aufrufen von Esentutl aus dem NTDS-Verzeichnis C:\Windows\NTDS>Esentutl /ms ein detaillierter Auszug der Ntds.dit erstellt. Es ist auch möglich die AD-Datenbank aus einer System State-Sicherung an einer alternativen Stelle wiederherzustellen, um diese AD-Datenbank zum überprüfen des freien Speicherplatzes zu nutzen. In der AD-Datenbank wird jede Tabelle zusammen mit der Anzahl der Datenbankseiten die es besitzt, samt der Anzahl der leeren Datenbankseiten die zur Verfügung stehen aufgelistet.
Damit die AD-Datenbank physikalisch kleiner wird, ist eine Offlinedefragmentierung notwendig. Natürlich müsste die Offlinedefragmentierung auf jedem DC erfolgen, damit die AD-Datenbank auf jedem DC auch physikalisch kleiner wird. Aber in den allermeisten AD-Umgebungen ist eine Offlinedefragmentierung nicht nötig. Wobei es jedoch in größeren AD-Gesamtstrukturen wiederum des Öfteren notwendig sein kann, eine Offlinedefragmentierung durchzuführen.
Wann ist eine Offlinedefragmentierung empfehlenswert?
-
Nach einer größeren Löschaktion im AD ist es empfehlenswert, wenn nach Ablauf der Tombstone-Lifetime die gelöschten Objekte endgültig aus der AD-Datenbank entfernt wurden, eine Offlinedefragmentierung der AD-Datenbankdatei durchzuführen.
-
In einer Multidomänen-Gesamtstruktur ist es ratsam, nach der Deaktivierung des globalen Katalogs auf einem DC eine Offlinedefragmentierung der AD-Datenbank durchzuführen.
-
Des Weiteren ist nach einem Inplace-Update eines Windows 2000 DCs auf Windows Server 2003/2008 eine Offlinedefragmentierung empfehlenswert. Nach einem Inplace-Update von Windows 2000 entsteht in der AD-Datenbankdatei eine erhebliche Menge an freiem Speicherplatz. Das ist aufgrund einer Verbesserung ab Windows Server 2003 möglich, worin eindeutige „security descriptors“ nur einmal (Single Instance Store) und nicht jedes Mal wenn sie verwendet werden in der AD-Datenbank gespeichert werden.
-
Wenn die DNS-Daten aus der Domänenpartition in die Anwendungsverzeichnispartitionen (DomainDNSZones und ForestDNSZones) umgezogen werden, wie es z.B. nach einer Domänenaktualisierung von einer Windows 2000 Domäne zu einer Windows Server 2003 bzw. Windows Server 2008 Domäne der Fall sein könnte, entsteht ebenfalls freier Speicherplatz in der AD-Datenbank (genauer in der Domänenpartition). Die Größe der AD-Datenbank lässt sich dann mit einer Offlinedefragmentierung verkleinern.
Die Größe unter anderem der AD-Datenbank kann man sich mit dem folgenden Befehl anzeigen lassen:
FOR /f %i IN ('Dsquery Server -Domain %userdnsdomain% -o Rdn') DO dir \\%i\Admin$\NTDS
Eine Offlinedefragmentierung durchführen
Die Gesamtgröße der AD-Datenbank wird ausschließlich nur durch eine Offlinedefragmentierung verringert. Diese sollte beim Entfernen einer größeren Anzahl an AD-Objekten, nach dem Entfernen eines globalen Katalogs in einer Multidomänen-Gesamtstruktur, nach einem Inplace-Update eines Windows 2000 DCs auf Windows Server 2003/2003R2/2008 und nach dem Umzug der DNS-Daten aus der Domänenpartition in die Anwendungsverzeichnispartition durchgeführt werden.
Die Offlinedefragmentierung wird folgendermaßen durchgeführt:
-
Zuerst sollte eine System State-Sicherung des DCs durchgeführt werden.
-
Damit eine Offlinedefragmentierung der AD-Datenbank auf einem DC durchgeführt werden kann, muss unter Windows 2000 und Windows Server 2003 der DC im Modus Verzeichnisdienstwiederherstellung gestartet werden. In diesen Modus gelangt man, wenn während der Bootphase des DCs die F8-Taste betätigt und die Option „Verzeichnisdienstwiederherstellung“ ausgewählt wird.
-
Ab Windows Server 2008 ist das Starten im Modus „Verzeichnisdienstwiederherstellung“ nicht notwendig (was aber möglich wäre). Ab einem Windows Server 2008 DC kann der Dienst Active Directory-Domänendienste im laufenden Betrieb entweder in der Dienstesteuerung (services.msc) oder in der Kommandozeile mit dem Befehl net stop ntds /y samt den abhängigen Diensten angehalten werden.
Active Directory-Domänendienste (AD-DS)
-
In der Eingabeaufforderung oder unter „Start-Ausführen“ gilt es das NTDSUTIL aufzurufen.
-
Ab Windows Server 2008 muss als erstes mit dem Befehl Activate Instance NTDS die NTDS-Instanz aktiviert werden. Unter Windows 2000 und Windows Server 2003/2003R2 muss dieser Schritt übersprungen werden.
-
Als nächstes gilt es den Befehl Files einzugeben.
-
In der „file maintenance“ Ebene werden mit dem Befehl info die aktuellen Informationen über den Pfad und der Größe der AD-Datenbank sowie der zugehörigen Protokolldateien angezeigt. Der Pfad zur AD-Datenbankdatei sollte notiert werden (zumindest sollte man ihn sich merken).
-
Mit dem Befehl compact to <Laufwerk>:\<Verzeichnis> wird eine neue, komprimierte AD-Datenbankdatei im angegebenen Verzeichnis erstellt. Es sollte ein Laufwerk und Verzeichnis an dem ausreichend Speicherplatz zur Verfügung steht ausgewählt werden, um die komprimierte neue AD-Datenbankdatei Ntds.dit zu speichern. Falls im Namen des Verzeichnispfads Leerzeichen enthalten sind, muss der Pfad in Anführungszeichen stehen. Z.B. compact to "C:\Neu NTDS".
-
Sobald die Offlinedefragmentierung abgeschlossen ist, gilt es mit der zweimaligen Eingabe von quit das NTDSUTIL zu verlassen.
-
Nun muss die neu erstellte defragmentierte Datenbankdatei "Ntds.dit" über die alte Datei "Ntds.dit" im aktuellen Pfad zur Active Directory-Datenbank (der in Schritt vier notiert bzw. gemerkt wurde), kopiert werden. Anschließend sind noch die alten Protokolldateien (*.log) zu löschen.
-
Das Kopieren der Datenbankdatei kann auch über die Kommandozeile mit folgendem Befehl erfolgen: Copy „C:\Neu NTDS\Ntds.dit“ „C:\Windows\NTDS\Ntds.dit“
Die darauffolgende Sicherheitsabfrage muss mit einem „j“ bestätigt werden.
-
Die alten Protokolldateien können in der Kommandozeile mit diesem Befehl gelöscht werden:
Del „C:\Windows\NTDS\*.log“
-
Danach gilt es den DC neu zu starten. Unter Windows Server 2008 wird mit net start ntds der Dienst Active Directory-Domänendienste samt den abhängigen Diensten gestartet.
-
Zum Schluss sollte noch eine System State-Sicherung mit der neuen Größe der Ntds.dit durchgeführt werden.
AD-Replikationsprobleme
Ein weiterer Grund warum zwischen zwei DCs die AD-Datenbank unterschiedlich groß ist, könnten AD-Replikationsprobleme sein. Hinweise ob es bei der AD-Replikation Probleme gibt, liefert bereits das Verzeichnisdienstprotokoll der DCs. Ein entscheidender Faktor bei der AD-Replikation ist die Tombstone-Lifetime (TSL). Denn DCs müssen sich mindestens einmal während der TSL mit ihren Replikationspartnern repliziert haben, da ansonsten Lingering Objects (herumlungernde Objekte) in der AD-Datenbank des DCs entstehen und die Replikationspartner den „veralteten“ DC von der AD-Replikation ausschließen.
Lingering Objects (veraltete Objekte)
Oftmals handelt es sich bei Replikationsproblemen um DNS-Probleme, denn für eine AD-Umgebung ist das DNS essentiell. Bevor ein DC die AD-Replikation startet führt dieser zuerst ein DNS-Lookup durch. Somit stellt der DC zwei Dinge sicher, zum einen das sein Replikationspartner online und funktionstüchtig ist und zum anderen, das die Namensauflösung funktioniert. Daher muss bei Replikationsproblemen die Umgebung genauestens untersucht und verifiziert werden, um welche Probleme es sich tatsächlich handelt.
Das nützlichste Werkzeug für die Überprüfung und Problembehandlung bei der AD-Replikation ist für alle Serverversionen Repadmin. Bis einschließlich „Windows Server 2003“ befindet sich Repadmin noch in den Windows Support Tools (auf der Server CD im Verzeichnis Support\Tools) und ab „Windows Server 2008“ ist es „on Bord“. Dieses Tool stellt quasi das Schweizer Messer für die AD-Replikation dar. Mit diesem Kommandozeilentool lässt sich die Replikationstopologie aus der Sicht jedes einzelnen DCs anzeigen.
Den Zustand der AD-Replikation kann man z.B. mit diesem Repadmin-Befehl überprüfen:
Repadmin /Replsum * /Bysrc /Bydest /Sort:Error
Die Replikationsinformationen auf einem DC lassen sich auch in eine CSV-Datei importieren, damit diese Datei z.B. in Excel geöffnet und leichter durchsucht werden kann. Der Befehl ist wie folgt:
Repadmin /showrepl * /csv > C:\Repadmin.csv
Eine andere Methode um Differenzen zwischen den AD-Datenbanken aufzudecken, ist neben Repadmin das DSASTAT. Details dazu liefert der folgende Artikel:
Domänencontroller vergleichen
Es könnte aber auch sein, dass ein Problem in der AD-Datenbank auf einem DC existiert. Dieses lässt sich mit einer Überprüfung der AD-Datenbankdatei herausfinden. Dazu sollte die Integrität der Ntds.dit mit NTDSUTIL untersucht und falls bei der Überprüfung Probleme gemeldet werden, könnten diese sich evtl. mit einem Fixup beheben lassen.
Siehe:
Die Active Directory-Datenbank reparieren
Die unterschiedliche Größe der AD-Datenbank zwischen globalen Katalogen
Wenn in einer Multidomänen-Gesamtstruktur auf einem DC der globale Katalog (GC) aktiviert wird, werden alle AD-Objekte aus allen Domänen in den GC repliziert. Im GC wird die vollständige Domänenpartition (alle Objekte samt allen Attributen) der eigenen Domäne gespeichert, in der sich der GC befindet. Die Domänenpartitionen der anderen Domänen werden ebenfalls in den GC repliziert, es werden jedoch nicht alle Attribute der Objekte gespeichert. Nur die Attribute die für eine Suchoperation relevant sein könnten (z.B. der DN eines Objekts) werden gespeichert.
Wird auf einem DC der GC aktiviert, gibt sich dieser nach Beendigung der Replikation im DNS als solcher bekannt. Das der DC endgültig ein GC ist, wird im Verzeichnisdienstprotokoll mit der EventID 1119 (was zwingend erscheinen muss!) protokolliert.
Ob das Heraufstufen eines DCs zum GC erfolgreich abgeschlossen wurde, lässt sich anhand des folgenden Artikels ermitteln:
Globaler Katalog – Sein oder nicht sein
Falls das Heraufstufen zum GC ordnungsgemäß abgeschlossen wurde und sich die lokale AD-Datenbankdatei dennoch von anderen GCs in der Größe wesentlich unterscheidet (z.B. 50%), so könnte ein DNS- und/oder Replikationsproblem vorliegen. Auch hierbei muss dann ein tiefergehendes Troubleshooting betrieben und die AD-Replikation mit Repadmin untersucht werden. Bei der Fehlersuche sollte die erste Anlaufstelle die Ereignisanzeige des DCs sein, DCDIAG sollte ausgeführt werden und bei Verdacht auf DNS-Probleme könnte man neben dem DCDIAG (mit den DNS-Parametern) noch das DNSLint ausführen.
Weitere Informationen:
Die Tombstone Lifetime
Globaler Katalog (Global Catalog - GC)
Die Protokollierung des Active Directory`s konfigurieren
Extensible Storage Engine Architecture
The Active Directory database garbage collection process
Performing offline defragmentation of the Active Directory database
Die Active Directory-Replikation ist ein komplexer Vorgang, die regelmäßig (um nicht zu sagen ständig) kontrolliert werden sollte.
Falls es zwischen Domänencontrollern zu Replikationsproblemen kommt, helfen neben der Ereignisanzeige in erster Linie die beiden
Tools REPADMIN sowie REPLMON bei der Suche nach der Fehlerquelle.
Gerade das Kommandozeilentool REPADMIN, das sich unter Windows 2000 sowie Windows Server 2003 in den Windows Support Tools
und im Windows Server 2008 bereits im Betriebssystem befindet, ist ein mächtiges Tool das mit vielen Parametern ausgestattet ist.
Nun hat Microsoft speziell für dieses Tool ein Whitepaper veröffentlicht, in dem das Tool mit all seinen Parametern erläutert wird.
Weiterhin werden auch Szenarien beschrieben, in denen REPADMIN helfen kann.
Hier kann das Whitepaper heruntergeladen werden:
Troubleshooting replication with Repadmin
Weitere Informationen:
Windows 2000 Service Pack 4 Support Tools
Windows Server 2003 Service Pack 2 32-bit Support Tools
Wenn ein zusätzlicher Domänencontroller (DC) z.B. durch die Install from Media-Funktion (kurz IFM) bereitgestellt wird, kann es je nach
Umgebung eine Weile dauern bis die Replikation vollständig abgeschlossen wurde. Die Dauer der Replikation hängt von der Größe der
Active Directory-Datenbank (Ntds.dit), von der zur Verfügung stehenden Badbreite und von dem Replikationszeitplan ab. Wobei die zur
Verfügung stehende Bandbreite sowie der Replikationszeitplan bei der standortübergreifenden, der sogenannten Inter-Site Replikation
eher eine Rolle spielt.
In vielen Umgebungen in denen vielleicht nur ein AD-Standort existiert reicht meistens ein Blick in die einzelnen MMCs aus. Diese wären
z.B. das Active Directory-Benutzer und –Computer Snap-In, das DNS-Snap-In (bei AD-integrierter FLZ) oder dem Verzeichnisdienstprotokoll,
um festzustellen ob bereits die Active Directory-Replikation stattgefunden hat oder evtl. ein Problem mit der AD-Replikation besteht.
Wer es aber genau wissen möchte hat die Möglichkeit, sich im laufenden Betrieb einen Überblick über die Replikation zu verschaffen,
ob auch tatsächlich die Repliken auf den verschiedenen DCs identisch sind. Ohnehin sollte ein Administrator die AD-Replikation stets überprüfen.
Mit den beiden Kommandozeilentools DSASTAT und REPADMIN lässt sich zum einen der Inhalt einer Verzeichnispartition auf zwei DCs
vergleichen und zum anderen, eine statistische Auswertung der Verzeichnispartition durchführen. So lassen sich Unstimmigkeiten innerhalb
einer Active Directory-Partition zwischen zwei DCs aufdecken. Auch lässt sich das ganze über die grafische Oberfläche mit REPLMON überprüfen.
Alle drei genannten Tools befinden sich unter Windows 2000 sowie Windows Server 2003 in den Windows Support Tools, die auf der
Windows 2000 sowie Windows Server 2003 CD im Verzeichnis Support/Tools zu finden sind. Für beide Server-Versionen können die
Support Tools auch von den Microsoft-Seiten heruntergeladen werden (siehe unter Weitere Informationen). Die beiden Tools
DSASTAT und REPLMON existieren unter Windows Server 2008 nicht. Aber auch unter Windows Server 2008 lassen sich die
Windows Server 2003 SP2 Support Tools installieren. Direkt nach dem Starten der Installation meldet der Assistent zwar bekannte
Kompatibilitätsprobleme, aber dennoch lassen sich die Support Tools ohne weiteres installieren und im Fall von DSASTAT sowie REPLMON,
auch ohne Funktionsverlust verwenden. Andererseits ist im Windows Server 2008 das REPADMIN bereits im Betriebssystem integriert.
DSASTAT
Das DSASTAT kann eine Verzeichnispartition zwischen zwei DCs der gleichen Domäne oder im Falle des globalen Katalogs,
zwischen verschiedenen Domänen überprüfen. Dabei werden im ersten Schritt die Informationen wie Megabyte pro Server,
Objekte pro Server und Megabyte pro Objektklasse ausgelesen. Im zweiten Schritt werden dann die Attribute der replizierten Objekte
miteinander verglichen. So kann überprüft werden, ob die Verzeichnispartition auf beiden DCs exakt übereinstimmt.
Die Hilfe zu DSASTAT lässt sich wie gewohnt in der Kommandozeile mit dem Befehl dsastat /? aufrufen,
in der die wenigen Parameter erläutert werden.
Die Verzeichnisinformationen aller DCs in der Domäne, werden mit diesem Befehl vergliechen:
Dsastat –loglevel:debug –output:both
Dieser Befehl vergleicht die Verzeichnisinformationen der angegebenen DCs:
Dsastat -s:<DC01>;<DC02>;<DC03>
Eine ausführlichere Überprüfung wird mit diesem Befehl durchgeführt:
dsastat –s:DomainS1;DomainS2 –b:DC=Domain,DC=com –gcattrs:all –sort:true –t:false –p:100
Um z.B. den Standard-Container Users zwischen zwei DCs zu vergleichen, muss der folgende Befehl eingegeben werden (alles in einer Zeile):
dsastat -s:DC01;DC02 -b:CN=Users,DC=intra,DC=domaene,DC=de -gcattrs:all -sort:true -t:false -p:100
-filter:"(&(objectcategory=person)(objectclass=user))"
Wenn ein DC aus der Sub-Domäne mit dem globalen Katalog der Root-Domäne verglichen werden soll, so gilt es diesen Befehl einzugeben:
dsastat -s:RootDC:3268;FQDN-SubDC -b:DC=sub,DC=domäne,DC=de -gcattrs:objectclass -p:500
Wichtig ist egal welcher Befehl verwendet wird, immer das Ende der Ausgabe.
REPADMIN
Eine andere Möglichkeit eine Verzeichnispartition zwischen zwei DCs zu vergleichen, stellt das REPADMIN dar.
Unter Windows 2000 lautet die Syntax wie folgt:
Repadmin /getchanges <DN-NamingContext> <FQDN-DC01> <GUID-DC02>
Repadmin /getchanges <DN-NamingContext> <FQDN-DC02> <GUID-DC01>
Besteht zwischen beiden DCs ein unterschiedlicher Datenbestand innerhalb einer Verzeichnispartition,
werden die Objekte um die es geht in der Ausgabe aufgeführt.
Hinweis: Der Parameter /getchanges in Windows 2000, wird auch unter Windows Server 2003 sowie Windows Server 2008 weiterhin unterstützt.
Des Weiteren können auch die folgenden Befehle, auf jeweils beiden DCs unter Windows 2000, Windows Server 2003 und 2008
ausgeführt werden, um so den up-to-dateness vector zu vergleichen:
Repadmin /showvector <DN-NamingContext> <NameDC1>
Repadmin /showvector <DN-NamingContext> <NameDC2>
Unter Windows Server 2003 sowie Windows Server 2008 ist dieser Befehl einzugeben:
Repadmin /showchanges <FQDN-ZielDC> <GUID-QuellDC> <DN-NamingContext> /statistics
Die Konfigurationspartition kann zwischen einem DC der Root-Domäne und einem DC einer Sub-Domäne wie folgt überprüft werden:
Repadmin /showchanges <FQDN-ZielDC> <GUID-QuellDC> <CN=Configuration,DC=Root-Domäne,DC=de> /statistics
Die Anwendungsverzeichnispartition ForestDNSZones kann folgendermaßen überprüft werden:
Repadmin /showchanges <FQDN-ZielDC> <GUID-QuellDC> <DC=ForestDNSZones,DC=Root-Domäne,DC=de> /statistics
Die Object-GUID eines DCs lässt sich z.B. unter Windows 2000 mit Repadmin /showreps und unter Windows Server 2003 sowie
Windows Server 2008 mit Repadmin /showrepl herausfinden.
REPLMON
Mit dem Replication-Monitor lassen sich ebenfalls Unterschiede einer Verzeichnispartition zwischen zwei DCs unter Windows 2000,
Windows Server 2003 und Windows Server 2008 aufdecken.
-
Nach dem Starten von REPLMON gilt es zuerst unter dem Menüpunkt View die Options aufzurufen.
-
Im Reiter General ist die Option Show Transitive Replication Partners and Extended Data zu aktivieren und anschließend
die Auswahl mit OK zu bestätigen.
-
Danach ist in der linken Spalte mit einem Rechtsklick auf Monitored Server die Option Add Monitored Server… zu wählen.
-
Im Assistent Add Monitored Server Wizard der daraufhin startet, gilt es einen gewünschten DC (z.B. einen neu hinzugefügten DC „DC01“)
anzugeben, der dann in der linken Spalte im Replmon erscheint.
-
Nun muss auf das Pluszeichen der entsprechenden Verzeichnispartition geklickt werden, damit mit einem Rechtsklick
auf dem anderen DC (DC02), mit dem die Verzeichnispartition verglichen werden soll, die Option Check Current USN
and Un-replicated Objects ausgewählt werden kann.
-
Falls notwendig, können für diesen Vorgang alternative Benutzerinformationen angegeben werden.
-
Wenn es nun Objekte gäbe die von DC02 zu DC01 noch nicht repliziert wurden, würden diese noch nicht replizierten Objekte
in einer Meldung angezeigt werden.
-
Soll hingegen die Replikation einer bestimmten Verzeichnispartition von DC01 zu DC02 kontrolliert werden, so sind die
gleichen Schritte auszuführen bis auf Punkt 4 (und 5). Dort ist dann DC02 als Monitored Server auszuwählen und an der
gewünschten Verzeichnispartition mit einem Rechtsklick auf DC01, erneut die Option Check Current USN and Un-replicated Objects auszuwählen.
Weitere Informationen:
Windows 2000 Service Pack 4 Support Tools
Windows Server 2003 Service Pack 2 32-bit Support Tools
Dsastat Examples
Determining the Server GUID of a Domain Controller
Als Microsoft mit Windows 2000 das Active Directory in der ersten Version einführte, waren damals die Ansprüche an dem
Verzeichnisdienst andere als heute. Insbesondere was die Active Directory-Replikation oder das Replikationsaufkommen angeht,
hatte man seinerzeit noch eine andere (geringere) Vorstellung darüber. Es kristallisierte sich heraus, dass sich dieses Verhalten
noch verbessern lässt. Denn sowohl unter Windows 2000 als auch Windows Server 2003 (abhängig vom Gesamtstrukturfunktionsmodus)
werden sämtliche Werte eines mehrwertigen (multi-valued) Attributs auch dann repliziert, wenn lediglich ein einziger Wert geändert wurde.
In einem mehrwertigen bzw. multi-valued Attribut werden, wie es der Name bereits verrät, mehrere Werte in einem Attribut gespeichert.
In Windows 2000 findet dabei ausschließlich eine Replikation auf Attribut-Ebene und nicht auf der Wert-Ebene (per Value) statt.
Die Replikation auf Attribut-Ebene hat den Nachteil, dass zum einen ein dadurch überflüssig hohes Replikationsaufkommen
entsteht und zum anderen, dass Risiko eines Replikationskonflikts sich erhöht. Bekanntermaßen findet im Active Directory
eine Multimaster-Replikation statt was soviel bedeutet, dass auf jedem Domänencontroller zur gleichen Zeit eine Änderung
durchgeführt werden kann, die dann durch die AD-Replikation auf die anderen DCs repliziert wird.
Wenn nun bei diesem Replikationsverhalten zur gleichen Zeit auf verschiedenen DCs einer Domäne, der Wert des gleichen
Attributs verändert wird, würde ein Replikationskonflikt entstehen und somit eines der Änderungen verworfen werden.
Wie sich das Active Directory im Falle eines Replikationskonflikts verhält, wird im folgenden Artikel erläutert:
Active Directory-Replikationskonflikt
Das Verhalten trifft natürlich nur dann zu, wenn sich mindestens zwei Domänencontroller in der Domäne befinden.
Ansonsten würde keine Replikation stattfinden  .
Das oft zitierte Beispiel das man zu diesem Thema liest, wären Gruppenmitgliedschaften, was nachfolgend noch
genauer erläutert wird. Das Beispiel mit den Gruppenmitgliedschaften bietet sich deshalb an, da es sich zum einen
um ein mehrwertiges Attribut (Member) handelt und zum anderen in der Praxis darin viele Werte gespeichert werden.
Denn in größeren Unternehmen stößt man genau an diesem Punkt auf Probleme.
Als Beispiel nehmen wir an, es existiert eine Benutzergruppe mit 4.950 Benutzern. Das mehrwertige Attribut Member des
Gruppenobjekts enthält somit 4.950 Einträge. Im Attribut Member sind die Distinguished Names der einzelnen Mitglieder aufgelistet.
Das können Einträge von Benutzern, anderen Gruppen oder Computern sein. Im Benutzerobjekt hingegen befinden sich die
Einträge der Gruppenmitgliedschaften im mehrwertigen Attribut MemberOf. Wenn nun dieser Benutzergruppe ein weiterer Benutzer
hinzugefügt wird, werden alle 4.951 Einträge im Attribut Member auf die anderen DCs repliziert und nicht nur der einzig
hinzugekommene Eintrag. Schließlich wird auf Attribut- und nicht auf der Wert-Ebene repliziert.
In einem anderen Beispiel gehen wir davon aus, dass eine Benutzergruppe simultan auf zwei DCs verändert wird.
Es existiert eine GruppeA mit den Benutzern: User1 und User2. Administrator1 fügt der GruppeA einen neuen Benutzer User5
hinzu und zeitgleich fügt Administrator2 auf einem anderen DC User9 hinzu. Somit kommt es zu einem Replikationskonflikt,
wobei eines der Änderungen verworfen wird.
Das Member- und MemberOf-Attribut stellen zusammen ein Linked-Attribut (verknüpftes Attribut) Paar dar.
Linked-Attribute stellen eine besondere Beziehung im Active Directory zueinander dar, denn sie bestehen aus zwei Attributen,
dem Forward- sowie Back-Link. Verändert der Administrator im Forward-Link einen Wert, aktualisiert das Active Directory
automatisch den Back-Link. Das beinhaltet natürlich auch das Löschen von Werten.
Das Member-Attribut im Gruppenobjekt ist ein Forward-Link und das Attribut MemberOf eines Benutzerobjekts stellt den Back-Link dar.
Back-Links werden von jedem DC selbst verwaltet und können auch nicht vom Administrator bearbeitet werden. Es ist ein sogenanntes
system-only Attribut und wird auch nicht auf andere DCs repliziert. Ein Back-Link und sein Wert werden zum Zeitpunkt der Abfrage generiert.
Solche Attribute tragen den Namen "constructed". Der Administrator kann nur den Forward-Link, in dem Fall dass
Member-Attribut eines Gruppenobjekts das auf andere DCs repliziert wird bearbeiten.
Neben dem unnötigen Replikationsaufkommen unter Windows 2000 kommt noch hinzu, dass eine Benutzergruppe mit mehr
als 5.000 Mitgliedern nicht unterstützt wird. Diese Grenze von 5.000 kommt daher, weil eine Aktualisierung im Active Directory
in einem einzigen Vorgang durchgeführt werden muss und eben dabei ca. 5.000 Werte aktualisiert werden können.
Anders ausgedrückt, die Active Directory Jet Database Engine kann lediglich mit einer bestimmten Anzahl an Werten
während eines Schreibvorgangs bzw. eines Replikationszyklus umgehen.
In größeren Umgebungen kann aber diese Grenze von 5.000 Mitgliedern pro Benutzergruppe ein Problem darstellen.
Der Weg diese Barriere zu umgehen wäre mit Gruppenverschachtelungen zu arbeiten.
Daraufhin wurde im Windows Server 2003 dieses Verhalten verbessert. Microsoft hat die sogenannte Linked-Value Replikation
(zu Deutsch, verknüpfte Wertreplikation) eingeführt. Mit dieser Funktion wird nur noch der geänderte Wert eines
mehrwertigen Attributs repliziert, aber nicht mehr die unveränderten Werte. Die AD-Replikation findet nun auf der Wert-Ebene statt.
Diese neue Funktion trägt sowohl zur effizienteren Replikation, als auch der Konfliktvermeidung eines mehrwertigen Attributs bei.
Bei der LVR-Replikation werden bei einem Objekt zuerst die nicht verknüpften Attribute (non-Linked Attributs) und anschließend
die verknüpften Attribute (Linked Attributes) repliziert.
Im oben genannten ersten Beispiel mit den 4951 Mitgliedern einer Benutzergruppe, würde durch die LVR-Replikation lediglich
der geänderte Wert (der hinzugekommene Benutzer) repliziert werden und nicht mehr alle Werte. Auch unter Windows NT
würde der PDC lediglich den veränderten Wert zum BDC übertragen.
Im zweiten Beispiel wären die Benutzer: User1, User2, User5 und User9 nach der LVR-Replikation in der GruppeA.
Die Linked Value Replikation ist aber erst verfügbar, wenn sich der Gesamtstrukturfunktionsmodus auf Windows Server 2003 Interim
oder Windows Server 2003 befindet. Nur dann kommt die verbesserte Replikationstechnik zum Einsatz.
Somit wird auch die künstliche Grenze von 5.000 Mitgliedern pro Benutzergruppe aufgehoben.
Eine Gruppe im Gesamtstrukturfunktionsmodus Windows Server 2003 kann im sieben stelligen Bereich Mitglieder enthalten.
Allerdings ist die unterstützte Anzahl der Änderungen die innerhalb eines Schreibvorgangs durchgeführt werden können 5.000.
Denn wenn z.B. per Skript oder Management-Tool eine Gruppe mit weit mehr als 5.000 Mitgliedern erstellt wird, läuft man Gefahr
einen „out of version store“-Fehler zu erhalten. Daher sollte beim automatisierten einrichten von Gruppen darauf geachtet werden,
diesen Wert nicht zu überschreiten.
Als Bestätigung, dass nach dem Heraufstufen der Gesamtstruktur auf Windows Server 2003 nun die LVR-Replikation eingesetzt wird,
findet man im Verzeichnisdienstprotokoll aller Domänencontroller in der Gesamtstruktur die EventID 1695.
Leider profitieren aber die bereits bestehenden Werte in einem mehrwertigen Attribut nach dem Heraufstufen der Gesamtstruktur
nicht von der LVR-Replikation. Lediglich neu hinzugekommene Werte in diesem Modus nutzen den Vorteil der LVR-Replikation.
Überprüfen lässt sich das mit dem Tool Repadmin, das sich in den Windows Support Tools befindet.
Gibt man in einer Kommandozeile den folgenden Befehl ein: Repadmin /showobjmeta <DC-Name> <DN der Gruppe>
erscheint eine Ausgabe die wie folgt aussieht:
Entscheidend dabei ist die Spalte Type. Der Eintrag LEGACY zeigt, dass dieser Wert vor dem Heraufstufen der Gesamtstruktur bereits existierte.
Somit profitiert dieser Wert nicht von der LVR-Replikation.
Im nächsten Schritt wird der bestehenden Gruppe ein weiterer Benutzer hinzugefügt.
Es ist zu erkennen, dass in der Spalte Type bei User11 der Status sich auf PRESENT befindet. Da dieser Eintrag im
Gesamtstrukturfunktionsmodus Windows Server 2003 hinzugefügt wurde, profitiert der Wert auch von der LVR-Replikation.
Ein weiterer Status wäre ABSENT. Dieser Eintrag wird angezeigt, wenn ein Mitglied im Gesamtstrukturfunktionsmodus
Windows Server 2003 zu einer Gruppe hinzugefügt und entfernt wurde.
Wenn ein Benutzerobjekt aus dem Active Directory gelöscht wird, ist die Wiederherstellung samt Gruppenmitgliedschaften
eine heikle Angelegenheit. Wenn es sich aber um eine Windows Server 2003 SP1 Umgebung handelt, erleichtert einem das
NTDSUTIL bei der Wiederherstellung der Informationen von Gruppenmitgliedschaften das Leben. Denn die Wiederherstellung
von Gruppenmitgliedschaften basiert auf LDAP Data Interchange Format (LDIF) Dateien. Der genaue Vorgang wird im folgenden Artikel beschrieben.
How to restore deleted user accounts and their group memberships in Active Directory
Damit alle Werte eines mehrwertigen Attributs von der LVR-Replikation profitieren, ist es notwendig alle Werte neu zu schreiben.
Dazu müssen die Werte zuerst entfernt und anschließend erneut hinzugefügt werden.
Neben skriptbasierten Lösungen kann einem das LDIFDE behilflich sein oder aber die im Windows Server 2003
enthaltenen Tools DSGET und DSMOD. Mit diesem Befehl werden alle Werte neu geschrieben:
Dsget group <DN der Gruppe> -members | Dsmod group <DN der Gruppe> -chmbr
Active Directory - Abfrage
Anschließend werden mit der Abfrage von Repadmin, alle Werte im Attribut Member mit dem Status PRESENT angezeigt.
Weitere Informationen:
Verknüpfte Attribute
How to raise domain and forest functional levels in Windows Server 2003
Group Objects (Windows)
Microsoft Windows 2000 Scripting Guide - Modifying Multivalued Attributes
Enumerating Groups That Contain Many Members (Windows)
In einer Active Directory Umgebung findet zwischen den Domänencontrollern eine Multimaster-Replikation statt.
Dadurch kann auf jedem Domänencontroller (DC) eine Änderung durchgeführt werden, die Dank der AD-Replikation an alle DCs repliziert wird.
Das Active Directory (genauer KCC) reagiert dabei schnell auf etwaige Veränderungen in der Gesamtstrukturtopologie und findet
- sofern irgendwie möglich - oftmals eine Lösung.
Nun kann es in einer Umgebung mit mehreren DCs und mehreren Administratoren vorkommen, dass zur gleichen Zeit an einem Objekt,
dass gleiche Attribut auf verschiedenen DCs bearbeitet wird. Ein Replikationskonflikt wird anhand der Versions-Nummer (versionID) des
veränderten Attributs erkannt. Im Gegensatz zu der Update Sequence Number (USN), worin serverspezifische Werte gespeichert werden,
wird in der Versions-Nummer eines Attributs ein eindeutiger Wert gespeichert.
Wird nun ein Attribut auf DC2 verändert, bevor die zur gleichen Zeit getätigte Änderung von DC1 repliziert wurde,
entsteht somit ein Replikationskonflikt. Angenommen auf DC1 wird in den Eigenschaften eines Benutzerobjekts im Feld Büro die
Zimmer-Nummer 2.12 und zur gleichen Zeit auf DC2 die Zimmer-Nummer 2.21 eingetragen. Wenn nun DC3 beide Änderungen gleichzeitig erhält,
muss bestimmt werden, welche Änderung repliziert wird.
Das Active Directory wendet dann die folgenden drei Regeln an, um festzulegen welche Änderung repliziert werden soll:
-
Das modifizierte Attribut mit der höheren Versions-Nummer (versionID) überschreibt die Änderung mit der niedrigeren Versions-Nummer.
Sind in beiden Fällen, beide Versions-Nummern identisch, folgt die nächste Regel.
-
Enthalten beide Änderungen die gleiche versionID, wird die Änderung mit dem späteren Zeitstempel (Timestamp) akzeptiert und somit
würde die Änderung mit dem früheren Zeitstempel überschrieben werden. Ist in beiden Fällen auch der Zeitstempel gleich
(was in seltenen Fällen zutrifft), kommt die dritte und letzte Regel ins Spiel.
-
Falls beide Änderungen sowohl die gleiche versionID, als auch den gleichen Zeitstempel haben, wird die Änderung,
die seine Herkunft auf dem DC mit der niedrigeren GUID hat akzeptiert. Somit wird der Schreibvorgang vom DC mit der höheren GUID überschrieben.
In einem anderen Fall kann es zu einem Replikationskonflikt kommen, wenn ein Objekt auf zwei verschiedenen DCs mit dem
gleichen Namen zur gleichen Zeit erstellt wird, wie es z.B. beim hinzufügen eines Clients zur Domäne vorkommen kann.
Oder beim gleichzeitigen erstellen zweier Benutzerobjekte, mit dem gleichen Namen. Denn wenn zwei DCs zur gleichen Zeit
ein Objekt mit dem gleichen Namen im Active Directory erstellen, kommt es ebenfalls zum Konflikt.
Das Active Directory wendet in diesem Fall ebenfalls die o.g. drei Regeln an, mit dem Unterschied, dass das nicht akzeptierte
Objekt nicht überschrieben, sondern umbenannt wird. Der Relative Distinguished Name (RDN) des Objekts, bekommt einen
eindeutigen Namen der folgendermaßen aussieht: <Original RDN>CNF:<ObjectGUID>. Die Zeichen CNF stehen dabei für
Conflict (Konfliktobjekt). Danach folgt ein Doppelpunkt, gefolgt von der Objekt GUID.
Der Administrator kann dann bestimmen, welches Objekt beibehalten und welches gelöscht werden soll.
Über eine benutzerdefinierte Abfrage lassen sich alle Konfliktobjekte anzeigen. Der Filter dazu lautet (CN=*CNF:*).
Es gibt aber noch eine dritte Situation, in dem es zu einem Konflikt kommen kann. Erstellt ein Administrator z.B. einen Benutzer in einer OU
und ein anderer Administrator löscht im gleichen Moment auf einem anderen DC diese OU, wird das Benutzerobjekt trotzdem erstellt
obwohl der übergeordnete Container entfernt wurde. Das AD löst in diesem Fall den Konflikt, in dem es das Benutzerobjekt in
einem versteckten Container Namens LostAndFound erstellt. Der Domänen-Benutzer der sich im Container LostAndFound befindet,
kann sich wie jeder andere Benutzer an der Domäne anmelden. Der Administrator sollte aber aus administrativen Gründen
den Benutzer in eine andere OU verschieben. Der Container LostAndFound kommt erst dann zum Vorschein,
wenn in der MMC Active Directory-Benutzer und -Computer unter "Ansicht" die Option Erweiterte Funktionen aktiviert wurde.
Weitere Informationen:
Avoiding Replication Issues When Designing Applications that Use Active Directory
Troubleshooting Directory Data Problems
Bei einer standortinternen (Intra-Site) Replikation kündigen die Domänencontroller (DC) vor der eigentlichen Replikation durch eine Änderungsbenachrichtigung
(Change Notification) die anstehende Replikation an. Sobald eine Änderung im Active Directory durchgeführt wurde, bekommen die Replikationspartner die sich
am gleichen Standort befinden eine Benachrichtigung. Das geschieht ab dem Gesamtstrukturfunktionsmodus „Windows Server 2003“ nach 15 Sekunden
(Initial Notification Delay). Falls der Quell-DC mehrere Replikationspartner hat, wird jeder weitere DC nach weiteren 3 Sekunden benachrichtigt (Subsequent Notification Delay).
Befindet sich der Gesamtstrukturfunktionsmodus nicht mindestens auf „Windows Server 2003“, sind es 300 Sekunden für eine Replikationsankündigung
und weitere 30 Sekunden Wartezeit für die weiteren Replikationspartner.
Die standortübergreifende Replikation findet nach einem Zeitplan (Standardeinstellung alle 180 Minuten) statt. Das Intervall kann zwischen
min. 15 bis max. 10.080 Minuten betragen und lässt sich im Snap-In „Active Directory-Standorte und –Dienste“ konfigurieren.
Die standortinterne (Intra-Site) Replikation nutzt die Benachrichtigung sowie Pull Methode, die wie folgt aussieht:
-
Auf einem DC wird eine Änderung an einem Objekt vorgenommen oder es wurde eine Änderung von einem anderen DC repliziert.
-
Danach wartet der DC 15 Sekunden (ab der Gesamtstrukturfunktionsebene „Windows Server 2003“ bzw. 300 Sekunden in allen vorherigen Ebenen)
nach der ersten Änderung und sendet anschließend eine Änderungsbenachrichtigung an seine direkten Replikationspartner am gleichen Standort.
Um genau zu sein, werden die Änderungsbenachrichtigungen nur jenen Replikationspartnern zugesandt, die ebenfalls die Verzeichnispartition in der
die Änderung vollzogen wurde besitzen. Jeder weitere Replikationspartner des Quell-DCs wird im Abstand von 3 Sekunden
(ab der Gesamtstrukturfunktionsebene „Windows Server 2003“ bzw. 30 Sekunden in allen vorherigen Ebenen) benachrichtigt.
Wenn die Änderungsbenachrichtigung zeitgleich an alle Replikationspartner versandt werden würde (Initial Notification Delay),
könnte dies zu einer Überlastung auf dem Quell-DC führen.
Daher wird jeder Replikationspartner mit einem Abstand (Subsequent Notification Delay) benachrichtigt.
-
Der Ziel-DC fordert danach die Änderungen von dem Quell-DC der die Benachrichtigung versandt hat an.
Falls weitere Replikationsanforderungen anstehen, werden diese erst abgearbeitet, wenn die vorherige Replikation abgeschlossen wurde.
Dabei verwendet das Active Directory die Pull-Replikation, die effektiver als eine Push-Replikation ist.
Bei einer Push-Replikation ist es schwierig zu erkennen, welche Änderungen dem Ziel-DC noch fehlen. Daher würde unnötig Replikationslast erzeugt,
wenn sich bereits die Informationen evtl. auf dem Ziel-DC befinden.
Möchte man die Zeit der Replikationsankündigung sowie der Verzögerung verändern, so geht das auf folgenden beiden Wegen:
-
In der Registry gilt es im Pfad „HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters“
die beiden DWORD-Schlüssel „Replicator notify pause after modify (secs)“ und „Replicator notify pause between DSAs (secs)“ zu erstellen
(falls diese nicht existieren). Als Wert trägt man die Zeit in Sekunden ein.
Ein anderer Weg wäre die Zeit für die einzelnen Verzeichnispartitionen zu definieren. Das geht, in dem die beiden Attribute
ms-DS-Replication-Notify-First-DSA-Delay sowie ms-DS-Replication-Notify-Subsequent-DSA-Delay des jeweiligen Cross-Reference Objekts
der entsprechenden Verzeichnispartition bearbeitet werden. Bearbeiten lässt sich das ganze über ADSIEdit.msc das sich in den
Windows Support Tools befindet. Die Cross-Reference Objekte befinden sich im Container Partitions der Konfigurationspartition.
Falls an beiden Stellen (Registry sowie an dem Cross-Reference Objekt) Änderungen vorgenommen wurden, so hat die Registry-Einstellung Vorrang.
Dringende Replikation (Urgent Replication)
Die dringende Replikation wird für bestimmte wichtige Ereignisse verwendet.
Wie bei der standortinternen (Intra-Site) Replikation basiert die dringende Replikation auf Änderungsbenachrichtigungen. Außer dass beim Eintreten eines
wichtigen Ereignisses die Benachrichtigung unverzüglich versendet wird, anstatt 15 bzw. 300 Sekunden abzuwarten. Standardmäßig werden bei der dringenden
Replikation (aufgrund des hohen Replikationsaufkommens) Standortgrenzen nicht überschritten.
Die dringende Replikation kann aber für die standortübergreifende (Inter-Site) Replikation ebenfalls genutzt werden,
sofern die Benachrichtigungsfunktion in der Standortverknüpfung (Site-Link) konfiguriert wurde.
Auslöser einer dringenden Replikation sind:
- Benutzerkonto wurde gesperrt, durch mehrmalige falsche Kennwort-Eingabe
- Kennwort-Änderungen
- Statusänderung an der Rolle des RID-Masters
Bei der Kennwort-Änderung gilt allerdings folgendes;
Findet z.B. eine Benutzer-Kennwortänderung auf einem DC statt, so repliziert der DC die Information (durch den sicheren Kanal) umgehend an den DC, der die Rolle des PDC-Emulators innehat. Wenn sich der Benutzer nun an einem anderen DC, der noch nicht die Benachrichtigung der Kennwort-Änderung erhalten hat, anmelden möchte, erkennt dieser ein „anderes“ Kennwort und kontaktiert somit den PDC-Emulator um abzufragen, ob zwischenzeitlich eine Kennwort-Änderung stattgefunden hat.
Urgent replication triggers in Windows 2000
Aber auch dieses Verhalten lässt sich ändern, wie es folgender Artikel zeigt:
New Password Change and Conflict Resolution Functionality in Windows
Änderungsbenachrichtigung für die Inter-Site Replikation aktivieren
Seit Windows 2000 lässt sich die Replikationsankündigung (Change Notification) über Standortgrenzen hinweg konfigurieren. Dies geht auf folgende Weise:
Mit ADSIEdit gilt es das Attribut Options der entsprechenden Standortverknüpfung (Site-Link) zu bearbeiten.
Die Standortverknüpfungen befinden sich in der Konfigurationspartition. Der Pfad für die IP-Replikation wäre:
CN=<Site-Link-Objekt-Name>,CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=<DeineDomäne>,DC=<TLD>
Dort wählt man die Eigenschaften der entsprechenden Standortverknüpfung aus und navigiert zum Attribut Options.
Als Standardwert ist <Not Set> eingestellt und dieses gilt es auf 1 zu ändern.
Hinweis: Für die SMTP-Replikation kann man die Änderungsbenachrichtigung nicht aktivieren!
Weitere Informationen:
Domänen- und Gesamtstrukturfunktionsmodus
Account Unlocks and Manual Password Expirations Are Not Replicated Urgently
Advanced Replication Management
How the Active Directory Replication Model Works
CrossRef-Referrals
Wenn ein Objekt im Active Directory gelöscht wird, verschwindet das Objekt nicht sofort aus dem Verzeichnis. Denn in größeren Gesamtstrukturen
mit einer komplexen Replikationstopologie könnte es durchaus vorkommen, dass ein Domänencontroller der von dieser Löschung noch nichts mitbekommen hat,
dass Objekt zurückrepliziert. Deshalb werden (weiter unten stehende) diverse Attribute eines Objekts behalten und als gelöscht markiert.
Anschließend wird dieser Datensatz auf alle anderen Domänencontroller repliziert. Auf diese Art ist sichergestellt, dass jeder Domänencontroller von dieser
Löschung informiert wird. Dieser Ansatz wird als Tombstone (Grabstein) bezeichnet, denn den Grabstein muss das gelöschte Objekt für einen bestimmten
Zeitraum, nämlich die Tombstone Lifetime (TSL), mit sich herumtragen. Die Tombstone Lifetime definiert, in welchem Zeitraum ein gelöschtes Objekt im
Active Directory wiederhergestellt werden kann.
Wenn ein Objekt gelöscht wird, werden folgende Änderungen an dem Objekt vorgenommen:
- Das Attribut des gelöschten Objekts Is-Deleted wird auf TRUE gesetzt,
wenn das löschen nicht durch das gesetzte Bit (0x80000000) im System-Flags Attribut des Objekts verhindert wird.
- When-Deleted ist eine interne Eigenschaft und besitzt keinen LDAP-Namen. Diese Eigenschaft bekommt den Wert (Timestamp) aus dem
Attribut Is-Deleted.
- Das Attribut NT-Security-Descriptor bekommt einen speziellen Wert.
- Der Common Name (CN) wird zu einem Wert geändert, der anderweitig von keinem LDAP Programm gesetzt werden kann.
Wenn z.B. das Benutzerobjekt „Yusuf Dikmenoglu“ gelöscht wird, bekommt es nach dem löschen einen bestimmten Wert und der
Distinguished Name (DN) würde wie folgt lauten:
„CN=Yusuf Dikmenoglu\0ADEL:ee3570c0-2664-4947-bde0-4dcbb55a8a23,CN=Deleted Objects,DC=<Domäne>,DC=<TLD>“
(CN=<alter RDN>\0ADEL:<Object-GUID>).
-
Das Objekt wird in den versteckten Container Deleted Objects (CN=Deleted Objects,DC=<Domäne>,DC=<TLD>),
der in allen Verzeichnispartitionen enthalten ist, verschoben. Natürlich nur dann, wenn im System-Flags Attribut des Objekts das verschieben
durch den Wert "67108864 (0x04000000)" nicht verhindert wurde.
-
Der Garbage Collection Prozess der standardmäßig alle 12 Stunden auf jedem Domänencontroller läuft, entfernt alle nicht mehr benötigten
Attribute eines gelöschten Objekts. Das Intervall kann im Attribut garbageCollPeriod das sich im folgenden Pfad der Konfigurations-Partition befindet,
konfiguriert werden: CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<Domäne>,DC=<TLD>.
Schließlich ist es auch der Garbage Collection Prozess, der das gelöschte Objekt nach Ablauf der Tombstone Lifetime dauerhaft aus dem
Verzeichnisdienst entfernt. Als Kriterium zur endgültigen Löschung des Objekts dient die Zeit, die in When-Deleted angegeben ist.
Weiterhin führt der Prozess eine online Defragmentierung der Active Directory-Datenbank NTDS.DIT durch. Das Löschen von Objekten
verkleinert die physikalische Dateigröße der Active Directory-Datenbank NTDS.DIT allerdings nicht. Dazu wäre eine Offline-Defragmentierung notwendig,
was aber i.d.R. nicht erforderlich ist. Die online Defragmentierung reicht völlig aus.
-
Diverse Attribute bleiben in einem gelöschten Objekt (Tombstone) erhalten. Diese wären:
Attribute-ID, Attribute-Syntax, Distinguished Name, DN-Reference-Update, DNS-Host-Name, Flat-Name, Governs-ID, Group-Type,
Is-Deleted, Instance-Type, Last-Known-Parent, LDAP-Display-Name, Legacy-Exchange-DN, MS-DS-Creator-SID, MSMQ-Owner-ID, NC-Name,
Object-Class, Object-GUID, Object-SID, OM-Syntax, Proxied-Object-Name, Repl-Property-Meta-Data, SAM-Account-Name, Security-Identifier,
SID-History (ab Windows Server 2003), Sub-Class-Of, System-Flags, Trust-Attributes, Trust-Partner,Trust-Direction, Trust-Type,
User-Account-Control, USN-Changed, USN-Created, When-Created.
Zusätzlich bleiben noch die Attribute erhalten, die einen gesetzten Wert im Attribut Search-Flags haben.
Das Active Directory speichert aber weder Forward- noch Backwardlink-Attribute im Tombstone, selbst dann nicht,
wenn es im Search-Flags Attribut des Objekts eingestellt wurde.
- Welche Attribute eines gelöschten Objekts erhalten bleiben, entscheidet das vierte Bit (in Dezimal 8) des Attributs Search-Flags.
- Es werden keine Forward- sowie Backwardlink-Attribute im Tombstone gespeichert, auch nicht, wenn dies im Search-Flag Attribut eingestellt wäre.
Neben den beiden Attributen objectCategory und samAccountType, wird auch das Attribut memberOf immer von einem gelöschten Objekt entfernt.
- Wenn das Objekt auf einem Windows Server 2003 Domänencontroller gelöscht wurde, so wird der Ursprungs-Ort des Objekts im Attribut
Last-Known-Parent gespeichert.
Gelöschte Objekte werden in keinem Snap-In wie z.B. „Active Directory-Benutzer und -Computer“ oder ADSIEdit angezeigt,
stattdessen können diese mit LDP.exe aus den Windows Support Tools angezeigt werden.
Wie entstehen Lingering Objects (veraltete Objekte)?
Die Namensauflösung spielt wie so oft, bei der Replikation eine wichtige Rolle. Denn Windows 2000 sowie
Windows Server 2003 Domänencontroller führen vor der eigentlichen Replikation DNS-Lookups durch. Es wird versucht den GUID-Teil des
CNAME-Records das sich in der Zone _msdcs.<Root-Domäne> befindet, des Replikationspartners, in eine IP-Adresse aufzulösen.
Somit wird sichergestellt, dass der Replikationspartner erreicht und aufgelöst werden kann. Falls Lookups nicht durchgeführt werden können,
kann keine Replikation stattfinden und somit besteht die Gefahr, dass veraltete Objekte entstehen.
Folgende Fehlersituationen können dazu führen, dass ein DC länger keine Replikation durchführen kann:
Diese Fehlerquellen könnten dafür sorgen, dass sich ein Domänencontroller nicht ordnungsgemäß replizieren kann und dadurch von
den Löschungen die das Active Directory tätigt, nichts mitbekommt. Objekte die auf allen anderen Domänencontrollern gelöscht wurden,
bleiben auf dem Domänencontroller erhalten. Da der Domänencontroller während der Tombstone-Lebensdauer nicht erreichbar (offline) war,
bekommt dieser während diesem Zeitraum nicht die gelöschten Informationen (Tombstone) repliziert. Solche Objekte werden als
Lingering Objects (veraltete Objekte) bezeichnet.
Wenn nun aber der längerfristig vom Netzwerk getrennte Domänencontroller erneut ins Netzwerk integriert wird, könnte es vorkommen,
dass dieser eines der gelöschten Objekte erneut auf alle Domänencontroller der Domäne repliziert. Dieses tritt z.B. dann auf, wenn auf dem
„veralteten“ Domänencontroller eines der gelöschten Objekte bearbeitet wird. Nach der Änderung am entsprechenden Objekt, repliziert das
Active Directory die Änderung auf einen Domänencontroller, auf diesem das Objekt - verursacht durch die Löschung - nicht mehr vorhanden ist.
Daraufhin hat der Ziel-Domänencontroller der die Replikation empfängt, folgende Möglichkeiten:
-
Ein Domänencontroller zeichnet auf, wann die letzte Replikation stattgefunden hat. Wenn die Tombstone Lifetime verstrichen ist und danach ein veralteter Domänencontroller versucht sich mit einem „aktuellen“ Domänencontroller zu replizieren, wird folgende Fehlermeldung im Verzeichnisdienstprotokoll protokolliert:
Event-ID: 2042 Quelle: NTDS Replication
Es ist zu lange her, dass dieser Computer zuletzt mit dem genannten Quellcomputer repliziert hat. Die Zeit zwischen den Replikationen mit dieser
Quelle hat die Tombstone-Ablaufzeit überschritten. Die Replikation mit dieser Quelle wurde beendet. Der Grund dafür, dass das Fortsetzen der
Replikation nicht zugelassen wird, ist, dass die Sicht der beiden Computer in Bezug auf gelöschte Objekte sich nun ggf. unterscheidet.
Der Quellcomputer hat ggf. noch Kopien von Objekten, die auf diesem Computer gelöscht (und in die Sammlung veralteter Objekte aufgenommen)
wurden. Würde der Replikation zugelassen, könnte der Quellcomputer Objekte zurückgeben, die bereits gelöscht wurden. Zeitpunkt der letzten
erfolgreichen Replikation: 2006-08-09 08:36:24 Aufrufkennung der Quelle: 43b8e6bd-h4bf-16a8-571c-6f2346653c02 Name der Quelle:
432cb837-e36c-37h3-ge5b-63egf24a1478._msdcs.<Domäne>.<TLD>.
Tombstone-Ablaufzeit (Tage): 60 usw.
In der Beschreibung werden dann folgende Lösungswege vorgeschlagen:
1. Stufen Sie den/die Computer herunter, die getrennt wurden, oder installieren Sie ihn/sie neu.
Da sich der Domänencontroller nicht ordnungsgemäß repliziert, muss zum herunterstufen (wenn diese Lösung gewählt wird) das
DCPROMO Kommando mit dem Schalter /FORCEREMOVAL ausgeführt und anschließend das Active Directory bereinigt werden:
Das Active Directory gewaltsam vom DC entfernen
How to remove data in Active Directory after an unsuccessful domain controller demotion
2. Verwenden Sie das Tool „Repadmin /removelingeringobjects", um inkonsistent gelöschte Objekte zu entfernen
und setzen Sie dann die Replikation fort.
Mit dem angegebenen Befehl, werden die veralteten Objekte entfernt. Anschließend gilt es die Replikation zu forcieren.
Dieses ist mit folgendem Befehl möglich: REPADMIN /Repl <Ziel-DC> <Alt-DC> dc=<Domäne>,dc=<TLD> /Force.
Dadurch lässt sich das Problem für die angegebene Verzeichnispartition beheben. Wenn nun die Replikation erneut startet,
kann der gleiche Fehler, diesmal für eine andere Verzeichnispartition protokolliert werden. Deshalb muss der REPADMIN-Befehl für
alle einzeln angegebenen Verzeichnispartitionen (Schemapartition, Konfigurationspartition, DomainDNSZones, ForestDNSZones) und
für alle weiteren existierenden Anwendungsverzeichnispartitionen durchgeführt werden. Für den Fall, dass auf dem DC der GC aktiviert ist,
so gilt es dieses durchzuführen:
Lingering objects may remain after you bring an out-of-date global catalog server back online
3. Setzen Sie die Replikation fort. Möglicherweise werden inkonsistent gelöschte Objekte eingeführt. Sie können die Replikation fortsetzen,
indem Sie den folgenden Registrierungsschlüssel verwenden. Es wird empfohlen, zur Wiederherstellung des Schutzes den Schlüssel zu entfernen,
sobald das System ein Mal repliziert hat. Registrierungsschlüssel:
HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Allow Replication With Divergent and Corrupt Partner
Repliziert sich ein DC während der Tombstone Lifetime nicht mit anderen DCs, besteht die Gefahr,
dass auf diesem veraltete Objekte entstehen. Tritt dieser Fall ein, blockiert der Ziel-DC die eingehende (In-Bound) Replikation mit
dem „veralteten“ DC und protokolliert im Verzeichnisdienstprotokoll die Fehler-ID 2042 mit der Beschreibung wie sie hier aufgeführt ist.
Anschließend sollten die veralteten Objekte entfernt werden (weiter unten beschrieben). Für die erneute Replikation ist der folgende Wert
in der Registry zu setzen:
HKLM\System\CurrentControlSet\Services\Ntds\Parameters
Allow Replication With Divergent and Corrupt Partner
REG_DWORD
Value: 1
Der Wert in diesem Fall ist auf 1 zu setzen, damit die Replikation auf dem Ziel-Domänencontroller durchgeführt werden kann.
Wenn diese Einstellung vorgenommen wurde, ist kein Neustart des DCs notwendig.
Existiert dieser Registry-Schlüssel (der nur unter Windows Server 2003 DCs gültig ist) nicht, so gilt es diesen zu erstellen.
Diese Einstellung wäre z.B. für eine Testumgebung mit virtuellen Maschinen, die über einen längeren Zeitraum nicht in Nutzung waren das richtige.Event ID 2042: It has been too long since this machine replicated
Es sollte unbedingt darauf geachtet werden, wenn diese Einstellung in einer produktiven Umgebung eingesetzt wird,
dass nach der Replikation diese Einstellung auf 0 gesetzt wird, damit die Replikation vor veralteten Objekten geschützt werden kann!
Falls auf dem Ziel-Domänencontroller die strikte Replikationskonsistenz (Strict Replication Consistency) aktiviert ist und er eine Anfrage für die
Aktualisierung eines lokal nicht vorhandenen Objekts erhält, erkennt dieser, dass er das Objekt nicht aktualisieren kann (weil es nicht vorhanden ist)
und stoppt somit die eingehende (In-Bound) Replikation der Verzeichnispartition in dem sich das veraltete Objekt befindet.
Die Einstellung der Replikationskonsistenz (strikte oder nicht strikte) bestimmt das Verhalten eines Domänencontrollers bzgl. der Aktualisierung
von AD-Objekten die nicht mehr in seiner lokalen Datenbank vorhanden sind. Wenn also der Ziel-Domänencontroller (der DC, der das veraltete
Objekt empfangen soll) ein veraltetes Objekt vom Quell-Domänencontroller entdeckt, verschiebt der Ziel-DC die zu empfangende Verzeichnispartition
in der sich das veraltete Objekt befindet, in eine Art Quarantäne. Die Quarantäne wird erst dann aufgehoben, wenn entweder das veraltete Objekt
entfernt wird oder der Ziel-DC die Loose Replication Consistency aktiviert hat.
Standardmäßig ist die strikte Replikationskonsistenz bei einer Migration von NT 4.0 auf Windows Server 2003 oder wenn eine Gesamtstruktur
ab Windows Server 2003 erstellt wurde aktiviert. Die Funktion des Strict Replication Consistency steht ab Windows 2000 Server SP3
(sogar schon mit Post-SP2 Hotfix) zur Verfügung, diese ist aber unter Windows 2000 standardmäßig deaktiviert. Bei aktivierter Einstellung
wird die Ereignis-ID 1988 im Verzeichnisdienstprotokoll des Ziel-DCs protokolliert.
Die Lösung für diesen Fehler wäre, mit dem Befehl REPADMIN /removelingeringobjects die veralteten Objekte von dem Domänencontroller
der diese enthält zu entfernen. Dazu muss der Quell- sowie Ziel-Server ein Windows Server 2003 Domänencontroller sein.
Die Einstellung für die strikte Replikationskonsistenz, kann in der Registry im folgenden Pfad vorgenommen werden:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Value Name: Strict Replication Consistency
Data type: REG_DWORD
Value: 1
Hinweis: Das Heraufstufen des Domänenfunktionsmodus bzw. Gesamtstrukturfunktionsmodus ändert nicht die „Strict Replication Consistency“ Einstellung!
Falls diese Funktion auf dem Ziel-Domänencontroller deaktiviert ist (Value: 0), fordert dieser eine vollständige Replik (Kopie) des
Objekts an und fügt es in seine Verzeichnis-Datenbank hinzu. Die Deaktivierung dieser Einstellung wird als Loose Replication Consistency bezeichnet.
Wenn ein Domänencontroller unter Windows 2000 SP3 (oder höher), ein Windows 2000 Server auf Windows Server 2003 aktualisiert wurde oder
das Active Directory (DCPROMO) auf einem Windows Server 2003 Mitgliedsserver, dass Mitglied in einer Windows 2000 Gesamtstruktur ist,
installiert wurde, ist diese Option standardmäßig deaktiviert. Dabei wird die Ereignis-ID 1388 im Verzeichnisdienstprotokoll des Ziel-Domänencontrollers
(also der DC, der das nicht mehr existierende Objekt erneut repliziert bekommen soll) protokolliert.
Wird auf einem Domänencontroller die Ereignis-ID 1388 im Verzeichnisdienstprotokoll protokolliert, ist eine eingehende Replikation (In-Bound) von
einem veralteten Objekt aufgetreten. Ein Domänencontroller der die Loose Replication Consistency Einstellung aktiviert hat, bekommt eine Anfrage
für die Aktualisierung eines lokal nicht mehr vorhandenen Objekts. Der Ziel-Domänencontroller fordert danach vom Replikationspartner das vollständige
Objekt an. Der Quell-Domänencontroller (der das veraltete Objekt besitzt) repliziert es auf den Ziel-Domänencontroller und dieser fügt es in seine
Verzeichnisdatenbank hinzu.
Event ID 1388 or 1988: A lingering object is detected
Outdated Active Directory objects generate event ID 1988 in Windows Server 2003
Enable strict replication consistency
Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042)
Auf Domänencontrollern die mindestens unter Windows Server 2003 mit Service Pack 1 laufen, ist es nicht zwingend notwendig die Einstellung direkt in der Registry vorzunehmen. Stattdessen kann der Wert auch mit REPADMIN gesetzt werden.
Der Befehl würde folgendermaßen lauten:
REPADMIN /Regkey <DC-DNS-Name> +strict = Dieser Befehl aktiviert auf dem angegebenen DC das „Strict Replication Consistency“.
REPADMIN /Regkey <DC-DNS-Name> -strict = Dieser Befehl deaktiviert auf dem angegebenen DC das „Strict Replication Consistency“.
REPADMIN /Regkey <*> +strict = Dieser Befehl aktiviert auf allen DCs der Gesamtstruktur das „Strict Replication Consistency“.
Natürlich nur auf DCs, die unter Windows Server 2003 SP1 laufen.
Anstatt den DNS-Namen des Domänencontrollers anzugeben, kann man auch den Distinguished Name des Domänencontroller-Computerobjekts verwenden.
Falls die Loose Replication Consistency aktiviert und das Objekt repliziert wurde, sollte anschließend diese Einstellung rückgängig gemacht werden.
Zusammenfassend lässt sich ableiten, dass sich ein Domänencontroller vor “veralteten Objekten” auf zweierlei Art schützt.
Zum einen durch die Tombstone Lifetime und zum anderen durch die aktivierte Replikationskonsistenz (Strict Replication Consistency).
Damit erst keine veralteten Objekte entstehen, sollte regelmäßig die Replikation überprüft werden. Falls Replikationsprobleme bestehen,
werden diese durch Fehlermeldungen z.B. in einer Ausgabe von REPADMIN oder durch Ereignisse protokolliert.
Sollen lediglich Replikationsfehler angezeigt werden, so ist der Befehl REPADMIN /Showrepl /Errorsonly auszuführen.
Mit dem Befehl REPADMIN /SHOWREPL * /CSV > C:\Repadmin.csv kann die Ausgabe in eine Datei exportiert werden.
Mit der Eingabe REPADMIN /Experthelp bekommt man eine ausführlichere Hilfe des Befehls REPADMIN angezeigt, als mit REPADMIN /?.
Repadmin Syntax
Auch mit DCDIAG kann die Replikation überprüft werden:
DCDIAG /Test:Replications
Auf Windows Server 2003 mit SP1 kann folgender Befehl ausgeführt werden:
DCDIAG /Test:CheckSecurityError oder DCDIAG /Test:CheckSecurityError /s:<DC-Name>.
Eine weitere Möglichkeit wäre, das Attribut tombstoneLifetime mit ADSIEdit im Pfad:
CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<Domain>,DC=<TLD> zu erweitern.
Wobei in produktiven Umgebungen der Standard nicht verändert werden sollte!
Lingering objects prevent Active Directory replication from occurring
Information about lingering objects in a Windows 2000-based forest or in a Windows Server 2003-based forest
Wie kann man Lingering Objects (veraltete Objekte) entdecken und entfernen?
Ab Windows Server 2003 steht dem Administrator das Tool REPADMIN, dass Bestandteil der Windows Support Tools ist, zur Verfügung.
Damit ist es möglich, veraltete Objekte aufzuspüren und aus dem Verzeichnisdienst zu entfernen.
Der Schalter der dazu benötigt wird lautet /removelingeringobjects. Dieser Schalter prüft die Objekte auf einem Referenz-Domänencontroller
und vergleicht diese mit den Objekten des „veralteten“ Domänencontrollers (dem DC, auf dem gegebenenfalls veraltete Objekte vorhanden sind).
Zuerst sollte man sich die veralteten Objekte anzeigen lassen. Dies geht z.B. mit folgendem Befehl (bei aktiviertem Strict Replication Consistency):
REPADMIN /removelingeringobjects <DNS-Name des “veralteten” DCs> <GUID eines “aktuellen” DCs> <Verzeichnispartition worin sich die veralteten
Objekte befinden> /Advisory_Mode.
Als Beispiel:
Repadmin /removelingeringobjects alterdcon.intra.dikmenoglu.de FB1E6374-47A3-23C8-DE2F-3685A2F79268 DC=intra,DC=dikmenoglu,DC=de /Advisory_Mode
Hinweis: Um die GUID eines DCs herauszufinden, kann man z.B. den Befehl REPADMIN /Showrepl <DC-Name> eingeben.
Der Parameter /Advisory_Mode protokolliert dabei im Verzeichnisdienstprotokoll die Ereignis-ID 1946 für jedes existierende veraltete Objekt.
Wenn nun der gleiche Befehl, aber diesmal ohne den Parameter /Advisory_Mode ausgeführt wird, werden alle aufgelisteten veralteten Objekte
vom veralteten Domänencontroller entfernt. Dabei wird die Ereignis-ID 1945 im Verzeichnisdienstprotokoll protokolliert.
Weiterhin kann man sich mit dieser Abfrage, Konflikt-Objekte anzeigen lassen:
dsquery * forestroot -gc -attr distinguishedname -scope subtree -filter „(name=*\0ACNF:*)“
Das Verzeichnisdienstprotokoll liefert bei veralteten Objekten ebenfalls wichtige Informationen.
The Repadmin.exe tool does not report existing lingering objects in Windows Server 2003
Event ID 2108 and Event ID 1084 occur during inbound replication of Active Directory in Windows 2000 Server and in Windows Server 2003
Weitere Informationen:
Windows Server Tombstone-Wiederbelebung in Active Directory -- TechNet Magazine, September 2007
Creating and Deleting Objects in Active Directory Domain Services
Viewing deleted objects in Active Directory
Deleting Items from Active Directory
Phantoms, tombstones and the infrastructure master
How the Active Directory Replication Model Works
Replication Collisions in Windows 2000
Wenn es notwendig ist, dass Domänencontroller durch eine Firewall miteinander kommunizieren (replizieren) müssen, sollten folgende Dienste mit ihren entsprechenden Ports und Protokollen zu den Domänencontrollern durchgeleitet werden:
-
RPC: 135 TCP und UDP
-
Network Basic Input/Output System (NetBIOS) name service: 137 TCP und UDP, 138 UDP und 139 TCP
-
Dynamische RPC Portzuweisung: 1024-65535 TCP
-
Server Message Block (SMB) über IP / Microsoft-DS: 445 TCP und UDP
-
Lightweight Directory Access Protocol (LDAP): 389 TCP und UDP
-
LDAP über SSL: 636 TCP
-
Globaler Katalog (GC) LDAP: 3268 TCP
-
Globaler Katalog LDAP über SSL: 3269 TCP
-
Kerberos: 88 TCP und UDP
-
Domain Name Service (DNS): 53 TCP und UDP
-
Windows Internet Name Service (WINS): 1512 TCP und UDP
-
WINS Replikation (falls benötigt): 42 TCP und UDP
Dem aufmerksamen Administrator fällt nun auf, dass die „dynamische RPC Portzuweisung“ ein Problem darstellen könnte. In der Tat, möchte man nicht die Ports von 1024 bis 65535 öffnen, deshalb ist es ratsam zu prüfen, welche Ports an der Firewall geblockt werden, um nach und nach die Ports freizugeben und nicht alle auf einmal. Abgesehen davon, lieber einen Port zu wenig aufgemacht, als einen zuviel. Deshalb muss jedes Unternehmen vor dem öffnen der Ports genauestens prüfen, welche Ports für welche Active Directory Aufgaben notwendig sind.
Man kann aber auch eine gewisse Portanzahl für die „dynamische RPC Portzuweisung“ durch einen Registry-Eintrag fest vorgeben.
How to configure RPC dynamic port allocation to work with firewalls
Den meisten Verkehr durch eine Firewall, verursachen die Authentifizierungsanforderungen, als die wären:
- Dateiserverzugriff
- DNS Abfragen
- Vertrauensstellungen
- Benutzeranmeldung
- Verbindung zwischen Mitgliedsservern und Domänencontrollern
- Active Directory Replikation
Falls Memberserver wie z.B. Windows Exchange im Perimeter-Netzwerk, Verbindung mit dem internen Netzwerk haben sollen, ist es empfehlenswert die notwendigen Protokolle und Ports (für das Active Directory sowie die benötigten Dienste) von der jeweiligen IP-Adresse zum jeweiligen Domänencontroller auf der Firewall zu beschränken.
Wenn Standorte (Niederlassungen) und somit ggf. Subdomänen erstellt werden, sind weitere Regeln auf der Firewall zu erstellen, um die Vertrauensstellung sowie Active Directory Replikation zuzulassen.
Weitere Informationen:
Active Directory and Active Directory Domain Services Port Requirements
Active Directory Replication over Firewalls
Active Directory in Networks Segmented by Firewalls
How to configure Windows Server 2003 SP1 firewall for a Domain Controller
How to configure a firewall for domains and trusts
Restricting Active Directory replication traffic to a specific port
The default dynamic port range for TCP/IP has changed in Windows Vista and in Windows Server 2008
Exchange 2000 Windows 2000 connectivity through firewalls
Service overview and network port requirements for the Windows Server system
|
Copyright © 2010 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|