AD Attributaenderung Freigabe: 5136-Werte zuordnen

Was bedeutet AD Attributaenderung Freigabe?

Eine Prüfung zur AD Attributaenderung Freigabe verknüpft eine dokumentierte Änderung an einem bestehenden Verzeichnisobjekt mit einer unabhängig autorisierten Entscheidung. Ihr Ergebnis ist ein Belegprotokoll: Objekt-GUID, geändertes Attribut, beobachtete gelöschte und hinzugefügte Werte, Operationskorrelations-ID, anforderndes Konto, ausgebender Domänencontroller, Ereigniszeit und Freigabebelege. Ein vertrauter Administratorname oder eine geringe Anzahl von Befunden zum Sicherheitszustand kann dieses Protokoll nicht ersetzen.

Verwenden Sie dieses Verfahren, wenn eine Verzeichnisänderung erklärt werden muss, bevor die Prüfung abgeschlossen oder eine korrigierende Änderung freigegeben wird. Beginnen Sie mit einem Objekt und einem Attribut. Bewahren Sie die ursprünglichen Ereignisse auf, stellen Sie die Erfassungsgrenzen fest und lassen Sie den autorisierten Entscheider bestätigen, ob die beobachtete Wertänderung zum Antrag passt. Die Prüfung kann mit einer belegten Freigabe, einer bestätigten unautorisierten Änderung oder einer ungeklärten Beleglücke enden; diese Ergebnisse erfordern unterschiedliche Folgemaßnahmen.

Dieser Artikel behandelt Änderungen an einem bestehenden Objekt. Verwenden Sie für neu bereitgestellte Objekte das Erstellungsregister, das whenCreated und Erstellungsbelege mit freigegebener Bereitstellung verbindet. Für den umfassenderen Vergleich zwischen vorgesehenem Zugriff und wirksamen Gruppen-, ACL- und Replikationsrechten verwenden Sie den Prüf- und Revalidierungsablauf für Abweichungen beim privilegierten Zugriff. Hier ist das Ergebnis das Belegprotokoll zur Attributänderung, keine weitere Bestandsaufnahme privilegierter Konten.

Funktionsweise: Feststellen, was 5136 zeigen kann

Microsoft dokumentiert Ereignis 5136 für Änderungen an Verzeichnisdienstobjekten. Damit das Ereignis erzeugt wird, muss die Erfolgsüberwachung von Directory Service Changes gelten, und das Objekt benötigt einen passenden SACL-Eintrag, der den relevanten Attributschreibzugriff überwacht. Die Überwachungsunterkategorie wirkt auf Domänencontrollern. Einige Objekt- oder Eigenschaftsänderungen werden aufgrund von Schemaeinstellungen nicht überwacht; die Aktivierung der Richtlinie allein belegt daher keine vollständige Abdeckung. Microsoft Learn: Event 5136, Audit Directory Service Changes.

Für eine Ersetzung beschreibt Microsoft typischerweise ein Ereignis für den gelöschten Wert, gefolgt von einem Ereignis für den hinzugefügten Wert. Behandeln Sie dieses Muster als Rekonstruktionshilfe. Es garantiert nicht, dass jede Prüfung genau zwei Datensätze enthält. Ein Attribut kann mehrere Werte haben, eine Operation kann mehrere Attribute betreffen, und die aufbewahrten Datensätze können unvollständig sein. Bewahren Sie jedes relevante Wertereignis auf und erklären Sie, wie es zur geprüften Änderung beiträgt.

Das XML-Feld OperationType unterscheidet eine Hinzufügung, %%14674, von einer Löschung, %%14675. AttributeValue enthält den an diesem Ereignis beteiligten Wert. Bewahren Sie sowohl den rohen Operationscode als auch seine Bedeutung auf. Interpretieren Sie einen hinzugefügten Wert nicht als vollständigen Attributwertsatz nach der Änderung, wenn er ein einzelnes Element eines mehrwertigen Attributs darstellen kann. Microsoft Learn: Feldbeschreibungen zu Event 5136.

OpCorrelationID verknüpft Änderungen, die zu einer LDAP-Operation gehören. Sie kann mehr als das eine geprüfte Attribut umfassen. Kombinieren Sie sie mit Objekt- und Attributidentität, Herkunft und Zeit; sie ist keine geschäftliche Ticketreferenz. Microsoft beschreibt AppCorrelationID als unbenutzt, mit einem Bindestrich als Wert. Keines der beiden Felder liefert die Freigabeentscheidung der Organisation.

Erkennung: Einen begrenzten Belegsatz erfassen

Die folgenden Befehle verwenden dokumentierte Befehls- und Parametersyntax, angepasst an diese Prüfung. Sie wurden nicht gegen eine reale Domäne ausgeführt. Lesen Sie Ereignisse von einem autorisierten Windows-Host aus; verwenden Sie für das Auslesen des Objekts das Active Directory-Modul. Ersetzen Sie den Beispiel-DC, das UTC-Intervall und die Objekt-GUID durch die tatsächlichen Eingaben des Falls. Dokumentieren Sie Berechtigungsfehler und nicht verfügbare Protokolle als fehlgeschlagene Beobachtungen, nicht als leere, erfolgreiche Suchen. Remotezugriffe mit Get-WinEvent benötigen Firewallzugriff auf den Windows Event Log-Dienst; das Cmdlet verwendet kein PowerShell-Remoting. Microsoft Learn: Get-WinEvent ComputerName.

Schritt 1: Überwachungs- und Aufbewahrungsabdeckung dokumentieren

Prüfen Sie auf jedem für den Fall relevanten DC die aktuelle Systemüberwachungsunterkategorie. Der folgende englische Name erfordert eine Installation, die diesen Namen erkennt; die dokumentierte Syntax akzeptiert auch eine Unterkategorie-GUID.

auditpol /get /subcategory:"Directory Service Changes" /r

Als Ausgabe ist ein Richtlinienbericht zu erwarten, der die Unterkategorie und ihre Erfolgs- und Fehlereinstellungen identifiziert. Speichern Sie die DC-Identität, den Erfassungszeitpunkt, den Befehl und den zurückgegebenen Bericht. Eine erfolgreiche Abfrage belegt, was zu diesem Zeitpunkt gelesen wurde. Sie beweist nicht, dass dieselbe Einstellung zum Zeitpunkt der historischen Änderung galt. Die Befehlssyntax und die erforderlichen Leseberechtigungen sind in Microsoft Learn: auditpol get dokumentiert.

Prüfen Sie für die Protokollkonfiguration das Security-Protokoll auf demselben DC:

Get-WinEvent -ListLog Security -ComputerName 'dc01.contoso.local' -ErrorAction Stop

Das Ergebnis beschreibt das Protokoll einschließlich Modus, konfigurierter Maximalgröße und Datensatzanzahl. Eine Größe oder Anzahl beweist nicht, dass das Zielintervall weiterhin durchsuchbar ist. Prüfen Sie für dieses Intervall die aufbewahrten lokalen Datensätze und zentralen Archive und dokumentieren Sie Quellenabdeckung, Weiterleitungslücken und verfügbare historische Richtlinien- und SACL-Belege. Microsoft Learn: Get-WinEvent.

Beantworten Sie die erste Entscheidungsfrage ausdrücklich: Welche SACL für Attributschreibzugriffe und welche Aufbewahrungsbelege stützen diese Rekonstruktion? Dokumentieren Sie das überwachte Objekt oder den geerbten Geltungsbereich, die relevante Schreibaktion, den erfassten Principal und die Erfolgseinstellung. Wenn nur die aktuelle Konfiguration verfügbar ist, kennzeichnen Sie die historische Abdeckung als unbelegt. Schließen Sie aus einem fehlenden historischen Ereignis nicht, dass das Attribut nie geändert wurde.

Schritt 2: Ereignisse ohne willkürliche Begrenzung auf ein Paar abrufen

Verwenden Sie ein begrenztes Intervall, das die geprüfte Änderung umfasst. Das folgende Beispiel wählt Security-Ereignisse nach Provider, ID und Zeit aus:

$reviewStart = [DateTimeOffset]::Parse('2026-10-04T08:00:00Z').UtcDateTime
$reviewEnd = [DateTimeOffset]::Parse('2026-10-04T09:00:00Z').UtcDateTime
$events = Get-WinEvent -ComputerName 'dc01.contoso.local' -FilterHashtable @{
    LogName = 'Security'
    ProviderName = 'Microsoft-Windows-Security-Auditing'
    Id = 5136
    StartTime = $reviewStart
    EndTime = $reviewEnd
} -ErrorAction Stop

Diese Zeiten dienen der Veranschaulichung; sie sind weder ein gemessenes Änderungsfenster noch eine vorgeschriebene Prüfdauer. Get-WinEvent dokumentiert diese Filterschlüssel und liefert Ereignisdatensätze standardmäßig mit den neuesten zuerst. Das Beispiel fordert bewusst nicht nur zwei Ereignisse an und begrenzt das Ergebnis nicht mit -MaxEvents. Bewahren Sie Abfrage und Ergebnis auf, bevor Sie Objekt und Attribut aus dem Ereignis-XML auswählen. Microsoft Learn: Filterparameter von Get-WinEvent.

Erwarten Sie null oder mehr passende Datensätze, keine vorgegebene Anzahl. Wenn der Befehl keine passenden Ereignisse meldet, unterscheiden Sie dieses Ergebnis von Zugriffs- oder Verbindungsfehlern und bewerten Sie anschließend Aufbewahrungs- und Erzeugungsabdeckung. Durchsuchen Sie bei Bedarf autorisierte Archive; das Cmdlet dokumentiert auch -Path für gespeicherte Ereignisdateien. Ein fehlgeschlagener Lesezugriff muss im Fallprotokoll sichtbar bleiben.

Bewahren Sie den ursprünglichen Ereignisexport und das XML jedes Ereignisses auf. Ein Screenshot des neuesten Werts reicht für die Rekonstruktion nicht aus. Prüfen Sie in einem SIEM, dass die Aufnahme die folgenden Felder erhält und die Identität des Quellereignisses getrennt vom Aufnahmezeitpunkt und von etwaigen doppelt weitergeleiteten Kopien bewahrt.

Schritt 3: Das Belegprotokoll zur Attributänderung zusammenstellen

Verwenden Sie ObjectGUID, um das Objekt zu identifizieren, und AttributeLDAPDisplayName, um das Attribut zu identifizieren. Dokumentieren Sie DN und Klasse als Kontext. Sammeln Sie anschließend alle möglichen Wertereignisse mit derselben Operationskorrelations-ID für dieses Objekt und Attribut und prüfen Sie den ausgebenden DC, das Subjekt und die Zeiten. Wenn diese Felder voneinander abweichen, bewahren Sie die Abweichung zur Untersuchung auf, statt die Datensätze in ein Paar zu zwingen.

Diese Ereignisfeldnamen stammen aus dem 5136-XML und den Feldbeschreibungen. Die Freigabefelder sind ein vorgeschlagenes Prüfprotokoll, keine zusätzliche Windows-Telemetrie.

Bei einer Ersetzung eines einwertigen Attributs mit vollständigen Belegen sollte der Prüfer die beobachtete Löschung und Hinzufügung beschreiben und jeden Quelldatensatz referenzieren können. Bei einem mehrwertigen Attribut bewahren Sie die einzelnen Entfernungen und Hinzufügungen als Mengen beobachteter Operationen auf. Erfinden Sie keine unveränderten Werte und behaupten Sie nicht, der Ereignissatz sei ein vollständiger Vorher-Nachher-Snapshot.

Für den Vergleich mit dem aktuellen Verzeichniszustand akzeptiert Get-ADObject eine Objekt-GUID als -Identity, zusätzliche Attribute als -Properties und einen bestimmten Server als -Server. Dieses Beispiel verwendet die GUID aus Microsofts Beispielereignis 5136; ersetzen Sie sie und das Beispielattribut durch die geprüften Identifikatoren.

Get-ADObject -Identity '4fe80a66-5f93-4f73-b215-68678058e613' -Server 'dc01.contoso.local' -Properties userAccountControl -ErrorAction Stop

Erwarten Sie das gefundene Objekt und die angeforderte Eigenschaft oder einen ausdrücklichen Lese- beziehungsweise Suchfehler. Bewahren Sie den Erfassungszeitpunkt und den DC auf. Der aktuelle Zustand kann die Behebung validieren helfen, aber weder einen fehlenden historischen Wert noch eine fehlende Freigabe wiederherstellen. Microsoft Learn: Get-ADObject.

Überprüfung: Die Freigabeentscheidung unabhängig treffen

Lassen Sie die benannte Änderungsinstanz den Antrag diesem Objekt, Attribut und der vorgesehenen Wertänderung zuordnen. Dokumentieren Sie, wer entscheiden darf, die Freigabebelege samt Zeitpunkt und ob diese Belege die beobachtete Operation abdecken. Die Erklärung eines Bedieners zu einer Änderung ist ein hilfreicher Beleg, aber nicht automatisch eine unabhängige Freigabe.

Halten Sie den technischen Akteur und den Entscheider in getrennten Feldern fest. Wenn ein Automatisierungskonto die Änderung angefordert hat, dokumentieren Sie dieses Subjekt, ohne den menschlichen Initiator zu erraten. Belegen Sie jede Zuordnung zu einem Bediener durch unabhängige Aufzeichnungen. Verknüpfen Sie ebenso einen geschäftlichen Antrag nicht allein deshalb mit einem Ereignis, weil die Zeitstempel nahe beieinanderliegen oder beide Beschreibungen „Verzeichniswartung“ erwähnen.

Klassifizieren Sie schwierige Fälle ausdrücklich:

Diese Tabelle schlägt Prüfergebnisse vor. Sie behauptet nicht, dass jedes nicht zugeordnete Ereignis bösartig ist. Beantworten Sie vor Abschluss die übrigen Entscheidungsfragen: Wer bestätigt die Autorisierung unabhängig vom technischen Akteur, und wie werden fehlende, mehrwertige oder ausschließlich Löschungen umfassende Belege eingeordnet? Weisen Sie jedem ungeklärten Punkt einen Verantwortlichen und die nächste Beleganforderung zu.

Behebung: Entscheidung klären und Abdeckung validieren (Remediation)

Bewahren Sie die historischen Belege auf, bevor Sie eine korrigierende Verzeichnisänderung vornehmen. Fügen Sie bei einer belegten freigegebenen Änderung die Entscheidung dem Prüfprotokoll bei. Lassen Sie bei einer Abweichung von der Freigabe oder einer bestätigten unautorisierten Änderung die zuständigen Identitäts- und Dienstverantwortlichen die Exposition und Abhängigkeiten bewerten, über Eindämmung oder Korrektur entscheiden und den autorisierten Zielzustand dokumentieren. Vermeiden Sie es, einen gelöschten Wert blind wiederherzustellen: Spätere legitime Änderungen oder Abhängigkeiten mehrwertiger Attribute können diese Handlung falsch machen.

Wenn die Erzeugungsabdeckung unzureichend ist, sollten autorisierte Administratoren die geltende Überwachungsrichtlinie und SACL für Attributschreibzugriffe korrigieren. Microsoft dokumentiert Erfolgsüberwachung für Directory Service Changes und keine Failure-Ereignisse in dieser Unterkategorie. Führen Sie den folgenden Befehl lokal auf dem ausgewählten DC aus. Er verwendet die dokumentierte Syntax auditpol /set zur Aktivierung der Erfolgsüberwachung, ändert die Konfiguration und gehört in ein freigegebenes Administrationsverfahren.

auditpol /set /subcategory:"Directory Service Changes" /success:enable

Auf ein erfolgreiches Befehlsergebnis folgen der oben beschriebene Lesezugriff mit auditpol /get und die separat geprüfte passende SACL. Der Befehl konfiguriert keine SACL, beweist nicht die Persistenz zentral verwalteter Richtlinien und erzeugt keine vergangenen Ereignisse neu. Stimmen Sie ihn mit dem Richtlinienverantwortlichen ab und bewahren Sie die resultierenden Konfigurationsbelege auf. Microsoft Learn: auditpol set, Audit Directory Service Changes.

Validieren Sie die künftige Abdeckung durch eine freigegebene Pilotänderung an einem Testobjekt außerhalb der Produktion und einem geeigneten Attribut. Dokumentieren Sie vor dem Test die autorisierte Absicht für alte und neue Werte. Prüfen Sie, dass die erzeugten und aufbewahrten Ereignisse das erwartete Objekt, Attribut und die Wertoperationen enthalten, dass die Weiterleitung ihre Identität bewahrt und dass die Prüfung sie mit der Testfreigabe verknüpfen kann. Für diesen Artikel wurde kein solcher Domänentest durchgeführt.

Wiederholen Sie nach einer autorisierten Korrektur das eingegrenzte Auslesen des Objekts und die Ereignisprüfung. Bewahren Sie den aktuellen Zustand, die Belege zur Korrekturoperation und die unabhängige Entscheidung auf. Schließen Sie nur die belegten Teile des Falls ab; führen Sie Lücken der historischen Rekonstruktion mit einem dokumentierten Ergebnis weiter.

Wie EtcSec dies erkennt

Am Collector-Commit bcd03c540bfccdeecf70f36bb80fd58bbe0bef1d ist CHANGE_MANAGEMENT_BYPASS eine Heuristik für den Sicherheitszustand mit Schweregrad Medium. Ihr Detect() liest erfasste LDAP-Benutzer. Es zählt aktivierte Benutzer, deren direkte memberOf-Einträge die englischen Namen Domain Admins oder Enterprise Admins enthalten, mittels Teilzeichenfolgenabgleich ohne Beachtung der Groß- und Kleinschreibung. Mehr als 10 solche Benutzer erzeugen ein Problem. Eine separate Zählung umfasst Benutzer mit mindestens einem SPN und adminCount=1; mehr als 5 erzeugen ein weiteres Problem. Die zweite Zählung schließt deaktivierte Benutzer nicht aus.

Wenn eine der beiden Bedingungen erfüllt ist, hat der zurückgegebene Befund Count=1; andernfalls hat er Count=0. Eins ist der Befundindikator, nicht die Anzahl nicht freigegebener Änderungen. Die Details enthalten die beiden aggregierten Zähler. Die Schwellenwerte sind Produktheuristiken ohne normative Autorität, keine Freigabeanforderungen von Microsoft, ANSSI oder HDS.

Der LDAP-Provider liefert memberOf, servicePrincipalName und adminCount. Dieser Detektor erweitert keine verschachtelten Gruppenmitgliedschaften. Umbenannte oder lokalisierte Namen privilegierter Gruppen können den Abgleich mit englischen Namen aushebeln; ein Teilzeichenfolgenabgleich ist keine stabile Prüfung der Gruppen-SID. Microsoft dokumentiert, dass adminCount auf 1 gesetzt bleiben kann, nachdem ein Konto eine geschützte Gruppe verlassen hat; dieses Flag belegt daher keine aktuell wirksamen Privilegien. Ein SPN kann auf einem Benutzer- oder Computerkonto registriert sein, sodass seine bloße Anwesenheit den aktuellen betrieblichen Zweck des Kontos nicht belegt. Microsoft Learn: Geschützte Konten und adminCount, SPN-Registrierung. Auch Erfassungsumfang und -grenzen beschränken die untersuchten Populationen.

Diese Prüfung liest keine 5136-Ereignisse, entfernten oder hinzugefügten Werte, Korrelations-IDs, SACLs, Aufbewahrungsnachweise oder Freigabeabläufe. Ein positiver Befund kann eine Prüfung des Änderungsmanagements anstoßen, aber weder eine Umgehung beweisen noch diese Attributänderung identifizieren oder über die Autorisierung entscheiden. Ein Zählerstand von null kann das Belegprotokoll nicht als geklärt abschließen. Schließen Sie die oben beschriebene Ereignisrekonstruktion und unabhängige Entscheidung ab, bevor Sie die Prüfung beenden.