Lingering Objects (veraltete Objekte)

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 (0×80000000) 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 (0×04000000)” 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:




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




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




  3. 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=*CNF:*)“


 


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