Metadaten zum AD Schema Sicherheitsdeskriptor: Änderungen bewerten

Was Metadaten zum AD Schema Sicherheitsdeskriptor aussagen

Metadaten zum AD Schema Sicherheitsdeskriptor helfen zu bestimmen, wann der Sicherheitsdeskriptor an der Wurzel des Schema-Namenskontexts zuletzt geändert wurde. Ein aktueller Zeitstempel ist ein Anlass, Belege zu sammeln und die Änderung zu prüfen. Er belegt weder, dass eine Berechtigung gefährlich geworden ist, noch, dass ein Administrator ohne Autorisierung gehandelt hat oder die Gesamtstruktur kompromittiert wurde.

Dieser Leitfaden untersucht nTSecurityDescriptor am exakt als schemaNamingContext zurückgegebenen Objekt. Er untersucht nicht defaultSecurityDescriptor an einzelnen Schemaklassen. Halten Sie diese Unterscheidung in der Untersuchungsakte fest: Eine Änderung am Deskriptor des Wurzelobjekts und eine Änderung am Standarddeskriptor einer Klasse sind unterschiedliche Prüfgegenstände.

Microsoft beschreibt msDS-ReplAttributeMetaData als vom System gepflegte Metadaten für replizierte Attribute. Behandeln Sie diese Informationen als Herkunftsnachweis der Replikation. Der ursprüngliche Verzeichnisserver ist nicht das Benutzer- oder Dienstkonto, das einen Schreibvorgang angefordert hat. Um das anfordernde Konto zu ermitteln, sind separate Belege erforderlich.

Das praktische Ergebnis ist ein Bewertungsprotokoll: welches Objekt abgefragt wurde, welcher Domänencontroller geantwortet hat, welche Metadaten zurückgegeben wurden, ob der Zeitstempel verwendbar ist und ob eine genehmigte Referenz die aktuellen Berechtigungen erklärt. Dies ist ein Untersuchungsablauf, der am 4. Oktober 2026 anhand der Microsoft-Dokumentation geprüft wurde; keiner der hier gezeigten Befehle wurde gegen ein Kundenverzeichnis ausgeführt.

Erkennung: das Objekt vor der Metadatenabfrage identifizieren

Schritt 1: den Schema-Namenskontext auf dem ausgewählten DC ermitteln

Verwenden Sie eine Windows-Administrationsarbeitsstation mit dem PowerShell-Modul ActiveDirectory und ein Konto, das zum Lesen der betreffenden Verzeichnisdaten berechtigt ist. Ersetzen Sie den Beispielserver durch einen bestimmten DC in Ihrer Gesamtstruktur. Verwenden Sie denselben Server für die Ermittlung und die erste Metadatenabfrage.

Das folgende Beispiel verwendet den dokumentierten Parameter -Server von Get-ADRootDSE. Die Ausgabe enthält schemaNamingContext, defaultNamingContext, den Hostnamen des Servers und die aktuelle Uhrzeit.

$dc = 'dc01.example.com'
$root = Get-ADRootDSE -Server $dc -ErrorAction Stop
$root | Format-List dnsHostName, defaultNamingContext, schemaNamingContext, currentTime
$schemaDN = [string]$root.schemaNamingContext
if ([string]::IsNullOrWhiteSpace($schemaDN)) {
    throw 'Schema naming context was not returned; stop qualification.'
}

Erfassen Sie den zurückgegebenen DN exakt. Vergleichen Sie ihn mit dem Objekt-DN, den Ihr Auditwerkzeug verwendet. Prüfen Sie im Kontext einer untergeordneten Domäne insbesondere, ob ein aus dem DN der aktuellen Domäne zusammengesetzter DN mit RootDSE übereinstimmt. Eine Abweichung ist eine Frage der Datenerhebung, die vor der Interpretation des Befunds geklärt werden muss; sie ist kein Beleg dafür, dass der Deskriptor geändert wurde.

Schritt 2: die Replikationsmetadaten des Attributs abrufen

Get-ADReplicationAttributeMetadata akzeptiert einen Distinguished Name über -Object, einen DC über -Server und Attributnamen über -Properties. Dieses Beispiel beschränkt die Anfrage auf nTSecurityDescriptor und zeigt die vollständig zurückgegebenen Metadaten an, statt Felder in einer kurzen Tabelle auszublenden.

$metadata = @(Get-ADReplicationAttributeMetadata -Object $schemaDN -Server $dc -Properties nTSecurityDescriptor -ErrorAction Stop)
if ($metadata.Count -eq 0) {
    throw 'No metadata was returned; record insufficient evidence.'
}
$metadata | Format-List *

Bewahren Sie die Ausgabe auf, einschließlich Attributname, Version, Zeitpunkt der letzten ursprünglichen Änderung und Identität des ursprünglichen Verzeichnisservers. Unterscheiden Sie den abgefragten DC vom Server, der als Ursprung der Änderung angegeben ist. Übernehmen Sie jede ungeklärte Identität so, wie sie zurückgegeben wurde; ersetzen Sie sie nicht durch einen angenommenen Administratornamen.

Schritt 3: den Zeitstempel und das Beobachtungsfenster bewerten

Erfassen Sie den Erhebungszeitpunkt und die Zeitzone zusammen mit dem unveränderten Zeitstempel. Bestätigen Sie, dass das Datum vorhanden ist und korrekt interpretiert wird, bevor Sie ein Zeitfenster anwenden. Verwenden Sie beim Nachvollziehen der Auditentscheidung die im Audit erfasste Referenzzeit, statt bei einer späteren Untersuchung stillschweigend die heutige Zeit einzusetzen.

Wenn Sie die Abfrage auf einem anderen DC wiederholen, wiederholen Sie dort auch die RootDSE-Ermittlung und speichern Sie ein separates Erhebungsprotokoll. Führen Sie zwei Beobachtungen nicht zu einer erfundenen Historie zusammen. Ein Zeitstempel der letzten Änderung kann weder jeden früheren Deskriptorzustand noch jede Änderung im Prüfzeitraum rekonstruieren.

Behebung: zuerst bewerten, bestätigte Abweichungen korrigieren (Remediation)

Schritt 1: den aktuellen Deskriptor mit einer genehmigten Referenz vergleichen

Beschaffen Sie den aktuellen Deskriptor für die exakte Schemawurzel und vergleichen Sie ihn mit einer datierten, genehmigten Referenz für dasselbe Objekt. Für eine Berechtigungsansicht auf dem ausgewählten DC verwendet das folgende Beispiel die von Microsoft dokumentierte Syntax für entfernte Objekte von Dsacls. Führen Sie den Befehl in einer Windows-Shell mit erhöhten Rechten, installiertem Dsacls und Lesezugriff auf das Zielobjekt aus. Ohne Änderungsoptionen zeigt er die ACL an.

dsacls "\\$dc\$schemaDN"

Bewahren Sie die Befehlsausgabe auf und melden Sie jeden Fehler. Eine ACL-Anzeige unterstützt die Berechtigungsprüfung; bewahren Sie über Ihre freigegebenen Verzeichniswerkzeuge einen vollständigen Deskriptorexport auf, wenn die Untersuchung auch Informationen zu Besitzer, Gruppe oder Überwachung benötigt. Kennzeichnen Sie genau, welche Komponenten erfasst wurden, damit eine Teilansicht nicht als vollständiger Deskriptorvergleich dargestellt wird.

Prüfen Sie geänderte Berechtigungsempfänger, Rechte, objektspezifische GUIDs, Vererbung und Geltungsbereich. Klären Sie, ob jede Abweichung zur Wurzel selbst oder zu einem anderen Objekt gehört. Die bestehende Prüfung der Schemaberechtigungen bietet ergänzenden Berechtigungskontext; diese Zeitprüfung weist keine Änderung am defaultSecurityDescriptor einer Klasse nach.

Falls keine genehmigte Referenz existiert, erfassen Sie diese Einschränkung. Der aktuelle Deskriptor kann weiterhin anhand der vorgesehenen Delegierung der Organisation geprüft werden, aber ein exakter historischer Vergleich bleibt nicht verfügbar. Konstruieren Sie aus dem Zeitstempel keinen früheren Zustand und behandeln Sie einen allgemeinen Standardwert nicht als genehmigte Referenz Ihrer Gesamtstruktur.

Schritt 2: Autorisierung und verfügbare Ereignisse korrelieren

Gleichen Sie die Belege mit einem tatsächlichen Änderungsticket ab: Ziel-DN, erwartete Berechtigungen, verantwortliches Team, genehmigtes Ausführungsfenster und resultierender Zustand. Ein Ticket, das eine schemabezogene Bereitstellung erwähnt, genügt allein nicht; prüfen Sie, ob die beabsichtigte Änderung das beobachtete Objekt und die Deskriptorabweichung erklärt.

Microsoft dokumentiert Sicherheitsereignis 5136 für Änderungen an Verzeichnisobjekten unter Audit Directory Service Changes. Seine Erzeugung erfordert einen passenden Überwachungseintrag für Attributschreibzugriffe in der SACL des Objekts. Wenn Ereignisse vorliegen, prüfen Sie ObjectDN und AttributeLDAPDisplayName, bewahren Sie die Kontofelder von Subject auf und korrelieren Sie zusammengehörige Vorgänge über OpCorrelationID. Microsoft beschreibt typische Datensätze für Value Deleted und Value Added; prüfen Sie jedoch die tatsächlich in Ihren Belegen verfügbaren Werte.

Verwenden Sie den AD-Monitoring-Leitfaden zur Ereigniserfassung und Korrelation, um die umgebende Überwachungskette zu prüfen. Klären Sie, ob Überwachung, Weiterleitung und Aufbewahrung den betreffenden DC und Zeitraum abdeckten, bevor Sie eine leere Suche interpretieren. Ein Subject-Konto bezeichnet im Ereignis einen anfordernden Sicherheitsprinzipal; jede Zuordnung zu einer bestimmten Person benötigt weiterhin unterstützende Betriebsunterlagen.

Schritt 3: eine belegbare Einstufung wählen

Ein unerklärter Zeitstempel allein gehört in den dritten Zweig. Eine bestätigte Berechtigungsabweichung kann eine Behebung rechtfertigen, ohne festzustellen, wer sie verursacht hat. Halten Sie die Frage der Autorisierung und die Bewertung der aktuellen Gefährdung ausdrücklich fest, damit die Reaktion nicht von einer unbelegten Zuordnung abhängt.

Schritt 4: nur die bestätigte Deskriptorabweichung korrigieren

Lassen Sie das autorisierte Verzeichnisteam eine Änderung am verifizierten DN der Schemawurzel vorbereiten. Sichern Sie den aktuellen Deskriptor, identifizieren Sie den exakten zu korrigierenden ACE oder Deskriptorbestandteil, dokumentieren Sie das beabsichtigte Ergebnis und planen Sie vor dem Schreiben einen Wiederherstellungsweg. Wenden Sie die geprüfte Änderung mit Ihrem freigegebenen ACL-Editor an und erhalten Sie dabei legitime Delegierungen und erforderliche Berechtigungen.

Vermeiden Sie einen pauschalen Reset, um einen aktuellen Zeitstempel wegzuerklären. Microsofts Dsacls-Referenz beschreibt /S als Wiederherstellung der Klassenstandardwerte und /R als Entfernung aller ACEs für einen bestimmten Sicherheitsprinzipal; keines ersetzt eine gezielte Korrektur, die durch Ihren genehmigten Vergleich gestützt wird.

Wiederholen Sie nach der Korrektur die RootDSE-, Metadaten- und Berechtigungsabfragen. Verifizieren Sie, dass der beabsichtigte Deskriptorzustand vorliegt und erforderliche Verzeichnisoperationen weiterhin funktionieren. Erfassen Sie die neuen Metadaten und alle erhobenen Auditbelege als neue autorisierte Änderung. Ein Befund zu einer aktuellen Änderung kann nach einer legitimen Korrektur positiv bleiben, weil die Korrektur selbst aktuell ist; validieren Sie die Berechtigungen und nicht nur das Verschwinden des Zeitsignals.

Wie EtcSec dies erkennt

In der geprüften Implementierung von etc-collector erzeugt SCHEMA_SD_RECENT_CHANGE einen Befund der Stufe Info mit Count 1, wenn SchemaSDLastChanged ungleich null ist und strikt nach data.Now.AddDate(0, 0, -90) liegt. Die Grenze verwendet die Subtraktion von Kalendertagen. Der exakte Grenzzeitpunkt ist ausgeschlossen, und es gibt keine obere Grenze bei Now: Auch ein zukünftiges Datum erfüllt den Test. Andernfalls hat der zurückgegebene Befund Count 0.

Die Engine setzt CN=Schema,CN=Configuration, gefolgt von DomainInfo.DomainDN zusammen, fordert Replikationsmetadaten an und kopiert den Änderungszeitpunkt für nTSecurityDescriptor. Vergleichen Sie diesen zusammengesetzten DN mit dem tatsächlichen RootDSE-schemaNamingContext, insbesondere wenn der Auditkontext eine untergeordnete Domäne ist. Diese Quellcodeprüfung begründet eine Validierungsanforderung und keinen gemessenen Fehler in Ihrer Gesamtstruktur.

Der LDAP-Provider durchsucht den Teilbaum mit auf einen Eintrag begrenzten Ergebnissen und liest msDS-ReplAttributeMetaData. Fehlende Antworten, Anfragefehler, fehlende XML-Tags oder nicht ausgewertete Zeitstempel können dazu führen, dass das Datum null bleibt. Der Zeitstempelparser unterstützt YYYY-MM-DDTHH:MM:SSZ und YYYY-MM-DDTHH:MM:SS. Dieser Pfad hat keinen separaten probed-Zustand, der den Erfolg der Erhebung belegt.

Der Detektor vergleicht keinen alten mit einem neuen Deskriptor, berechnet keinen DACL-Diff, identifiziert kein anforderndes Konto und weist keinen Missbrauch nach. Verwenden Sie sein Info-Ergebnis, um die Bewertung zu beginnen. Count 1 stützt das implementierte Zeitkriterium; Count 0 kann weder ein unverändertes Schema noch eine erfolgreiche Erhebung bescheinigen.