AD whenCreated Review: genehmigte Bereitstellung

Was ist eine Prüfung neu erstellter AD-Objekte?

Ein AD whenCreated Review verknüpft kürzlich erstellte Verzeichnisobjekte mit genehmigter Bereitstellung. Das nützliche Ergebnis ist ein datierter Nachweis darüber, welche Benutzer, Computer und Gruppen geprüft wurden, wer für sie verantwortlich ist, welcher Antrag ihre Erstellung begründet und welche Nachweise noch ungeklärt sind. Die Gesamtzahl neuer Objekte ist ein Ausgangspunkt für diese Arbeit; sie belegt weder eine böswillige noch eine genehmigte Erstellung.

Microsoft beschreibt whenCreated als einen vom System gesetzten Erstellungszeitstempel, der repliziert wird und im globalen Katalog verfügbar ist. Er liefert ein Datum, aber weder die Identität des Antragstellers noch eine geschäftliche Begründung. Halten Sie diese Nachweisarten während der gesamten Prüfung getrennt. Microsoft Learn: When-Created attribute.

Die praktische Frage lautet, ob jede beobachtete Erstellung zu einem dokumentierten Bereitstellungsprozess gehört. Ein neuer Computer kann eine erwartete Bereitstellung sein, eine Gruppe kann eine genehmigte Anwendung unterstützen und ein Benutzer kann ein berechtigter Neuzugang sein. Diese Möglichkeiten benötigen Belege und einen verantwortlichen Eigentümer. Namen, Beschreibungen und eine vertraute OU können die Untersuchung lenken, sollten aber keinen Genehmigungsnachweis ersetzen.

Funktionsweise: Ein datiertes Objektregister aufbauen

Erfassen Sie zunächst die Domäne, die Suchbasis, den abgefragten Domänencontroller, den Erfassungszeitpunkt und den Prüfzeitraum. Bewahren Sie die Erfassungseinstellungen und etwaige Fehler zusammen mit den Objektzeilen auf. So lässt sich eine Verzeichnisbeobachtung von einer Annahme über die Abdeckung der Erfassung unterscheiden.

Führen Sie pro stabiler Objektkennung eine Prüfzeile und verwenden Sie den aktuellen Distinguished Name als lesbare Ortsangabe. Bewahren Sie die Zugehörigkeit zu den Populationen separat auf: Ein Objekt, das sowohl in der Benutzer- als auch in der Computerpopulation zurückgegeben wird, sollte beide Kennzeichnungen behalten, im Register eindeutiger Objekte aber nur einmal zählen. Das ist bei gruppenverwalteten Dienstkonten relevant, die die LDAP-Filter des Collectors in beide Populationen aufnehmen können.

Registerfeld	Was die prüfende Person erfasst	Welche Entscheidung es unterstützt
Objektidentität	Objekt-GUID, DN, Klasse und verfügbare SID	Nachweise demselben Objekt zuordnen und Beobachtungen deduplizieren
Erstellungszeit	Auf UTC normalisiertes `whenCreated`; fehlendes Datum ausdrücklich vermerkt	Das Objekt dem gewählten Prüfzeitraum zuordnen
Herkunft der Erfassung	Domäne, DC, Suchbasis, Abfragezeitpunkt und Ergebnis	Den Umfang der Beobachtung erklären
Populationszugehörigkeit	Benutzer, Computer, Gruppe oder überlappende Populationen	Populationssummen mit eindeutigen Objekten abgleichen
Bereitstellungsnachweise	Antragsreferenz, beantragter Zweck und Genehmigungsnachweis	Den dokumentierten Grund für die Erstellung feststellen
Verantwortlicher Eigentümer	Benannter Dienst- oder Geschäftsverantwortlicher und Prüfantwort	Folgemaßnahmen zuweisen, statt unerklärte Zeilen offen zu lassen
Ereignisnachweise	Passendes Erstellungsereignis oder dokumentierte Einschränkung der Abdeckung	Das Wissen über den Antragsteller bewahren
Einordnung	Genehmigt, Untersuchung erforderlich oder ungeklärt	Unsicherheit bis zum Abschluss sichtbar halten

Verwenden Sie getrennte Sammlungen für Objekte innerhalb des Zeitraums, Objekte außerhalb des Zeitraums, Objekte ohne verfügbares Datum sowie Populationen oder Bereiche, die nicht gelesen werden konnten. Eine fehlgeschlagene Abfrage ist eine fehlgeschlagene Beobachtung. Sie kann kein vertrauenswürdiges leeres Ergebnis liefern. Ebenso ist ein durch einen Datumsfilter ausgeschlossenes Objekt damit nicht als genehmigt eingestuft.

Die wöchentliche Prüfung neuer Erstellungen im wiederkehrenden AD-Auditablauf liefert den operativen Rhythmus. Dieses Register stellt die Objekt- und Bereitstellungsnachweise für diese Prüfung bereit. Halten Sie den Prüfzeitraum ausdrücklich fest, statt den zehntägigen Rückblick eines Produkts als organisatorische Richtlinie zu behandeln.

Erkennung: whenCreated mit ausdrücklichem Suchumfang lesen

Verwenden Sie einen Rechner mit dem Active-Directory-PowerShell-Modul und ein zum Lesen des Verzeichnisses autorisiertes Konto. Die folgenden Beispiele sind dokumentationsbasierte Prüfabfragen und keine Befehle, die in einem Kundenverzeichnis ausgeführt wurden. Ersetzen Sie vor der Verwendung die Beispieldomäne und den DC.

Get-ADObject dokumentiert -Filter, zusätzliche -Properties, -SearchBase, -SearchScope und -Server. Die Beispiele setzen -SearchScope Subtree, um die Suchbasis und ihre untergeordneten Bereiche einzubeziehen. Die folgenden Filter kombinieren diese Parameter mit den drei Populationsdefinitionen des Collectors und einer unteren Grenze für whenCreated. Microsoft Learn: Get-ADObject.

$reviewEnd = [DateTime]::UtcNow
$reviewStart = $reviewEnd.AddDays(-10)
$base = 'DC=contoso,DC=local'
$dc = 'dc01.contoso.local'
$properties = 'whenCreated','objectGUID','objectSid','objectClass'

$users = Get-ADObject -Filter {objectClass -eq 'user' -and (objectCategory -eq 'person' -or objectClass -eq 'msDS-GroupManagedServiceAccount') -and whenCreated -gt $reviewStart} -Properties $properties -SearchBase $base -SearchScope Subtree -Server $dc -ErrorAction Stop
$computers = Get-ADObject -Filter {objectClass -eq 'computer' -and whenCreated -gt $reviewStart} -Properties $properties -SearchBase $base -SearchScope Subtree -Server $dc -ErrorAction Stop
$groups = Get-ADObject -Filter {objectClass -eq 'group' -and whenCreated -gt $reviewStart} -Properties $properties -SearchBase $base -SearchScope Subtree -Server $dc -ErrorAction Stop

Die Abfragen mit unterer Grenze lassen ältere und nicht verfügbare Datumswerte aus. Lesen Sie für eine separate Beobachtung mit festgelegtem Suchumfang ohne Datumsprädikat:

$scopeObjects = Get-ADObject -Filter * -Properties $properties -SearchBase $base -SearchScope Subtree -Server $dc -ErrorAction Stop

Diese breitere Abfrage ist den drei Populationsabfragen nicht gleichwertig. Klassifizieren Sie ihre Objekte vor dem Vergleich. Standardmäßig schließt das Cmdlet gelöschte Objekte aus; keine der beiden Lesevarianten rekonstruiert ein vollständiges historisches Verzeichnis.

Schritt 1: Die Beobachtung bewahren

Speichern Sie die Abfragedefinitionen und ihre erfolgreichen oder fehlgeschlagenen Ergebnisse, bevor Sie die Zeilen interpretieren. Wenn eine Abfrage mit einem Fehler abbricht, erfassen Sie den Fehler und den betroffenen Suchumfang und untersuchen Sie das Erfassungsproblem. Ersetzen Sie das Ergebnis nicht durch ein leeres Array, um dann fortzufahren, als wäre die Population geprüft worden.

Bewahren Sie bei zurückgegebenen Datumswerten den Originalwert auf und normalisieren Sie die Anzeige im Register auf UTC. Bewerten Sie die untere Grenze einheitlich: Der Collector verwendet einen strikten Vergleich mit seiner Referenzzeit abzüglich zehn Tagen. Ein Zeitstempel genau auf dieser Grenze wird ausgeschlossen. Sein Code enthält keine obere Grenze an der Referenzzeit. Kennzeichnen Sie deshalb zurückgegebene Datumswerte nach dem erfassten Prüfende separat, statt sie stillschweigend in den normalen Zeitraum aufzunehmen.

Schritt 2: Eindeutige Objekte abgleichen

Führen Sie Beobachtungen anhand der Objekt-GUID zusammen, bewahren Sie alle Populationskennzeichnungen auf und vergleichen Sie das resultierende Register mit den Populationszahlen des Collectors. Erklären Sie Unterschiede anhand von Suchumfang, Limits, Datumsbehandlung und überlappenden Klassen, bevor Sie diese als unerklärte Erstellungen behandeln. Eine deduplizierte Anzahl kann berechtigterweise von der Summe der Benutzer-, Computer- und Gruppenbeobachtungen abweichen.

Behalten Sie deaktivierte Konten in der Prüfung. Ein deaktivierter Zustand beantwortet nicht, warum ein Objekt erstellt wurde oder ob sein Bereitstellungsantrag genehmigt war. Der Detektor für neue Objekte selbst schließt deaktivierte Benutzer oder Computer nicht aus.

Schritt 3: Jede Zeile mit der Bereitstellung verknüpfen

Bitten Sie den verantwortlichen Eigentümer, den Antrag und die Genehmigungsnachweise für das konkrete Objekt bereitzustellen. Gleichen Sie Kennungen, vorgesehene Klasse, Speicherort und Zweck ab, statt ein allgemeines Bereitstellungsticket zu akzeptieren, das sich auf mehrere voneinander unabhängige Objekte beziehen könnte. Erfassen Sie Abweichungen zwischen Antrag und beobachtetem Objekt als Folgemaßnahme.

Eine Antwort des Eigentümers ohne unterstützende Nachweise bleibt eine zu bewertende Aussage. Umgekehrt bedeutet eine fehlende Antwort eine ungeklärte Herkunft und ist kein Beweis für Angreiferaktivität. Halten Sie diese Ergebnisse auseinander, damit die Behebung auf die tatsächliche Nachweislücke zielt.

Erkennung: Ereignis-ID 5137 nur bei belegter Abdeckung korrelieren

Ereignis-ID 5137 erfasst die Erstellung eines Verzeichnisobjekts auf einem Domänencontroller, wenn die Erfolgsüberwachung unter Audit Directory Service Changes aktiviert ist. Microsoft legt fest, dass die SACL des übergeordneten Objekts die relevante Create-Aktion für die Objektklasse überwachen muss. Beide Kontrollen müssen bereits vor der Erstellung gegolten haben; aufbewahrte lokale oder zentrale Protokolle müssen diesen Zeitpunkt abdecken. Microsoft Learn: Event 5137.

Ordnen Sie ObjectGUID, gestützt durch ObjectDN und ObjectClass, dem Register zu. Bewahren Sie die UTC-Zeit des Ereignisses, den ausgebenden DC und die Datensatzkennung auf. SubjectUserSid, SubjectUserName und SubjectDomainName identifizieren das anfordernde Konto. SubjectLogonId kann die Sitzungskorrelation unterstützen; es identifiziert weder die Person hinter einer Automatisierung noch beweist es eine Genehmigung.

Nachweis	Verwendung bei der Prüfung	Grenze
Passendes 5137	Den Antragsteller für dieses Objekt identifizieren	Die Identität des Antragstellers ist keine Autorisierung
Historische Richtlinie und übergeordnete SACL	Die Abdeckung der Ereigniserzeugung belegen	Die aktuelle Konfiguration kann keine frühere Abdeckung beweisen
Lesbare Protokolle und Archive	Den durchsuchbaren Zeitraum feststellen	Fehlende Datensätze lassen die Herkunft ungeklärt

Der Leitfaden zur Konfiguration von Auditrichtlinien erklärt, warum Ereignisse zuerst erzeugt werden müssen. Ergänzen Sie für 5137 Nachweise zur übergeordneten Create-SACL und zur Aufbewahrung; der Erstellungszähler belegt nichts davon.

Behebung: Nicht genehmigte Erstellung und Nachweislücken klären (Remediation)

Die Behebung beginnt mit der Einordnung jedes Objekts, nicht mit der Verringerung einer Anzahl neuer Erstellungen. Genehmigte Bereitstellung sollte dokumentiert bleiben, auch solange sich das Objekt noch im Rückblickfenster befindet. Eine ungeklärte Erstellung benötigt einen Eigentümer und einen Untersuchungsweg.

Den Bereitstellungsnachweis vervollständigen. Fügen Sie Objektkennung, Antrag, Genehmigung und Eigentümerantwort zur Prüfzeile hinzu. Bestätigen Sie, dass beobachteter Zweck und Platzierung mit dem genehmigten Antrag übereinstimmen. Erfassen Sie jede begründete Ausnahme und die für ihre Klärung verantwortliche Person.
Unerklärte oder widersprüchliche Erstellung eskalieren. Bewahren Sie Verzeichnisbeobachtungen und verfügbare Ereignisdatensätze auf. Bitten Sie die Identitäts- und Dienstverantwortlichen, die vorgesehene Nutzung des Objekts und seine aktuelle Exposition zu bewerten. Führen Sie bestätigt unautorisierte Objekte durch die Incident- und Änderungsprozesse der Organisation, mit einer ausdrücklichen Entscheidung zur Eindämmung.
Erfassungslücken beheben. Prüfen Sie Suchbasen, konfigurierte Populationslimits und Abfragefehler. Wiederholen Sie die Abfragen mit festgelegtem Suchumfang, nachdem die Ursache behoben wurde, und bewahren Sie den neuen Beobachtungszeitpunkt auf. Behalten Sie frühere fehlgeschlagene Beobachtungen im Register, damit der abschließende Nachweis keine lückenlose Abdeckung suggeriert.
Künftige Ereignisabdeckung herstellen. Lassen Sie autorisierte Administratoren die wirksame Erfolgsüberwachung von Directory Service Changes und die relevanten übergeordneten Create-SACLs prüfen. Kontrollieren Sie, dass aufbewahrte Archive tatsächlich durchsucht werden können. Validieren Sie die künftige Erzeugung und Erfassung durch eine genehmigte Testerstellung und bewahren Sie die resultierenden Nachweise auf.
Den Abschluss anhand des Registers prüfen. Gleichen Sie das aktualisierte Register eindeutiger Objekte mit genehmigter Bereitstellung und dokumentierten Ausnahmen ab. Schließen Sie nur Entscheidungen ab, die durch Nachweise gestützt sind; führen Sie unbekannte Herkunft und unvollständigen Suchumfang als offene Punkte weiter.

Vermeiden Sie automatisches Löschen oder Deaktivieren allein aufgrund von Alter, einem unbekannten Namen oder einem fehlenden Erstellungsereignis. Diese Signale rechtfertigen eine Untersuchung, während die Behebungsentscheidung Nachweise über das Objekt und seine Abhängigkeiten erfordert. Die Beispiele in diesem Artikel lesen das Verzeichnis; sie autorisieren keine Verzeichnisänderung.

Wie EtcSec dies erkennt

Beim Collector-Commit 9f698083354a1cb7f625df5cb490a515823c3257 ist RECENT_OBJECTS_CREATED ein Info-Befund. Sein Detect() summiert Benutzer-, Computer- und Gruppeneinträge, deren Created-Wert ungleich null ist und strikt nach DetectorData.Now - 10 × 24 hours liegt. Zehn Tage sind eine Produktheuristik. Der Vergleich hat keine obere Grenze bei Now, und der Detektor schließt deaktivierte Konten nicht aus.

Der Befund liefert eine Gesamtzahl und die aggregierten Zähler newUsers, newComputers und newGroups. Er stellt keine objektbezogene Liste AffectedEntities bereit und bestimmt weder Antragsteller noch Absicht oder Autorisierung. Die LDAP-Parser beziehen Created aus whenCreated; fehlende Werte oder von parseADTime nicht verstandene Formate werden zu null und aus dieser Berechnung ausgeschlossen.

Die Erfassung hängt von BaseDN sowie MaxUsers, MaxGroups und MaxComputers ab. Ein Fehler beim Abrufen einer der drei Populationen stoppt die Erfassung. Die Populationen können sich überlappen: Der Benutzerfilter umfasst gMSAs, und der Computerfilter kann dieselben Objekte zurückgeben. Daher ist die summierte Anzahl kein eindeutiges Inventar aller AD-Objekte.

Verwenden Sie diesen Befund, um das oben beschriebene unabhängige Register und die Bereitstellungsprüfung anzustoßen. Eine kleinere Anzahl bei einem späteren Audit kann schlicht bedeuten, dass Objekte aus dem Rückblickfenster herausgealtert sind, sich der Suchumfang geändert hat oder die Erfassung abweicht. Prüfen Sie die Prüfentscheidungen und Nachweise direkt, bevor Sie die Arbeit abschließen.