AD deaktivierte Computer whenChanged Review: Nachweise

Was umfasst die AD deaktivierte Computer whenChanged Review?

Eine AD deaktivierte Computer whenChanged Review beginnt mit einem derzeit deaktivierten Computerkonto und einem alten Änderungszeitstempel im Verzeichnis. Sie klärt, ob das Konto in Active Directory verbleiben soll, wer diese Entscheidung verantwortet und welche Nachweise seine Außerbetriebnahme stützen. Der Zeitstempel hilft, Untersuchungen zu priorisieren; er belegt nicht, wann das Konto deaktiviert wurde.

Diese Unterscheidung ist wichtig, wenn aus einer Bereinigungsliste eine Löschwarteschlange wird. Ein deaktiviertes Konto kann zu einer ausgemusterten Arbeitsstation, einem vorübergehend isolierten Rechner, einer Dienstidentität oder einer Infrastruktur gehören, für die ein gesondertes Außerbetriebnahmeverfahren aussteht. Ein Audit-Befund liefert keine dieser betrieblichen Entscheidungen. Halten Sie den aktuellen Kontostatus, den Nachweis der Deaktivierung und die Freigabe zur Außerbetriebnahme als getrennte Nachweise fest.

Die hier beschriebene Prüfung folgt dem Befund COMPUTER_DISABLED_NOT_DELETED in etc-collector. Sie führt weder einen allgemeingültigen Löschplan ein noch belegt sie anhand eines alten Zeitstempels einen Angriff. Das Ergebnis ist eine dokumentierte Entscheidung zu einem identifizierten Objekt: es mit einer verantworteten Begründung beibehalten, fehlende Nachweise untersuchen oder es nach Klärung seiner Abhängigkeiten durch ein freigegebenes Verfahren außer Betrieb nehmen.

Funktionsweise: Die letzte Änderung belegt keine Deaktivierung

Die Microsoft-Referenz zum Attribut whenChanged definiert den Wert als Datum der letzten Objektänderung. Das System aktualisiert ihn bei jeder Änderung des Objekts. Der Wert wird nicht repliziert; dokumentieren Sie deshalb, welcher Domain Controller die Beobachtung geliefert hat und wann Sie ihn ausgelesen haben.

Das Setzen des deaktivierten Zustands verändert das Objekt, doch der aktuelle Wert von whenChanged identifiziert diesen Vorgang nicht. Eine spätere Änderung kann den früheren Zeitstempel ersetzen, obwohl das Konto deaktiviert bleibt. Ein aktueller Wert belegt daher keine kürzlich erfolgte Deaktivierung; ein alter Wert liefert weder den Akteur noch den Grund oder die Freigabe. Behandeln Sie das Attribut als Änderungsbeobachtung vom gewählten DC und nicht als eigenes Feld für das Deaktivierungsdatum.

Halten Sie diese Unterscheidungen im Prüfprotokoll fest:

Nachweis	Beantwortete Frage	Grenze
Aktueller `userAccountControl`-Wert und Aktivierungsstatus	Ist dieses Konto beim aktuellen Auslesen deaktiviert?	Datiert den Übergang nicht und erklärt seinen Zweck nicht
`whenChanged`, DC und Auslesezeitpunkt	Wann wurde das Objekt auf diesem DC zuletzt geändert?	Identifiziert weder das geänderte Attribut noch den Deaktivierungsvorgang
Ein relevantes aufbewahrtes Ereignis zur Kontoänderung	Welche protokollierte Änderung erfolgte wann und unter welchem Subjekt?	Nur hilfreich, wenn das Ereignis den Übergang tatsächlich belegt
Verantwortlicher und Außerbetriebnahmeprotokoll	Sind Beibehaltung oder Außerbetriebnahme beabsichtigt und freigegeben?	Ein Verzeichniszeitstempel kann diese Entscheidung nicht ersetzen
Inventar der Abhängigkeiten und Wiederherstellungsdaten	Was muss vor der Entfernung verfügbar bleiben?	Muss unabhängig vom Detektor geprüft werden

Unser Leitfaden zur Hygiene von Active-Directory-Computerobjekten bietet den breiteren Lebenszykluskontext einschließlich Domain Controllern, LAPS und veralteten Computerobjekten. Seine beispielhaften Bereinigungsintervalle belegen kein Deaktivierungsdatum und werden für diese Prüfung nicht als Schwellenwerte übernommen. Eine Beobachtung zur letzten Anmeldung oder zum Computerkontokennwort würde eine andere Frage beantworten; keine davon ersetzt hier den Nachweis der Kontodeaktivierung.

Erkennung: Aktuellen Zustand feststellen und den Übergang untersuchen

Schritt 1: Das genaue Objekt von einem benannten DC auslesen

Verwenden Sie das ActiveDirectory-Modul auf einer autorisierten Administrationsarbeitsstation. Die Microsoft-Referenz zu Get-ADComputer dokumentiert -Identity, -Properties und -Server. Fordern Sie die LDAP-Attribute ausdrücklich an und benennen Sie einen Verzeichnisserver, statt sich auf eine implizite Auswahl zu verlassen:

$computer = Get-ADComputer -Identity 'PC01' -Server 'dc01.contoso.com' -Properties whenChanged,userAccountControl,objectClass -ErrorAction Stop
$computer | Select-Object DistinguishedName,ObjectGUID,SID,Enabled,whenChanged,userAccountControl,objectClass

Die Feldauswahl verwendet die von Microsoft dokumentierte Select-Object-Syntax. Bewahren Sie neben den angezeigten Feldern die Computeridentität, den gewählten DC, den Auslesezeitpunkt und das Erfassungsergebnis auf. Eine fehlgeschlagene Abfrage ist ein unvollständiger Nachweis. Ein nicht verfügbares Attribut ist nicht allein deshalb ein verlässliches negatives Ergebnis, weil die Erfassung ein Objekt zurückgegeben hat.

Der untersuchte LDAP-Parser leitet Disabled aus dem Bit ACCOUNTDISABLE, 0x0002, in userAccountControl des Verzeichnisses ab. Die angezeigte Eigenschaft Enabled und das rohe Attribut liefern Beobachtungen zum aktuellen Zustand, die miteinander abzugleichen sind. Sie protokollieren nicht, wie lange das Konto bereits deaktiviert ist. Wenn das aktuelle Auslesen dem Audit widerspricht, untersuchen Sie Erfassungszeitpunkt, Zielidentität und DC-Beobachtungen, bevor Sie auf Grundlage des älteren Befunds handeln.

Schritt 2: Ereignis 4742 nur nutzen, soweit seine Nachweise zutreffen

Microsoft dokumentiert Ereignis 4742, ein Computerkonto wurde geändert, in der Unterkategorie Audit Computer Account Management. Es wird auf Domain Controllern erzeugt. Prüfen Sie die relevanten Security-Protokolle der DCs oder deren erfasste Kopien; Audit-Konfiguration und Aufbewahrung müssen den vermuteten Übergang hinreichend abdecken.

Grenzen Sie die Untersuchung im SIEM auf Ereignis 4742 und die TargetSid des geänderten Kontos ein. Prüfen Sie das rohe Ereignis und nicht nur eine normalisierte Zusammenfassung. Bewahren Sie Ereigniszeitpunkt, ausgebenden DC, Datensatzkennung, Zielidentität, Subjektidentität, OldUacValue, NewUacValue und die Informationen zu geänderten Kontosteuerungsflags auf. Vergleichen Sie jeden behaupteten Deaktivierungsübergang mit dem freigegebenen Änderungs- oder Vorfallsprotokoll und dem aktuellen Auslesen des Verzeichnisses. Ein übereinstimmender Kontoname allein liefert schwächeren Kontext als die verifizierte Ziel-SID.

Die Ereignisdokumentation sagt ausdrücklich, dass manche Änderungen kein Ereignis 4742 erzeugen. Andere Ereignisse können bei sämtlichen angezeigten geänderten Attributen Bindestriche enthalten, sodass das geänderte Attribut unbestimmt bleibt. Ein 4742-Eintrag für das Objekt ist daher nicht automatisch ein Nachweis seiner Deaktivierung. Er kann eine andere Kontoänderung dokumentieren, und eine Protokollsuche deckt möglicherweise den maßgeblichen DC oder Zeitraum nicht ab.

Die alten und neuen UAC-Felder in 4742 verwenden die SAM-Implementierung der Kontoflags, deren Definitionen sich von LDAP-userAccountControl unterscheiden. Wenden Sie die LDAP-Maske 0x0002 nicht auf diese Ereignisfelder an, um einen Deaktivierungsübergang zu behaupten. Interpretieren Sie den protokollierten Übergang anhand der im Ereignis dokumentierten Kontoflagdefinitionen und bewahren Sie die Rohwerte für die Prüfung auf.

Schritt 3: Nachweise mit der Zuständigkeit abgleichen

Fragen Sie den verantwortlichen Eigentümer, ob der Rechner weiterhin benötigt wird, vorübergehend isoliert, ersetzt oder förmlich außer Betrieb genommen wurde. Verknüpfen Sie die Antwort mit der genauen Verzeichnisidentität. Halten Sie den Deaktivierungsgrund, die verfügbaren Nachweise des Übergangs und die Entscheidung zur Außerbetriebnahme getrennt fest. Wenn historische Nachweise fehlen, beschreiben Sie diese Lücke ausdrücklich, statt aus der letzten Objektänderung ein Datum abzuleiten.

Eine unerklärte Änderung an einer kritischen Identität muss vor der Lebenszyklusbereinigung untersucht werden. Umgekehrt kann eine freigegebene Entscheidung zur Beibehaltung berechtigt sein, auch wenn der Detektor das Objekt weiterhin meldet. Dokumentieren Sie, wer diese Entscheidung erneut prüfen wird und welche Bedingung eine Außerbetriebnahme rechtfertigen würde. Die Beseitigung des Befunds ist für sich genommen keine betriebliche Anforderung zur Löschung des Kontos.

Abhilfe: Abhängigkeiten vor der freigegebenen Entfernung prüfen (Remediation)

Schritt 1: Das Objekt einordnen und Unklarheiten beseitigen

Bestätigen Sie Objektklasse und betriebliche Rolle, bevor Sie ein Außerbetriebnahmeverfahren wählen. Der Detektor schließt Domain Controller oder group managed service accounts nicht ausdrücklich aus. Ein Domain Controller benötigt sein passendes Außerbetriebnahmeverfahren; bei einer Dienstidentität müssen die Dienstabhängigkeiten geprüft werden. Ein allgemeines Beispiel zur Entfernung einer Arbeitsstation berechtigt nicht dazu, dieselbe Aktion auf jedes vom Collector gelieferte Objekt anzuwenden.

Gleichen Sie aktuellen Kontostatus, Antwort des Eigentümers und Außerbetriebnahmeprotokolle ab. Stellen Sie ungeklärte Fälle zurück und weisen Sie die Verantwortung für den nächsten Schritt zu. Dieses Verfahren legt keine neue allgemeine Altersfrist fest: Verstrichene Zeit kann nicht belegen, dass Dienste, Datensätze oder Wiederherstellungsanforderungen nicht mehr benötigt werden.

Schritt 2: Untergeordnete Objekte und Wiederherstellungsabhängigkeiten inventarisieren

Lesen Sie die unmittelbar untergeordneten Objekte des verifizierten Computerobjekts mit den von Microsoft dokumentierten Get-ADObject-Suchparametern aus. Dieses Beispiel verwendet das oben zurückgegebene $computer und fordert Kennungen sowie Objektklassen an, keine Wiederherstellungsgeheimnisse:

Get-ADObject -LDAPFilter '(objectClass=*)' -SearchBase $computer.DistinguishedName -SearchScope OneLevel -Server 'dc01.contoso.com' -ErrorAction Stop |
    Select-Object DistinguishedName,ObjectGUID,ObjectClass

OneLevel durchsucht nur unmittelbar untergeordnete Objekte. Hat ein untergeordnetes Objekt eigene Nachfahren oder ist das Inventar unvollständig, untersuchen Sie diese Struktur und ihren Zweck, bevor Sie fortfahren. Ein leeres Ergebnis bei ungeprüfter Sichtbarkeit beweist nicht, dass keine abhängigen Objekte existieren. Erfassen Sie Zugriffsfehler und einen unklaren Suchumfang als offene Inventarpunkte.

Beziehen Sie BitLocker-Wiederherstellungsinformationen in die Abhängigkeitsprüfung ein. Unser Leitfaden zur Prüfung der BitLocker-Wiederherstellung in AD: Verzeichniseintrag mit dem aktuellen Wiederherstellungsschutz des Volumes abgleichen erklärt, warum ein Wiederherstellungsobjekt dem tatsächlich auf dem Volume vorhandenen Wiederherstellungsschutz entsprechen muss. Seine bloße Existenz belegt keine nutzbare Wiederherstellung, und sein Datum belegt nicht, wann das Computerkonto deaktiviert wurde.

Vereinbaren Sie vor der Computerentfernung, wie benötigte Wiederherstellungsinformationen und andere Daten untergeordneter Objekte gemäß dem freigegebenen Wiederherstellungs- und Aufbewahrungsverfahren der Organisation verfügbar bleiben. Halten Sie Geheimnisse aus Bereinigungstickets und SIEM-Datensätzen heraus. Dokumentieren Sie die Entscheidung zu den Abhängigkeiten und den verantwortlichen Eigentümer, statt Wiederherstellungskennwörter in die Nachweise zu kopieren. Dies ist eine Abhängigkeitsprüfung für die Außerbetriebnahme; der verlinkte Leitfaden liefert das gesonderte Verfahren zur Prüfung von Volume und Schutzvorrichtung.

Schritt 3: Nur die freigegebene Entfernung eines einzelnen Objekts vorab anzeigen und ausführen

Wenn die Prüfungen von Zuständigkeit, Außerbetriebnahme, Abhängigkeiten und Wiederherstellung abgeschlossen sind, verwenden Sie die Microsoft-Remove-ADComputer-Syntax für das verifizierte Objekt. Die Dokumentation unterstützt eine GUID als Identität, einen expliziten Server und -WhatIf. Die folgende Vorschau führt keine Entfernung aus:

Remove-ADComputer -Identity $computer.ObjectGUID -Server 'dc01.contoso.com' -WhatIf

Vergleichen Sie Ziel und Vorschau mit dem freigegebenen Außerbetriebnahmeprotokoll. Eine Vorschau bestätigt weder, dass der Rechner ungenutzt ist, noch, dass Wiederherstellungsdaten erhalten bleiben oder die Aktion freigegeben wurde. Lesen Sie das aktuelle Objekt vor dem autorisierten Vorgang erneut aus, falls sich die Nachweise geändert haben könnten.

Erst nach dieser Validierung behält der Befehl für ein einzelnes Objekt eine ausdrückliche Bestätigungsabfrage bei:

Remove-ADComputer -Identity $computer.ObjectGUID -Server 'dc01.contoso.com' -Confirm

Wenn untergeordnete Objekte, Schutzmechanismen oder ein anderer Fehler die Entfernung verhindern, stoppen Sie und beheben Sie die konkrete Ursache durch das freigegebene Verfahren. Machen Sie aus einem Fehler keine rekursive Löschung des Computers und seiner Nachfahren. Bewahren Sie das tatsächliche Befehlsergebnis auf; ein versuchter Vorgang beweist nicht, dass das Konto entfernt wurde.

Schritt 4: Die Prüfung mit Nachweisen abschließen

Dokumentieren Sie die endgültige Entscheidung, die freigebende Person, die Entscheidungen zu Abhängigkeiten und das Ergebnis des Vorgangs. Verifizieren Sie das Verzeichnisergebnis durch ein autorisiertes Auslesen der genauen Identität auf dem protokollierten DC und bewahren Sie jeden Fehler sowie seine Bedeutung auf. Bestätigen Sie, dass erforderliche Wiederherstellungsinformationen über das vereinbarte Verfahren weiterhin verfügbar sind. Dokumentieren Sie bei einem beibehaltenen Objekt den Grund und die verbleibende Untersuchung, statt die Abhilfe als abgeschlossen zu melden.

Wie EtcSec dies erkennt

Im untersuchten Collector-Commit 20268a321609c193b79c5da6764f3f56950449cb ist COMPUTER_DISABLED_NOT_DELETED ein Befund mit dem Schweregrad Low. Sein Detect() untersucht erfasste Computer und berücksichtigt ein Objekt nur, wenn Disabled wahr ist, WhenChanged nicht null ist und WhenChanged.Before(Now.AddDate(0, 0, -30)) wahr ist. Der Vergleich ist strikt: Ein Zeitstempel, der dem Grenzwert entspricht, wird ausgeschlossen.

Der Grenzwert zieht 30 Kalendertage vom Now des Audits ab. Er ist ein Maßstab für die betriebliche Hygiene in etc-collector, keine von Microsoft oder einem anderen benannten Standard vorgeschriebene Löschfrist. Eine spätere Objektänderung verschiebt whenChanged nach vorn und kann dieses Signal aufschieben, während das Konto deaktiviert bleibt.

Im untersuchten LDAP-Provider wird ein fehlender oder ungültiger whenChanged-Wert zu einem Nullzeitpunkt, den dieser Detektor überspringt. Ein fehlender oder syntaktisch ungültiger userAccountControl-Wert wird zu null, sodass der Parser das Objekt nicht als deaktiviert markiert. Der Standardfilter für Computer lautet (objectClass=computer). Obwohl der Parser eine gMSA-Klasse identifizieren kann, enthält dieses Detect() keinen ausdrücklichen Ausschluss von Domain Controllern oder gMSAs.

Der Detektor ermittelt weder Deaktivierungsdatum, Eigentümer, Freigabe der Außerbetriebnahme, untergeordnete Objekte, Wiederherstellungsabhängigkeiten noch eine unterstützende Ereignishistorie. Ein positiver Befund eröffnet die oben beschriebene Nachweisprüfung. Ein Ergebnis von null Befunden kann diese unabhängigen Fragen nicht abschließen, insbesondere bei unklarer Erfassung oder Attributverfügbarkeit.