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

Die dringende AD-Replikation

Yusuf Dikmenoglu — Sun, 29 Aug 2010 17:33:38 GMT

Ein weit verbreitetes Missverständnis ist, das ein Ereignis, welches die dringende AD-Replikation auslöst, sofort an alle Domänencontroller (DC) repliziert wird. Genau genommen handelt es sich bei einer dringenden AD-Replikation (urgent replication) noch nicht einmal um eine echte sofortige Replikation. In Wirklichkeit wird lediglich die Benachrichtigung, dass Änderungen auf dem Quell-DC vorliegen, an erster Stelle der Replikationswarteschlange hinzugefügt.

Genau wie bei der standortinternen (Intra-Site) Replikation, basiert die dringende AD-Replikation auf Änderungsbenachrichtigungen (change notification). Außer das beim Eintreten eines wichtigen Ereignisses die Benachrichtigung unverzüglich versendet wird, statt 15 Sekunden (bzw. 300 Sekunden unter Windows 2000) abzuwarten. Diese Änderungsbenachrichtigung wird sofort an alle Replikationspartner versendet, noch bevor die in der Replikationswarteschlange anstehenden Änderungsbenachrichtigungen verschickt werden. Jeder DC, der eine dringende Aktualisierung erhält, leitet diese ebenfalls umgehend an seine Replikationspartner weiter. Durch diese Vorgehensweise ist sichergestellt, dass alle DCs am gleichen AD-Standort innerhalb von Sekunden aktualisiert werden.

Durch die dringende AD-Replikation erhalten die Replikationspartner in gewohnter Weise sofort eine Änderungsbenachrichtigung über das RPC over IP Protokoll. Aufgrund des hohen Replikationsaufkommens werden bei der dringenden AD-Replikation standardmäßig die AD-Standortgrenzen nicht überschritten. Das lässt sich jedoch konfigurieren.

Ereignisse, die eine dringende AD-Replikation auslösen

Die dringende AD-Replikation wird bei Eintreten bestimmter Ereignisse standardmäßig nur innerhalb eines AD-Standorts durchgeführt. Dabei ist es unabhängig, unter welchem Betriebssystem die DCs betrieben werden. Ist allerdings die standortübergreifende Änderungsbenachrichtigung in der Standortverknüpfung (Site-Link) aktiviert, werden diese Ereignisse auch unverzüglich zwischen den AD-Standorten repliziert.

Siehe dazu:

Die Inter-Site (standortübergreifende) Änderungsbenachrichtigung aktivieren

Zwischen den DCs, die sich innerhalb des gleichen AD-Standorts befinden, wird die dringende AD-Replikation durch folgende Änderungstypen ausgelöst:

Benutzerkontosperrung (nachdem ein Benutzer sein Kennwort zu oft falsch eingegeben hat). Die Sperrung eines Benutzerkontos wird über die dringende AD-Replikation in erster Linie zu dem DC, der die FSMO-Rolle des PDC-Emulators innehat, repliziert. Das Entsperren eines Benutzerkontos hingegen löst keine dingende AD-Replikation aus!

Bearbeitung der Kontosperrungsrichtlinie. Die Bearbeitung der gleichen Optionen in einem PSO (Password Setting Object) löst hingegen keine dringende AD-Replikation aus! Die Änderung eines PSO wird über die normale standortinterne (Intra-Site) und standortübergreifende (Inter-Site) AD-Replikation durchgeführt.

Bearbeitung der domänenweiten Kennwortrichtlinie. Aber das Bearbeiten der Kennwortvorgaben in einem PSO löst ebenfalls keine dringende AD-Replikation aus! Die Änderung der Kennwortvorgaben innerhalb einer PSO wird ebenfalls über die normale standortinterne und standortübergreifende AD-Replikation durchgeführt.

Verschiebung der RID-Master FSMO-Rolle auf einen anderen DC.

Änderung eines LSA-Schlüssels (Local Security Authority, lokale Sicherheitsautorität). Wenn zum Beispiel das Kennwort des Computerkontos eines DCs oder für eine Vertrauensstellung geändert wird. >>

Die dringende AD-Replikation durch eine Benutzerkontosperrung

Gibt ein Benutzer sein Kennwort häufiger falsch ein, als es in der Kontosperrungsrichtlinie oder im PSO definiert ist, wird sein Benutzerkonto gesperrt. Die Benutzerkontosperrung wird dann über die dringende AD-Replikation zum PDC-Emulator repliziert. Unabhängig davon, an welchem AD-Standort dieser sich befindet.

Anschließend wird ebenfalls über die dringende AD-Replikation die Benutzerkontosperrung zu den folgenden DCs repliziert:
- Zu allen DCs der gleichen Domäne, die sich am gleichen AD-Standort befinden wie der DC der die FSMO-Rolle des PDC-Emulators innehat.
- Zu allen DCs der gleichen Domäne, die sich am gleichen AD-Standort befinden wie der DC der die Benutzerkontosperrung durchgeführt hat.
- Zu allen DCs der gleichen Domäne, die sich an einem AD-Standort befinden zu der die standortübergreifende Änderungsbenachrichtigung (und demnach die dringende AD-Replikation) mit dem AD-Standort aktiviert wurde, in dem sich der PDC-Emulator oder der DC befindet, der die Benutzerkontosperrung durchgeführt hat.
Wenn die Benutzerauthentisierung an einem DC, nicht jedoch am PDC-Emulator fehlschlägt, wird die Authentisierung auf dem PDC-Emulator wiederholt. Aus diesem Grund ist letzten Endes auch der PDC-Emulator derjenige, der das Benutzerkonto nach den Vorgaben der Kontosperrungsrichtlinie zuerst sperrt. Und nicht der DC, der die fehlgeschlagene Benutzerauthentisierung als erster entgegennahm.>

Die Replikation einer Kennwortänderung

Oftmals wird auch fälschlicherweise angenommen, dass die Kennwortänderung eines Benutzers über die dringende AD-Replikation zu allen anderen DCs repliziert wird. Kennwortänderungen werden anders als die normale AD-Replikation und anders als die dringende AD-Replikation durchgeführt.

Bei der Kennwortänderung eines Domänen-Benutzers oder eines Computerkontos repliziert der DC, der die Kennwortänderung durchgeführt hat, umgehend das neue Kennwort durch den sicheren Kanal zum PDC-Emulator. Das neue Kennwort wird sogar dann zum PDC-Emulator repliziert, wenn dieser an einem anderen AD-Standort steht. Dabei greift der DC auch nicht auf die Bridgeheadserver an den AD-Standort zurück. Der DC, auf dem das Kennwort geändert wurde, nutzt stattdessen eine RPC over IP-Verbindung direkt zum PDC-Emulator, um das Kennwort zu aktualisieren.

Authentisiert sich der Benutzer danach an einem DC (z.B. aus einem anderen AD-Standort) der das neue Kennwort noch nicht kennt, fragt der DC beim PDC-Emulator nach, ob ihm ein neueres Kennwort vorliegt, bevor er dem Benutzer die Anmeldung verweigert. Falls ja, wird der Benutzer vom PDC-Emulator authentisiert und der Benutzer kann sich anmelden. Falls nicht, schlägt die Anmeldung fehl. Der PDC-Emulator hat also bei der Kennwortfrage immer das letzte Wort. Wenn die Kennwortnachfrage beim PDC-Emulator erfolgreich verlief, repliziert der PDC-Emulator das neue Kennwort unverzüglich zu dem DC, von dem die Anfrage kam. Dadurch ist sichergestellt, dass der DC nicht erneut wegen des geänderten Kennworts beim PDC-Emulator nachfrägt.

Die Kennwortaktualisierung wird sofort zum PDC-Emulator repliziert, ohne Rücksicht auf einen eventuell konfigurierten Zeitplan in der Standortverknüpfung. Anschließend wird sie innerhalb des AD-Standorts des PDC-Emulators und innerhalb des AD-Standorts des DC, der die Kennwortänderung durchgeführt hat, durch die standortinterne AD-Replikation zu den anderen DCs repliziert. Alle anderen DCs, die sich an entfernten AD-Standorten befinden, erhalten die Kennwortänderung ganz normal durch die standortübergreifende AD-Replikation.

Ist allerdings der PDC-Emulator nicht erreichbar (beispielsweise wegen Überlastung) oder schlägt die RPC over IP-Verbindung fehl, wird die Kennwortänderung über das normale Replikationsverfahren (standortintern und standortübergreifend) an alle DCs inklusive dem PDC-Emulator repliziert.

Wenn es nicht gewünscht wird, dass die Kennwortaktualisierung eines Benutzers oder eines Computers sofort zum PDC-Emulator an einem anderen AD-Standort repliziert wird, kann man dieses Verhalten unterbinden. Dazu muss folgender neuer Eintrag in die Registry erstellt werden:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters

REG_DWORD
AvoidPdcOnWan
1 = Aktiviert (True) >
Dieser Registryeintrag muss auf jedem DC erstellt werden, der eine Kennwortaktualisierung nicht sofort zu einem (an einem entfernten AD-Standort stehenden) PDC-Emulator replizieren soll. Der PDC-Emulator erhält die Kennwortaktualisierung dann ganz normal über den konfigurierten Zeitplan für die standortübergreifende AD-Replikation. Befindet sich aber der PDC-Emulator am gleichen AD-Standort wie der DC, der die Kennwortaktualisierung durchgeführt hat, wird der Registryeintrag ignoriert und das neue Kennwort wird unverzüglich zum PDC-Emulator repliziert.

Komfortabler lässt sich diese Einstellung über die folgende GPO konfigurieren:

Computerkonfiguration\Richtlinien\Administrative Vorlagen\System\Netzwerkanmeldung\Verbindung mit PDC bei Anmeldungsfehler herstellen

Wird diese Richtlinie auf Deaktiviert konfiguriert, repliziert der DC, auf dem die Kennwortänderung stattgefunden hat, das neue Kennwort ebenfalls nicht sofort zum PDC-Emulator an einem anderen AD-Standort. Stattdessen wird das neue Kennwort dann über den konfigurierten Zeitplan für die standortübergreifende AD-Replikation repliziert. Wenn sich jedoch der PDC-Emulator am gleichen AD-Standort befindet wie der die Kennwortänderung durchführende DC, wird das neue Kennwort sofort zum PDC-Emulator repliziert.

Auf der anderen Seite hat man sowohl mit dem Registryeintrag als auch mit der GPO Einfluss darauf, wie sich ein DC Verhalten soll, wenn sich ein Benutzer oder Computer mit einem für den DC fremden Kennwort authentisieren möchte. Setzt man den Registryeintrag oder konfiguriert man die GPO, leitet der DC die Kennwortabfrage nicht an den PDC-Emulator weiter, wenn dieser sich an einem anderen AD-Standort befindet.

Der Registryeintrag oder die GPO kann zum Beispiel dann sinnvoll sein, wenn sich der PDC-Emulator an einem AD-Standort befindet, der mit einer geringen Bandbreite mit anderen Standorten angebunden ist (was in unserer Hemisphäre schon kaum mehr möglich ist). Oder um bei einer Brute Force Attacke nicht zusätzlich den PDC-Emulator und die VPN-Verbindung zu belasten. Dann muss man aber in Kauf nehmen, dass der Benutzer sich über einen längeren Zeitraum nicht an der Domäne anmelden kann. >

Weitere Informationen:
Password Setting Objects erstellen und verwalten
Der RID-Master und sein RID-Pool
How the Active Directory Replication Model Works
New Password Change and Conflict Resolution Functionality in Windows

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Zwei wichtige IDs eines DCs: DC GUID und InvocationId

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

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

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

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

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

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

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

Im Gegensatz zur objectGUID ändert sich die invocationId wenn:

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

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

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

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

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

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

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

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

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Den gefilterten Attributsatz abfragen

Yusuf Dikmenoglu — Sun, 07 Mar 2010 22:32:34 GMT

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
>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Die unterschiedliche Größe der AD-Datenbank

Yusuf Dikmenoglu — Sun, 26 Apr 2009 05:55:33 GMT

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

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Troubleshooting mit REPADMIN

Yusuf Dikmenoglu — Wed, 24 Sep 2008 16:42:03 GMT

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

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Domänencontroller vergleichen

Yusuf Dikmenoglu — Sun, 20 Jul 2008 14:48:13 GMT

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

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Die Linked Value Replikation (LVR)

Yusuf Dikmenoglu — Sun, 10 Feb 2008 22:00:51 GMT

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)

>>>>>>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Active Directory-Replikationskonflikt

Yusuf Dikmenoglu — Sun, 02 Dec 2007 21:56:30 GMT

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

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Die Inter-Site (standortübergreifende) Änderungsbenachrichtigung aktivieren

Yusuf Dikmenoglu — Sun, 22 Apr 2007 21:43:35 GMT

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.>

Die dringende AD-Replikation (Urgent Replication)

Die dringende AD-Replikation wird für bestimmte wichtige Ereignisse verwendet.
Wie bei der standortinternen (Intra-Site) AD-Replikation basiert die dringende AD-Replikation auf Änderungsbenachrichtigungen. Außer dass beim Eintreten eines
wichtigen Ereignisses die Benachrichtigung unverzüglich versendet wird, anstatt 15 Sekunden (bzw. 300 Sekunden unter Windows 2000) abzuwarten.
Standardmäßig werden bei der dringenden AD-Replikation (aufgrund des hohen Replikationsaufkommens) Standortgrenzen nicht überschritten.

Die dringende AD-Replikation kann aber für die standortübergreifende (Inter-Site) AD-Replikation ebenfalls genutzt werden,
sofern die Benachrichtigungsfunktion in der Standortverknüpfung (Site-Link) konfiguriert wurde.

Auslöser einer dringenden AD-Replikation sind:

Das Benutzerkonto wurde gesperrt, durch mehrmalige falsche Kennwort-Eingabe
Das Bearbeiten der Kontosperrungsrichtlinie.
Wenn die Kennwortrichtlinie bearbeitet wird.
Bei Änderung eines LSA-Schlüssels (Local Security Authority, lokale Sicherheitsautorität),
wenn z.B. das Computerkontokennwort eines DCs oder das Kennwort für eine Vertrauensstellung geändert wird.
Wenn die RID-Master FSMO-Rolle auf einen anderen DC verschoben wird.

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 nachzufragen, ob zwischenzeitlich eine Kennwort-Änderung stattgefunden hat.

Siehe auch: Die dringende AD-Replikation

Die Änderungsbenachrichtigung für die standortübergreifende (Inter-Site) AD-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=<Domä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. Ist in dem Attribut bereits ein Wert enthalten,
gilt es diesen Wert lediglich um +1 zu erhöhen. Also wenn das Attribut Options den Wert 2 hat, muss als neuer Wert 3 eingetragen werden.

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
>

Yusuf Dikmenoglu

Lingering Objects (veraltete Objekte)

Yusuf Dikmenoglu — Fri, 06 Apr 2007 21:39:23 GMT

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>) verschoben,
der in fast allen Verzeichnispartitionen enthalten ist, außer der Schemapartition. 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 (oder höher) Domänencontroller gelöscht wurde, so wird der Ursprungsort 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:

Falls keine Netzwerkkonnektivität zur Domäne besteht.
Wenn sich auf dem DC unbemerkt Replikations-Probleme eingeschlichen haben.
Die Replikation wegen einer Fehlkonfiguration nicht durchgeführt werden kann.
Die Namensauflösung nicht ordnungsgemäß funktioniert.
Bei fehlgeschlagener Authentifizierung oder Autorisierung.
Die In-Bound (eingehende) Replikation deaktiviert/blockiert ist.
Ein Problem mit dem Datenbankspeicher besteht (die ausgeführten Transaktionen werden evtl. nicht zeitgerecht abgearbeitet und führen zu Timeouts).
die Systemuhr bzw. das Datum falsch ist.

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 > >>>>>>>>>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Active Directory Replikation durch eine Firewall

Yusuf Dikmenoglu — Thu, 28 Sep 2006 19:30:17 GMT

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

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.