GPO-Sicherheitsfilterung MS16-072: Read und Geltungsbereich

Was ist GPO-Sicherheitsfilterung MS16-072?

Die Fehlersuche zur GPO-Sicherheitsfilterung MS16-072 beginnt mit zwei getrennten Fragen: Kann der Computer die Benutzerrichtlinie abrufen, und darf der angemeldete Benutzer sie anwenden? Eine Richtlinie für eine kleine Benutzergruppe kann ausfallen, wenn der Computer die Berechtigung Read verliert. Das Wiederherstellen einer breit vergebenen Apply-Berechtigung kann die Richtlinie wieder funktionsfähig machen, zugleich aber ihren vorgesehenen Empfängerkreis verändern.

Microsofts Supportartikel zu MS16-072 dokumentiert die am 14. Juni 2016 eingeführte Änderung: Windows ruft Benutzer-GPOs im Sicherheitskontext des Computers statt des Benutzers ab. Als Lösung nennt Microsoft Read für Authenticated Users oder, bei Sicherheitsfilterung, für Domain Computers. Das Bulletin zu MS16-072 verknüpft das Update mit Microsoft Knowledge Base-Artikel 3163622; die installierbaren Updatepakete hängen von der Windows-Version ab. Es handelt sich um eine etablierte Änderung der Verarbeitung, nicht um ein neu entdecktes Problem.

Das praktische Ziel ist, den Abruf wiederherzustellen und dabei die vorgesehenen Empfänger beizubehalten. Dieselbe Prüfung sollte produktiv benötigte Richtlinien von unvollständigen AD/SYSVOL-Paaren, deaktivierten Richtlinien mit aktiven Verknüpfungen, ungenutzten Objekten und fragwürdigen Delegierungen unterscheiden. Diese Zustände erfordern unterschiedliche Entscheidungen; alle Richtlinien zur Anwendung zu bringen ist kein sinnvolles Behebungsziel.

Funktionsweise: Read, Apply und der Geltungsbereich der Verknüpfungen

Microsofts aktuelle Anleitung zur Problembehandlung erklärt, warum das Entfernen von Authenticated Users aus Security Filtering Benutzerrichtlinien beeinträchtigen kann: Dabei werden sowohl Read als auch Apply Group Policy entfernt. Eine gezielte Benutzergruppe kann ihre Berechtigungen behalten, während das Computerkonto die GPO nicht mehr abrufen kann.

Read, das über die Registerkarte Delegation der GPMC hinzugefügt wird, unterscheidet sich vom Eintrag Read (from Security Filtering). Letzterer umfasst Apply; einfaches Read stellt den Abruf wieder her, ohne dieses Anwendungsrecht zu vergeben. Belassen Sie die vorgesehene Benutzergruppe in Security Filtering und vergeben Sie Read über Delegation an die passende Computerpopulation.

Die Sicherheitsfilterung wirkt innerhalb der Bereiche, die über die Verknüpfungen der GPO erreicht werden. Microsofts Referenz zur Sicherheitsfilterung erklärt, dass allein die Gruppenmitgliedschaft einen Benutzer außerhalb des Geltungsbereichs nicht in einen verknüpften Standort, eine Domäne oder OU einbezieht. Breit vergebenes Apply kann den Empfängerkreis innerhalb des geltenden Verknüpfungsbereichs erweitern; es wendet die GPO nicht automatisch auf die gesamte Domäne an. Diese historische Seite erklärt die Filtermechanik und sollte zusammen mit der aktuellen Anleitung zu Read für Computer gelesen werden.

Microsofts Dokumentation zur Gruppenrichtlinienverarbeitung beschreibt weitere Bedingungen: deaktivierte Abschnitte, WMI-Filter und Loopbackverarbeitung. Merge ergänzt die computerbasierte Liste der Benutzerrichtlinien nach der Liste des Benutzers; Replace verwendet stattdessen die computerbasierte Liste. Dokumentieren Sie den tatsächlichen Modus, bevor Sie ein Ergebnis interpretieren. Für Loopback Merge fordert der MS16-072-Supportartikel Administratoren ausdrücklich dazu auf, die vorgesehenen Benutzer und Computer unter Scope > Security Filtering hinzuzufügen. Prüfen Sie diese gezielte Konfiguration separat; die allgemeine Korrektur von Read für Computer oben ist keine vollständige Loopback-Anleitung.

Die Fehlerkette und Richtlinien mit Prüfbedarf

Eine häufige Fehlerfolge ist einfach: Ein Administrator beschränkt eine Benutzer-GPO auf eine Fachgruppe, entfernt Authenticated Users und stellt anschließend fest, dass Benutzereinstellungen auf den betreffenden Computern fehlen. Die Zielgruppe sieht weiterhin korrekt aus. Die fehlende Abhängigkeit ist Read für Computer. Das erneute Hinzufügen von Authenticated Users zu Security Filtering kann diese Abhängigkeit verdecken, weil es sowohl Read als auch Apply wiederherstellt.

Microsoft dokumentiert die fehlgeschlagene Anwendung von Benutzerrichtlinien als Symptom; das Beispiel zur Problembehandlung enthält einen Fehler im Ergebnisbericht. Gehen Sie nicht davon aus, dass dieser Fehler immer unbemerkt bleibt, und werten Sie nicht jede fehlende Einstellung als Beweis für ein MS16-072-Berechtigungsproblem.

Andere GPO-Zustände erfordern eine gesonderte Entscheidung, bevor sie verknüpft oder reaktiviert werden:

• AD/SYSVOL-Inkonsistenz: Prüfen Sie das Verzeichnisobjekt und die zugehörigen Dateien, die Replikation und wiederherstellbare Sicherungen. Ein Befund zu einem verwaisten Objekt rechtfertigt allein weder die erneute Nutzung noch die Löschung der Richtlinie.
• Beide Abschnitte deaktiviert, aber eine Verknüpfung aktiviert: Klären Sie, ob es sich um bewusste Wartung oder eine veraltete Verknüpfung handelt. Der Befund bedeutet nicht, dass deaktivierte Einstellungen derzeit angewendet werden.
• Keine inventarisierte Verknüpfung: Identifizieren Sie einen Entwurf, eine Reserverichtlinie oder eine vergessene Bereitstellung. Eine fehlende Verknüpfung ist ein Inventarsignal, kein Beleg für eine Kompromittierung.
• Fragwürdige Delegierung im Umfeld von Richtlinien und Verknüpfungen: Prüfen Sie die relevanten Berechtigungsträger und Objekte. Ein Berechtigungsbefund beweist nicht, dass jemand eine bösartige Verknüpfung eingefügt hat.

Zur gesonderten Frage, wer Einstellungen umschreiben kann, erläutert GPO-Fehlkonfigurationen als Angriffsvektor die Risiken durch Richtlinienbearbeitungsrechte und schwache Konfiguration. Für eine privilegierte OU erklärt schwache GPO-ACLs auf Tier 0, warum das Blockieren der Vererbung die Bearbeitungsberechtigungen der verknüpften GPO selbst nicht absichert. Lesezugriff, Zugriff zur Richtlinienbearbeitung und Schreibzugriff auf Verknüpfungen benötigen jeweils eigene Belege.

Erkennung: Berechtigungen und tatsächliche Ergebnisse messen

Beginnen Sie mit einer betroffenen GPO, die eindeutig identifiziert ist. Beispiel 3 in Microsofts Get-GPPermission-Referenz liefert diesen Befehl:

Get-GPPermission -Name "TestGPO" -All

Ersetzen Sie den Beispielnamen durch die tatsächliche Richtlinie. Das Cmdlet meldet Prinzipale mit Berechtigungen auf dieser GPO; es ist keine vollständige Simulation der Richtlinienverarbeitung. Verwenden Sie bei mehrdeutigen Namen die GUID der GPO. Die folgenden Einzelabfragen verwenden dokumentierte Parameter:

Get-GPPermission -Name "TestGPO" -TargetName "Domain Computers" -TargetType Group

Get-GPPermission -Name "TestGPO" -TargetName "Authenticated Users" -TargetType Group

Get-GPPermission -Name "TestGPO" -TargetName "GPO-Users-Cible" -TargetType Group

Verwenden Sie aufgelöste Namen aus Ihrer Domäne. Vergleichen Sie Read für Computer, Apply für die vorgesehene Gruppe und unerwartetes breit vergebenes Apply. Ein fehlendes Ergebnis oder ein Fehler ist keine erfolgreiche Berechtigungsprüfung. Untersuchen Sie benutzerdefinierte Berechtigungen und explizite Deny-Einträge, statt aus einer zusammengefassten Berechtigungsstufe auf den effektiven Zugriff zu schließen.

Für das Verarbeitungsergebnis verwendet Microsofts Beispiel zur Problembehandlung:

gpresult /h gpresult.html

Führen Sie einen positiven und einen negativen Benutzertest durch und prüfen Sie die erzeugten Berichte. Bewahren Sie mit jedem Ergebnis den Computer, den Benutzer, die GPO-Identität, die relevanten Verknüpfungen und etwaige Fehler auf. Die folgende Diagnosematrix hilft, konkurrierende Erklärungen sichtbar zu halten:

Dies sind dokumentierte Befehle und ein vorgeschlagenes Validierungsverfahren. Hier werden keine AD-Testergebnisse oder erfassten Ereignisprotokolle behauptet.

Behebung: Read wiederherstellen, ohne Apply auszuweiten (Remediation)

1. Vorgesehenen Empfängerkreis und aktuellen Zustand dokumentieren

Sichern Sie vor Berechtigungsänderungen den Richtlinienzustand und ermitteln Sie den Verantwortlichen, die Zielbenutzer, die Anmeldecomputer, den Geltungsbereich der Verknüpfungen und den Verarbeitungsmodus. Bestimmen Sie, welche Computerpopulation Read benötigt. Authenticated Users, Domain Computers oder eine geeignete Computergruppe sind Optionen, die anhand dieser Population zu bewerten sind; prüfen Sie explizites Deny gesondert.

2. Read für Computer über Delegation vergeben

Öffnen Sie in der GPMC die Registerkarte Delegation der betroffenen GPO, wählen Sie Add, wählen Sie die Gruppe oder das Computerobjekt, wählen Sie Read und bestätigen Sie. Belassen Sie Apply bei der vorgesehenen Benutzergruppe. Microsofts Seite zur Problembehandlung dokumentiert diesen Weg und den daraus resultierenden Unterschied zwischen einfachem Read und Read aus Security Filtering.

Für eine PowerShell-Vorschau verwendet dieses Beispiel Parameter aus Microsofts Set-GPPermission-Dokumentation:

Set-GPPermission -Name "TestGPO" -TargetName "Domain Computers" -TargetType Group -PermissionLevel GpoRead -WhatIf

-WhatIf zeigt die Operation als Vorschau; es wendet die Änderung nicht an. Verwenden Sie die tatsächliche GPO und den Berechtigungsträger, prüfen Sie die Vorschau und führen Sie die genehmigte Änderung an einer einzelnen Richtlinie über das gewählte Verfahren aus.

3. Eine versehentlich breit vergebene Apply-Berechtigung korrigieren

Wenn Authenticated Users diese gezielte GPO nur lesen soll, zeigen Sie die Ersetzung der aktuellen Berechtigungsstufe als Vorschau an:

Set-GPPermission -Name "TestGPO" -TargetName "Authenticated Users" -TargetType Group -PermissionLevel GpoRead -Replace -WhatIf

Laut Dokumentation bleibt eine vorhandene höhere Berechtigungsstufe unverändert, sofern nicht -Replace verwendet wird. Daher kann allein das Anfordern von GpoRead eine bestehende Apply-Berechtigung bestehen lassen. Eine Ersetzung ist nur dann angemessen, wenn bestätigt wurde, dass der Prinzipal seine höhere Berechtigung auf dieser GPO verlieren soll. Bewahren Sie Apply für die Zielgruppe und den dokumentierten Zustand zur Rücknahme der Änderung.

4. Anwendung validieren und Inventarbefunde klären

Wiederholen Sie die Berechtigungsmessungen und beide Benutzertests. Prüfen Sie die erwartete Anwendung, den Ausschluss von Benutzern außerhalb der Zielgruppe und die relevanten Verarbeitungsbedingungen. Validieren Sie bei verwaisten Objekten beide Speicherkomponenten vor einer Wiederherstellung oder Ausmusterung. Bestätigen Sie bei deaktivierten, aber verknüpften Richtlinien die Absicht und entfernen Sie gegebenenfalls veraltete Verknüpfungen; reaktivieren Sie Einstellungen nicht automatisch. Prüfen Sie fragwürdige Berechtigungen mit ihrem Verantwortlichen, einschließlich der Schreibrechte auf Verknüpfungen unabhängig von den Berechtigungen am Richtliniencontainer.

Wie EtcSec dies erkennt

Die folgenden Beschreibungen spiegeln sieben geprüfte Detect()-Implementierungen im etc-collector-Commit c38a5bb9d0d847a56980c8ba02c7b0169abbc69f wider. Sie beschreiben Konfigurationssignale, nicht sieben nachgewiesene Angriffe oder einen ausgeführten Test dieser Umgebung.

Prüfungen der Filterung

GPO_AUTHENTICATED_USERS_APPLY wählt GPOs mit einer aktivierten Verknüpfung und einem Authenticated Users-ACL-Eintrag mit gesetztem Apply-Bit aus. Der LDAP-Adapter ordnet dieses Bit dem relevanten erweiterten Recht zu; Microsoft dokumentiert Apply Group Policy als das Recht, mit dem die Anwendung bestimmt wird. Detect() selbst schließt weder Deny-Einträge aus noch berechnet es effektiven Zugriff, wertet WMI aus oder prüft deaktivierte Abschnitte. Eine beabsichtigte breite Basisrichtlinie kann berechtigterweise ein Prüfsignal erzeugen.

GPO_NO_SECURITY_FILTERING sucht aktivierte, verknüpfte GPOs mit Apply für Everyone oder Authenticated Users und ohne weiteren spezifischen Apply-Berechtigungsträger; Domain Computers wird von diesem Test auf spezifische Berechtigungsträger ausgenommen. Eine spezifische Gruppe hebt eine breite Apply-Berechtigung nicht auf; der Detektor kann daher eine Ausweitung übersehen, wenn beide nebeneinander bestehen. Er berechnet außerdem weder effektiven Zugriff noch den Abschnittszustand. Diese beiden Prüfungen überschneiden sich und sollten als ein Filterungsproblem geprüft werden, statt als unabhängige Risikonachweise gezählt zu werden.

Keines der beiden Prädikate belegt, dass Read für Computer fehlt. Verwenden Sie zur MS16-072-Diagnose die oben beschriebenen Berechtigungsmessungen und Verarbeitungstests.

Inventarprüfungen

GPO_ORPHANED verarbeitet gelieferte SYSVOL-Befunde vom Typ orphaned_ldap oder orphaned_sysvol. Wird kein passender Befund zu einem verwaisten Objekt zurückgegeben, meldet der LDAP-Fallback einen leeren Dateipfad oder ein Objekt, dessen DisplayName und CN beide leer sind. Dieser Fallback kann auch laufen, wenn andere SYSVOL-Befunde geliefert wurden. Ein vollständiges LDAP-Objekt, dessen SYSVOL-Ordner verschwunden ist, kann diesem Fallback entgehen. Dokumentieren Sie, ob SYSVOL-Belege geliefert wurden; dies ist kein Detektor für ein gPLink, das auf eine fehlende GPO verweist.

GPO_DISABLED_BUT_LINKED erfordert Flags = 3, also zwei deaktivierte Abschnitte, und eine aktivierte Verknüpfung. Es identifiziert einen zu erklärenden Inventarzustand, nicht derzeit angewendete deaktivierte Einstellungen.

GPO_UNLINKED findet GPOs ohne inventarisierte Verknüpfung, berücksichtigt dabei auch deaktivierte Verknüpfungen in der Menge verknüpfter GPOs und schließt die GUIDs der beiden Standard-GPOs aus. Dies bedeutet nicht dasselbe wie eine deaktivierte Verknüpfung, deaktivierte Abschnitte oder ein verwaistes AD/SYSVOL-Paar. Prüfen Sie Lebenszyklus und Absicht, bevor Sie das Objekt verknüpfen oder ausmustern.

Delegierungsprüfungen

GPO_MODIFY_RIGHTS prüft die direkte oder aufgelöste Primärgruppenmitgliedschaft in Group Policy Creator Owners, identifiziert durch RID 520. Verschachtelte Mitgliedschaften werden nicht verfolgt. Microsofts Referenz zu Sicherheits-IDs beschreibt die Möglichkeit der Gruppe, GPOs zu erstellen, sowie die Eigentümerschaft des Erstellers an neuen Objekten. Allein die Mitgliedschaft belegt weder Bearbeitungsrechte auf jeder vorhandenen GPO noch die Berechtigung, sie zu verknüpfen. Prüfen Sie Mitgliedschaften sowie die Richtlinien und Delegierungen, die diesen Mitgliedern gehören.

GPO_LINK_POISONING wählt gewährende ACEs aus, deren Objekt-DN CN=Policies,CN=System enthält und deren Maske GenericAll, GenericWrite oder WriteDACL umfasst. Detect() selbst schließt keine Administratoren aus, prüft nicht die ACL jeder GPO, belegt keinen Schreibzugriff auf das gPLink einer OU und identifiziert keine vorhandene bösartige Verknüpfung. Sein Count steht für unterschiedliche Objekte; TotalInstances kann mehrere ACEs enthalten. Validieren Sie den Berechtigungsträger und die Delegierung und prüfen Sie anschließend separat die relevanten Verknüpfungsberechtigungen für Standort, Domäne oder OU. Microsofts Dokumentation zum Geltungsbereich verortet gPLink auf diesen Objekten; das Delegierungsverfahren verwaltet dort die Berechtigungen Link GPOs.