Lingering Objects – Was ist das eigentlich?

Vereinfacht ausgedrückt sind „Lingering Objects“ veraltete Active Directory Objekte, die gelöscht wurden, aber von DCs, die während der „Tombstone Lifetime period“ nicht repliziert wurden, wiederhergestellt worden sind.

Wie kann das passieren? Wird ein Objekt im AD gelöscht, existiert dieses immer noch im AD als „Tombstone“ (Grabstein). Dieser Tombstone enthält nur die wichtigsten Attribute des Objektes und wird in den AD Container “Deleted Objects” verschoben. Der Inhalt dieses Containers ist über die herkömmlichen AD Tools wie z.B. ADUC (Active Directory Users and Computers) nicht sichtbar. Um sich den Inhalt anzusehen, ist ein LDAP Tool wie z.B. LDP.exe erforderlich. Das gelöschte Objekt bleibt bis zum Ablauf der Tombstone Lifetime period (bis Windows 2003 60 Tage default, ab Windows 2003 SP1 180 Tage default) in diesem Container und wird erst nach Ablauf dieser Periode vom “garbage collection process”, der per default alle 12 Stunden auf jedem DC läuft, aus dem AD gelöscht.

Nehmen wir an, ein DC ist für diesen Zeitraum offline. Vielleicht kann er auch (warum auch immer)  die Replikation nicht erfolgreich durchführen. Kommt der DC nun nach Ablauf der Tombstone Lifetime period wieder online, geht er davon aus, dass das Objekt zu den anderen DCs repliziert werden muss, weil diese es ja nicht mehr haben. Das Objekt nicht direkt zu löschen, hat natürlich seine Berechtigung. Würde es sofort aus der AD Datenbank gelöscht, könnte es schnell passieren, dass andere DCs, gerade bei einer weltweiten Umgebung, nichts von der Löschung mitbekommen würden und so eben auch diese Lingering Objects entstehen würden.

 

Ein Beispiel

Im Standort Deutschland eines ADs wird ein Benutzer gelöscht. Der DC im Standort Kanada ist aber nun 60 Tage offline und kommt am 61sten Tag wieder online. Der DC in Kanada hat aber von der Löschung des Benutzers nichts mitbekommen und geht nun davon aus, dass dieser repliziert werden muss. Nun replizieren alle Partner den Benutzer und das Objekt ist im AD wieder existent. Da der Global Catalog in Kanada eine Read-only Kopie der Domäne in Deutschland hält, wird eine schreibgeschützte Kopie des eigentlich gelöschten Benutzers repliziert.

Unter diesen Umständen erhalten Sie alle möglichen skurrilen Fehler. Sie möchten z.B. einen Benutzer erstellen, der so heißt wie der vermeintlich gelöschte und bekommen die Meldung, dass dieser schon existiert. Das Phänomen kann auch zu Inkonsistenzen im AD führen. Durch Inkonsistenzen in der GAL könnte auch die Mail Zustellung gestört werden. Es könnte passieren, dass einzelne AD Partitionen nicht mehr repliziert werden. Und noch vieles mehr…

 

Lingering Objects verhindern

Um Lingering Objects zu vermeiden, gibt es folgenden Registry Schlüssel

HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ NTDS \ Parameters\Strict Replication Consistency

Ist dieser Schlüssel auf 1 gesetzt, repliziert ein DC, der länger als die Tombstone Lifetime nicht mehr „online“ war, keine  veralteten Objekte zurück an den „aktuellen“ DC. Damit wird die Entstehung von Lingering Objects verhindert.

In Windows 2000 war dieser Schlüssel noch per default auf „0“, also die Strict Replication Consistency ausgeschaltet. Wurde eine Domäne oder ein Forest von Windows 2000 also irgendwann migriert, ist diese Funktion immer noch ausgeschaltet.

Am einfachsten schalten Sie die Strict Replication Consistency mit folgendem Befehl auf einem DC ein:

Repadmin /regkey DCName +strict

Mit dem Parameter –strict „könnten“ Sie die Prüfung auch ausschalten, was Sie aber nicht tun sollten.

Sie können die Prüfung auch auf allen DCs auf einmal setzen mit

Repadmin /regkey * +strict

Achten Sie darauf, dass bei einer von Windows 2000 migrierten Domäne auch jeder neu eingerichtete DC automatisch den Schlüssel Strict Replication Consistency auf „0“ gesetzt hat!

 

Lingering Objects finden

Wie finden Sie nun heraus, ob es in Ihrem AD Lingering Objects gibt? Es gibt mehrere Events, die darauf hinweisen:

Das Event 1864 ist ein solcher Hinweis:

Event ID 1864
Source NTDS Replication
User NT AUTHORITY\ANONYMOUS LOGON
This is the replication status for the following directory partition on the local domain controller.
Directory partition:
DC=DomainDnsZones,DC=domain,DC=com

The local domain controller has not recently received replication information from a number of domain controllers. The count of domain controllers is shown, divided into the following intervals.
More than 24 hours:
2
More than a week:
1
More than one month:
1
More than two months:
1
More than a Tombstone Lifetime:
1
Tombstone Lifetime (days):
60

Dieses Event zeigt an, wie viele DCs an einem Tag, einer Woche, einem Monat, zwei Monaten oder mehr als die Tombstone Liftime nicht mehr erfolgreich repliziert haben. Der letzte Eintrag „More than a Tombstone Lifetime“ ist der entscheidende. Leider teilt das Event nicht mit, um welchen DC es sich dabei handelt 🙁

Das nächste Indiz ist das Event 2042:

Event 2042
Source: NTDS Replication

Dieses Event zeigt an, dass die strict replication enabled ist, der Quell DC nicht während der Tombstone Lifetime repliziert hat und die Replikation deshalb von dem Quell DC deaktiviert wurde. Das Event liefert die GUID des DCs im CNAME (Alias) Format, wie er im DNS zu finden ist: 4255b1a3-56e3-21e4-4b3d-4609-bce1cdd3bfcb._msdcs.domain.com. Damit kann der betroffene DC leicht identifiziert werden.

Dann gibt es noch das Event 1388:

Event 1388
Source: NTDS Replication

Description: Another domain controller (DC) has attempted to replicate into this DC an object which is not present in the local Active Directory database. The object may have been deleted and already garbage collected (a Tombstone Lifetime or more has past since the object was deleted) on this DC.

Und 1988:

Event 1988
Source: NTDS Replication

Description: Active Directory Replication encountered the existence of objects in the following partition that have been deleted from the local domain controllers (DCs) Active Directory database.  This event is being logged because the source DC contains a lingering object which does not exist on the local DCs Active Directory database. 
Source DC (Transport-specific network address): 
4255b1a3-56e3-21e4-4b3d-4609-bce1cdd3bfcb._msdcs.domain.com

 

Lingering Objects entfernen

Wie kann man diese Lingering Objects nun entfernen. Am besten mit dem Repadmin Tool.

repadmin /removelingeringobjects ZielDC QuellDCGUID DomainPartition /advisory_mode

Der ZielDC ist der DC auf dem die Lingering Objects existieren. Im Event 1988 ist dies der Wert des Source DCs

QuellDCGUID ist die GUID des „aktuellen“ Quell DCs. Um diese herauszufinden, öffnen Sie das SnapIn Active Directory Sites and Services. Gehen Sie auf die NTDS Settings des QuellDCs und sehen Sie sich unter den Eigenschaften den DNS Alias an. Dies ist die GUID, die Sie benötigen.

Als Domainpartition geben Sie noch die Partition an, die eben nicht repliziert wurde. Sicherheitshalber können Sie dies noch einmal mit repadmin /showreps überprüfen.

Verwenden Sie am besten immer beim ersten Aufruf den Parameter /advisory_mode, da damit nichts entfernt, sondern nur das Ergebnis des Befehls angezeigt wird. Erst wenn alles erfolgreich war, sollten Sie den Befehl ohne /advisory_mode aufrufen.

Nach erfolgreichem Aufruf erhalten Sie die Rückmeldung:

RemoveLingeringObjects sucessfull on ZielDC.

 

Viel Erfolg!