Was ist eine Prüfung von AD-GPO-Metadaten?
Eine Prüfung von AD-GPO-Metadaten vergleicht ein erfasstes Inventar von Gruppenrichtlinienobjekten mit unabhängig abgerufenen Informationen für dieselbe Richtlinie, Domäne und denselben Domänencontroller. Das Ergebnis dokumentiert, was gelesen wurde, was übereinstimmt und was unbekannt bleibt. Eine GPO im Inventar belegt ein beobachtetes Objekt; sie belegt weder eine korrekte Filterung noch eine vollständige Delegierung, synchronisierte Versionen oder eine erfolgreiche Anwendung auf Clients.
Diese Unterscheidung ist wichtig, wenn ein Inventar einen leeren WMI-Filter oder eine kurze Berechtigungsliste zeigt. Ein Feld kann leer sein, weil der Erfassungspfad es nie angefordert hat. Wer diese Darstellung als bestätigte Abwesenheit behandelt, macht aus einer Erfassungsgrenze ein Konfigurationsurteil. Dasselbe Problem entsteht, wenn ein fehlgeschlagener Lesezugriff auf Verknüpfungen wie eine Richtlinie ohne Verknüpfungen aussieht.
Der folgende Ablauf nutzt das Inventar als Ausgangspunkt und eine Gruppenrichtlinienabfrage mit festgelegtem Geltungsbereich zur Gegenprüfung. Er schlägt eine betriebliche Prüfung vor und beschreibt kein ausgeführtes Audit einer Kundendomäne. Für die Erfassung der Vergleichsnachweise sind keine Richtlinienänderungen erforderlich.
So funktioniert es: Identität und Herkunft der Leseergebnisse zusammenhalten
Beginnen Sie mit einem Datensatz, dessen Schlüssel aus GPO-GUID und Domäne besteht. Bewahren Sie den Anzeigenamen zur besseren Lesbarkeit auf, verwenden Sie ihn jedoch nicht als Zuordnungsschlüssel. Ergänzen Sie den abgefragten DC, Erfassungszeitpunkt, Quelle und Erfolg oder Fehlschlag jedes Lesezugriffs. Wenn die ursprüngliche Erfassung diese Details nicht ausweist, kennzeichnen Sie sie als unbekannt, statt der früheren Beobachtung den Kontext einer späteren PowerShell-Sitzung zuzuweisen.
Microsofts Referenz zu Get-GPO dokumentiert den Abruf mit -Name, -Guid oder -All. Ein doppelter Anzeigename verursacht einen Fehler; verwenden Sie deshalb die GUID für den Abgleich. Die Beispielausgabe enthält GpoStatus, WmiFilter, UserVersion und ComputerVersion; jede Versionseigenschaft zeigt AD- und SysVol-Werte. -Domain erwartet einen FQDN; -Server wählt einen DC aus. Werden diese Parameter weggelassen, gelten eine sitzungsabhängige Domänenauswahl und der PDC-Emulator.
Microsofts Referenz zu Get-GPOReport dokumentiert XML- oder HTML-Berichte mit Verknüpfungen, WMI-Filterung, Sicherheitsfilterung, Delegierung und Richtlinieneinstellungen. Dies sind Eingaben für den Abgleich, kein Ergebnis der Verarbeitung auf einem Client. Bei beiden Cmdlets erfordert die Abfrage einer anderen Domäne eine Vertrauensstellung mit der Domäne des Sitzungsbenutzers (bei Start- oder Herunterfahrskripten mit der Domäne des Computers).
Verwenden Sie ein Arbeitsblatt, in dem beide Beobachtungen sichtbar bleiben:
| Nachweis | Beobachtung im Inventar | Unabhängige Beobachtung | Prüfentscheidung |
|---|---|---|---|
| Identität | GUID, Domäne, Anzeigename | Von der Abfrage zurückgegebene GUID und Domäne | Identität vor dem Feldvergleich abgleichen |
| Herkunft des Leseergebnisses | DC, Zeitpunkt, Leseergebnis, sofern verfügbar | Expliziter DC, Zeitpunkt, Befehlsergebnis | Fehlende Herkunftsangaben als unbekannt belassen |
| WMI-Filter | Wert oder Erfassungsgrenze | Abgerufene Zuordnung und Berichtseintrag | Nicht vorhanden von nicht erfasst unterscheiden |
| Verknüpfungen | Erfasste Ziele und Flags | Gemeldete Verknüpfungen und Geltungsbereich | Geltungsbereich und Lesefehler untersuchen |
| Delegierung | Zusammengefasste Berechtigte und Rechte | Berichtsdelegierung und weitere ACL-Nachweise | Keinen effektiven Zugriff ableiten |
| Versionen | Verfügbare Werte oder nicht erfasst | AD- und SYSVOL-Versionen für Benutzer/Computer | Unterschiede für die Untersuchung bewahren |
Ergänzen Sie bei jedem ungeklärten Vergleich einen Verweis auf die Nachweisdatei und einen Verantwortlichen. Ein Screenshot ohne GUID oder ein Export ohne zugehörigen DC bleibt ein unvollständiger Nachweis. Diesen Prüfdatensatz erstellen Sie selbst; der Inventardetektor liefert nicht alle diese Felder.
Die Fehlerkette: Unbekannte Metadaten erzeugen falsche Sicherheit
Betrachten Sie ein vorgeschlagenes Prüfszenario: Eine GPO erscheint im Inventar, ihr WMI-Feld ist leer und ihre Verknüpfungen und Delegierungen wirken unauffällig. Der Prüfer schließt daraus, dass die Richtlinie keine WMI-Einschränkung hat und ihre zusammengefassten Rechte ausreichen, um die Anwendung zu erklären. Ein unabhängiger Bericht zeigt anschließend eine WMI-Zuordnung, die das Inventar nie erfasst hat.
Das Problem liegt in der Interpretation der Nachweise. Wird der leere Inventarwert durch den Berichtswert ergänzt, verbessert das den Prüfdatensatz, belegt aber nicht, welche Clients den Filter erfüllen. Ebenso kann eine Delegierungsübersicht weder explizite Deny-Einträge auflösen noch nachweisen, wer die Richtlinie tatsächlich bearbeiten kann.
Eine andere Abweichung kann entstehen, wenn Bericht und Inventar von unterschiedlichen DCs oder zu unterschiedlichen Zeitpunkten abgerufen wurden. Bewahren Sie diese Kontexte, bevor Sie den Unterschied als Konfigurationsabweichung bezeichnen. Andernfalls kann ein anderer Geltungsbereich, ein fehlgeschlagener Lesezugriff oder eine sich ändernde Beobachtung für einen bestätigten Replikationsfehler gehalten werden.
Nutzen Sie für die separate Frage der Anwendung den Leitfaden zur Prüfung von GPO Read, Apply und dem tatsächlichen Empfängerkreis. Er unterscheidet Abrufberechtigungen von Anwendungsrechten und validiert Ergebnisse für Ziel- und Nichtzielobjekte. Dieses Metadatenarbeitsblatt liefert qualifizierte Eingaben für diese Untersuchung.
Für die Richtlinienbearbeitung prüfen Sie GPO-Bearbeitungsrechte und Verknüpfungen zu Tier-0-OUs. Dieser Artikel untersucht die eigene Berechtigungsgrenze der GPO. Ein Delegierungseintrag im Inventar ist ein Anlass, den Berechtigten und die relevanten Objekte zu untersuchen, kein Beweis für effektive Kontrolle über eine privilegierte Richtlinie.
Erkennung: GPO und Bericht im festgelegten Geltungsbereich abrufen
1. Vergleichsziel identifizieren
Wählen Sie die tatsächliche GUID, den Domänen-FQDN und den DC aus dem autorisierten Prüfbereich. Die folgenden Werte sind Beispiele, keine entdeckte Infrastruktur. Ersetzen Sie sie vor der Verwendung. Führen Sie die Befehle in einer administrativen Umgebung mit verfügbarem GroupPolicy-Modul aus; bewahren Sie Fehler zusammen mit erfolgreichen Ausgaben auf.
Diese Abfrage ergänzt den dokumentierten Get-GPO-Parametersatz für GUIDs um Domain und Server:
Get-GPO -Guid '31a09564-cd4a-4520-98fa-446a2af23b4b' -Domain 'sales.contoso.com' -Server 'DC1'
Erfassen Sie die zurückgegebene Identität, den Status, die WMI-Informationen und die Versionspaare für Benutzer/Computer. Übertragen Sie die tatsächlichen Werte in das Arbeitsblatt. Ersetzen Sie eine Messung nicht durch die Beispielausgabe aus Microsofts Dokumentation.
2. Bericht aus demselben Geltungsbereich abrufen
Dieser Befehl verwendet den dokumentierten Get-GPOReport-Parametersatz für GUIDs. Ohne Path wird der Bericht auf dem Bildschirm ausgegeben:
Get-GPOReport -Guid '31a09564-cd4a-4520-98fa-446a2af23b4b' -Domain 'sales.contoso.com' -Server 'DC1' -ReportType XML
Für einen umfassenderen Vergleich entspricht das folgende Beispiel dem dokumentierten Berichtsmuster für alle GPOs mit expliziten Parametern. Verwenden Sie ein vorhandenes, genehmigtes Ausgabeverzeichnis:
Get-GPOReport -All -Domain 'sales.contoso.com' -Server 'DC1' -ReportType XML -Path 'C:\GPOReports\GPOReportsAll.xml'
Prüfen Sie den Bericht der betreffenden Richtlinie bis einschließlich seiner abschließenden Konfigurationsblöcke. Bewahren Sie Bericht und Befehlskontext zusammen auf. Eine Berichtsdatei aus einem früheren Lauf belegt nicht, dass ein späterer fehlgeschlagener Befehl erfolgreich war.
3. Unterschiede klassifizieren
| Signal | Zu dokumentierende Einstufung | Als Nächstes benötigter Nachweis |
|---|---|---|
| Bericht zeigt WMI-Zuordnung; Inventarwert leer | Inventarfeld im geprüften Pfad nicht erfasst | Zuordnung und Berichtskontext bewahren |
| Verknüpfungen unterscheiden sich | Ungeklärter Vergleich | Zeitpunkte, DCs, Partitionen und Leseergebnisse abgleichen |
| Delegierungslisten unterscheiden sich | Kandidat für Berechtigungsprüfung | Zugrunde liegende ACLs, Deny und Kontext der Berechtigten prüfen |
| AD- und SYSVOL-Versionen unterscheiden sich | Kandidat für Konsistenzuntersuchung | Benutzer-/Computerpaare und Replikationsnachweise bewahren |
| Inventar liefert keine GPO-Befunde | Erfassungsergebnis ohne Gegenprüfung unbekannt | Geltungsbereich und erfolgreiche GPO-Aufzählung nachweisen |
| Beide Lesezugriffe erfolgreich und Felder stimmen überein | Abgeglichene Beobachtung für diesen Geltungsbereich und Zeitpunkt | Clientanwendung als separate Frage behandeln |
Übereinstimmung ist nützlich, erweitert die Beobachtung aber nicht auf jeden DC oder Client. Sind weitere DCs zur Prüfung freigegeben, wiederholen Sie dieselben expliziten Abfragen getrennt und bewahren Sie für jeden einen eigenen Datensatz auf. Ein Berechtigungsfehler bleibt ein Fehler; er darf nicht zu einer Nullzählung oder einem Wert „nicht vorhanden“ werden.
Abhilfe: Nachweise vor Richtlinienänderungen korrigieren (Remediation)
1. Unbelegte Schlussfolgerungen korrigieren
Ersetzen Sie jedes unbelegte Urteil „kein WMI-Filter“, „keine Verknüpfungen“ oder „effektiver Bearbeitungszugriff“ durch den passenden unbekannten oder ungeklärten Zustand. Fügen Sie die unabhängig abgerufenen Informationen hinzu, ohne die ursprüngliche Beobachtung zu überschreiben. So bleibt nachvollziehbar, weshalb sich die Prüfung geändert hat, und der Verantwortliche kann Erfassungslücken von Konfigurationsänderungen unterscheiden.
2. Konsistenzfehler untersuchen
Wenn Versionen oder Beobachtungen innerhalb des festgelegten Geltungsbereichs voneinander abweichen, eröffnen Sie mit den AD-Administratoren eine Replikationsuntersuchung. Liefern Sie die exakte GUID, DCs, Zeitstempel, Benutzer-/Computerversionspaare und Lesefehler. Fordern Sie vor jeder autorisierten Reparatur eine genehmigte Sicherung nach dem Wiederherstellungsverfahren der Organisation an. Ein Bericht ist ein Prüfnachweis; er ersetzt keine wiederherstellbare Sicherung.
Ändern Sie keine Versionsnummern, damit ein Vergleich besteht, löschen Sie keine GPO, um eine unerklärte Inventarzeile zu entfernen, und ändern Sie keine WMI-Zuordnung allein deshalb, um ein fehlendes Collector-Feld zu füllen. Das Arbeitsblatt muss die beobachtete Richtlinie beschreiben, statt die Richtlinie an einen unvollständigen Payload anzupassen.
3. Ergebnis verifizieren
Nachdem das zuständige Team eine genehmigte Korrektur abgeschlossen hat, wiederholen Sie Get-GPO und Get-GPOReport mit expliziten Parametern Domain und Server. Erfassen Sie neue Zeitstempel und vergleichen Sie mit dem bewahrten Ausgangsstand. Schließen Sie jede Abweichung mit Nachweis, Verantwortlichem und Erklärung; behalten Sie ungeklärte Erfassungsgrenzen bei.
Geht es darum, ob Einstellungen auf einen vorgesehenen Benutzer oder Computer angewendet werden, fordern Sie eine separate Validierung der Clientergebnisse an. Weder übereinstimmende Metadaten noch eine erfolgreiche Berichtserstellung belegen die resultierende Richtlinie auf diesem Client.
Wie EtcSec dies erkennt
Diese Beschreibung beschränkt sich auf INFO_DOMAIN_GPO_INVENTORY im etc-collector-Commit 9f698083354a1cb7f625df5cb490a515823c3257. Detect() erzeugt für jede erfasste GPO einen Info-Befund mit Count=1. Details zu betroffenen Entitäten werden nur angehängt, wenn IncludeDetails aktiviert ist. Wurden keine GPOs erfasst, gibt es nil zurück; das beweist keine leere Domäne.
Der untersuchte LDAP-Pfad GetGPOs fordert weder versionNumber noch gPCWQLFilter an. GPOEntity setzt WmiFilter explizit auf einen leeren Wert. Interpretieren Sie diesen Wert als nicht erfasste WMI-Metadaten, nicht als Nachweis dafür, dass kein Filter zugeordnet ist. Diese Inventarprüfung belegt weder AD-/SYSVOL-Versionskonsistenz noch die resultierende Richtlinie auf Clients.
Die Erfassung von Verknüpfungen versucht die Sites-Suche unter einem aus BaseDN konstruierten Configuration-DN und ignoriert den Fehler dieser Suche. Die Engine ignoriert außerdem Fehler von GetGPOs, GetGPOLinks und GetGPOAcls. Fehlende Objekte, Verknüpfungen oder Delegierungseinträge erfordern daher eine unabhängige Bestätigung erfolgreicher Lesezugriffe und des Geltungsbereichs.
Schließlich gruppiert gpoPermissions Rechte nach Berechtigtem, ohne Deny-Einträge zu trennen oder effektiven Zugriff zu berechnen. Die Ausgabe ist eine zu untersuchende Zusammenfassung, kein Autorisierungsurteil. Nutzen Sie das Arbeitsblatt für den festgelegten Geltungsbereich und den Berichtsvergleich, um diese Beobachtungen einzuordnen.
INFO_DOMAIN_GPO_INVENTORY ist eine Inventarkontrolle im untersuchten Collector. Sie fehlt im Schwachstellen-Tag-Katalog der Website, deshalb trägt dieser Artikel keine Schwachstellen-Tags. Er soll Prüfern helfen, unbekannte Zustände zu bewahren und GPO-Metadaten abzugleichen, bevor sie eine betriebliche Entscheidung treffen.
Entdecken Sie die Identity-Security-Seiten zu diesem Thema