Lingering Objects in Active Directory erkennen und sicher entfernen
Mittwochmorgen, 8 Uhr: Ein Benutzer, der vor Monaten gelöscht wurde, steht wieder im Adressbuch. Eine längst entfernte Gruppe taucht auf einem DC in der Außenstelle auf. repadmin meldet Fehler 8606, im Protokoll steht Ereignis 1988. Der Löschvorgang von damals ist zurückgekommen. Willkommen bei den Lingering Objects.
Woher kommen gelöschte Objekte zurück?
Ein gelöschtes Objekt verschwindet im Active Directory nicht sofort. Es wird zum Tombstone, der die Löschung an alle anderen DCs repliziert. Erst nach Ablauf der Tombstone Lifetime (TSL) räumt die Garbage Collection den Tombstone endgültig weg. Bei allen aktuell unterstützten Windows-Server-Versionen sind das standardmäßig 180 Tage.
Ein DC, der länger als die TSL nicht repliziert hat, bekommt die Löschung nie mit. Für ihn lebt das Objekt weiter. Ändert sich irgendwann ein Attribut daran, schickt er es an seine Partner – und die kennen es nicht mehr.
| Strict Replication Consistency am Ziel-DC | Was passiert |
|---|---|
| 1 (strikt) | Replikation der Partition von diesem Quell-DC wird blockiert. Ereignis 1988, Fehler 8606. |
| 0 (locker) | Der Ziel-DC fordert das komplette Objekt an und legt es neu an. Ereignis 1388. Das gelöschte Objekt ist wieder da. |
Typische Auslöser
- Ein DC war länger als die TSL ausgeschaltet oder eingelagert
- Die eingehende Replikation eines Standorts war über Monate gestört
- Die Systemuhr eines DCs wurde vor- oder zurückgestellt
- Eine Systemstatus-Sicherung älter als die TSL wurde eingespielt
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters als REG_DWORD.Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters' -Name 'Strict Replication Consistency' -ErrorAction SilentlyContinue repadmin /showattr DC1 "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=contoso,DC=com" /atts:tombstonelifetime
Diagnose: Wer hält welche Leichen?
1. Ereignisse im Protokoll „Directory Service“
Ereignis 1988 zeigt: Ein strikter DC hat ein Lingering Object erkannt und blockiert. Es nennt Quell-DC, Objekt-DN und Objekt-GUID. Ereignis 1388 ist die schlechte Nachricht: Ein lockerer DC hat das Objekt bereits neu angelegt. Ereignis 2042 meldet, dass seit der letzten Replikation mit einem Partner mehr Zeit als die TSL vergangen ist.
Get-WinEvent -FilterHashtable @{LogName='Directory Service'; Id=1988,1388,2042} |
Select-Object TimeCreated, Id, MachineName, Message | Format-List
2. Replikationsstatus im ganzen Wald
In repadmin heißt Ereignis 1988 Fehler 8606 („Insufficient attributes were given to create an object“), Ereignis 2042 heißt Fehler 8614.
repadmin /replsummary repadmin /showrepl * /csv > C:\ISW\showrepl.csv
3. Objekt-Metadaten prüfen
Für jedes Objekt aus Ereignis 1988 zeigt repadmin /showobjmeta, wann es gelöscht wurde. Liegt die Löschung genau an der TSL-Grenze, ist es nur vorübergehend und verschwindet mit der nächsten Garbage Collection innerhalb von etwa 12 Stunden.
repadmin /showobjmeta DC3.contoso.com "<GUID=Objekt-GUID aus Ereignis 1988>"
Beheben mit repadmin /removelingeringobjects
repadmin vergleicht eine Partition auf dem Ziel-DC mit einem Referenz-DC und entfernt alles, was dort als gelöscht gilt. Der Referenz-DC muss eine aktuelle, beschreibbare Kopie der Partition halten. Seine DSA-GUID steht ganz oben in repadmin /showrepl.
- Referenz-DC wählen und DSA-GUID ermitteln.
- Abgleich mit /advisory_mode – es wird nur protokolliert, nichts gelöscht.
- Gefundene Objekte auf dem Ziel-DC (Ereignis 1946) gegenlesen.
- Denselben Befehl ohne /advisory_mode ausführen.
- Für jede Partition wiederholen: Domäne, Konfiguration, Schema, DomainDnsZones, ForestDnsZones.
- Für jeden weiteren DC wiederholen, der Lingering Objects haben könnte.
# 1. DSA-GUID des Referenz-DCs
repadmin /showrepl DC1
# 2. Prüflauf
repadmin /removelingeringobjects DC3.contoso.com 4a8717eb-8e58-456c-995a-c92e4add7e8e "DC=contoso,DC=com" /advisory_mode
# 3. Ergebnis gegenlesen
Get-WinEvent -ComputerName DC3 -FilterHashtable @{LogName='Directory Service'; Id=1946}
# 4. Bereinigung
repadmin /removelingeringobjects DC3.contoso.com 4a8717eb-8e58-456c-995a-c92e4add7e8e "DC=contoso,DC=com"
# 5. weitere Partitionen, z. B.
repadmin /removelingeringobjects DC3.contoso.com 4a8717eb-8e58-456c-995a-c92e4add7e8e "CN=Configuration,DC=contoso,DC=com" /advisory_mode
Globale Kataloge nicht vergessen
Ein GC hält von den anderen Domänen des Waldes nur lesbare Teilkopien – und auch dort können Lingering Objects liegen, etwa eine gelöschte universelle Gruppe, die noch im Zugriffstoken steckt. Der Ziel-DC darf eine lesbare Kopie halten, der Referenz-DC nie. Als Referenz dient also ein DC der jeweiligen Domäne. Die bewährte Reihenfolge: erst alle beschreibbaren DCs einer Partition gegeneinander bereinigen, dann die GCs mit lesbarer Kopie gegen einen sauberen beschreibbaren DC.
repadmin /removelingeringobjects GC1.contoso.com <DSA-GUID FDC1> "DC=fabrikam,DC=contoso,DC=com" /advisory_mode
Fallstricke
⚠️ Den Schutz abschalten, damit es wieder repliziert. Der Klassiker unter Zeitdruck: Strict Replication Consistency auf 0 setzen oder „Allow Replication With Divergent and Corrupt Partner“ eintragen. Die Replikation läuft dann tatsächlich wieder – und jeder Partner legt das Lingering Object neu an (Ereignis 1388). Gelöschte Benutzer und Gruppen verteilen sich im ganzen Wald. Laut Microsoft lassen sich Objekte nach Ereignis 1388 nicht mehr mit repadmin oder dem Lingering Object Liquidator v2 entfernen. allowDivergent ist ein Werkzeug für nach der Bereinigung und wird nach der ersten erfolgreichen Replikation sofort wieder entfernt.
# erst NACH der Bereinigung repadmin /regkey DC1.contoso.com +allowDivergent repadmin /regkey DC1.contoso.com -allowDivergent # Dauerzustand auf allen DCs repadmin /regkey * +strict
Vorbeugen und Compliance
- Strict Replication Consistency auf allen DCs auf 1 setzen
- Replikation täglich prüfen, DCs ohne eingehende Replikation seit 50 % der TSL auf eine Beobachtungsliste
- Keine DCs „auf Halde“ und keine Systemstatus-Sicherungen älter als die TSL einspielen
- Saubere Zeithierarchie, verkürzte TSL wieder auf 180 Tage anheben
- Ereignisse 1988, 1388, 2042 sowie die Fehler 8606 und 8614 zentral überwachen
Das zahlt direkt auf die Anforderungen ein: BSI IT-Grundschutz APP.2.2 (Active Directory Domain Services), CON.3 (Datensicherungskonzept) und DER.4 (Notfallmanagement) sowie NIS2 Art. 21 Abs. 2 lit. c mit Backup-Management, Wiederherstellung und Aufrechterhaltung des Betriebs.
Fazit
Fehler 8606 ist nicht das Problem, sondern die Notbremse. Wer sie löst, verteilt die Leichen im ganzen Wald. Mit sauberem Referenz-DC, Prüflauf vor jedem Löschen und Disziplin bei Partitionen und globalen Katalogen ist eine Domäne mit wenigen DCs in 60 bis 120 Minuten bereinigt.
Quellen: Microsoft Learn – „Active Directory Replication Error 8606: Insufficient attributes were given to create an object“; Microsoft Learn – „Active Directory replication Event ID 1388 or 1988: A lingering object is detected“; Microsoft Learn – „Active Directory replication Event ID 2042: It has been too long since this machine replicated“; Microsoft Learn – „Information about lingering objects in a Windows Server Active Directory forest“; Microsoft Learn – „Description of the Lingering Object Liquidator tool“.
ISW Handbuch Lingering-Objects
Send download link to:
