GPO Security Filtering MS16-072: Restore Read, Preserve Scope

What Is GPO Security Filtering MS16-072?

GPO security filtering MS16-072 troubleshooting starts with two separate questions: can the computer retrieve the user policy, and is the signed-in user allowed to apply it? A policy intended for a small user group can stop working when the computer loses Read permission. Restoring a broad Apply permission can make the policy work while also changing its intended audience.

Microsoft's MS16-072 support article documents the change introduced on June 14, 2016: Windows retrieves user GPOs using the computer's security context instead of the user's. Its resolution is Read permission for Authenticated Users, or Domain Computers when security filtering is used. The MS16-072 bulletin links the update to Microsoft Knowledge Base article 3163622; the installable update packages depend on the Windows version. This is an established processing change, not a newly discovered issue.

The practical goal is to restore retrieval while preserving the intended recipients. The same review should separate policies that belong in production from incomplete AD/SYSVOL pairs, disabled policies with active links, unused objects, and questionable delegation. Those states require different decisions; making every policy apply is not a useful remediation objective.

How It Works: Read, Apply, and the Link Scope

Microsoft's current troubleshooting guidance explains why removing Authenticated Users from Security Filtering can break user policies: that action removes both Read and Apply Group Policy. A targeted user group can retain its permissions while the computer account can no longer retrieve the GPO.

Read added through the GPMC Delegation tab is different from the entry labelled Read (from Security Filtering). The latter includes Apply; plain Read restores retrieval without granting that application right. Keep the intended user group in Security Filtering and provide Read to the appropriate computer population through Delegation.

Security filtering operates within the locations reached by the GPO's links. Microsoft's security-filtering reference explains that group membership alone does not bring an out-of-scope user into a linked site, domain, or OU. Adding broad Apply can expand recipients within the applicable link scope; it does not automatically apply the GPO to the entire domain. This historical page explains filtering mechanics and should be read alongside the current computer-Read guidance.

Microsoft's Group Policy processing documentation describes additional conditions: disabled sections, WMI filters, and loopback processing. Merge adds the computer-based user-policy list after the user's list; Replace uses the computer-based list instead. Record the actual mode before interpreting a result. For loopback Merge, the MS16-072 support article specifically instructs administrators to add the intended users and computers under Scope > Security Filtering. Validate that targeted configuration separately; the general computer-Read correction above is not a complete loopback recipe.

The Failure Chain and Policies That Need Review

A common failure sequence is simple: an administrator narrows a user GPO to a business group, removes Authenticated Users, and then finds that user settings are absent on the relevant computers. The target group still looks correct. The missing dependency is computer Read. Adding Authenticated Users back to Security Filtering can hide that dependency by restoring both Read and Apply.

Microsoft documents failed user-policy application as a symptom; its troubleshooting example includes an error in the results report. Do not assume this failure is always silent, or treat every missing setting as proof of an MS16-072 permission problem.

Other GPO states deserve a separate decision before anyone links or reactivates them:

• AD/SYSVOL inconsistency: check the directory object and corresponding files, replication, and recoverable backups. An orphan finding does not by itself justify restoring the policy to use or deleting it.
• Both sections disabled, but a link enabled: establish whether this is deliberate maintenance or an obsolete link. The finding does not mean disabled settings are currently applying.
• No inventoried link: identify a draft, reserve policy, or forgotten deployment. Lack of a link is an inventory signal, not evidence of compromise.
• Questionable delegation around policies and links: inspect the relevant trustees and objects. A permission finding is not proof that someone inserted a hostile link.

For the separate question of who can rewrite settings, GPO misconfigurations as an attack vector explains exposure through policy-editing rights and weak configuration. For a privileged OU, weak GPO ACLs on Tier 0 explains why blocking inheritance does not secure the linked GPO's own editing permissions. Read access, policy-editing access, and link-writing access each need their own evidence.

Detection: Measure Permissions and Actual Results

Start with one affected GPO, identified unambiguously. Example 3 in Microsoft's Get-GPPermission reference provides this command:

Get-GPPermission -Name "TestGPO" -All

Replace the example name with the real policy. The cmdlet reports principals that have permissions on that GPO; it is not a complete simulation of policy processing. If names are ambiguous, use the GPO's GUID. The following individual queries adapt documented parameters:

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

Use resolved names from your domain. Compare computer Read, the intended group's Apply permission, and any unexpected broad Apply. A missing result or error is not a successful permission check. Inspect custom permissions and explicit Deny entries rather than inferring effective access from a summarized level.

For the processing result, Microsoft's troubleshooting example uses:

gpresult /h gpresult.html

Run a positive and negative user test and inspect the generated reports. Preserve the computer, user, GPO identity, relevant links, and any error with each result. The diagnostic matrix below helps keep competing explanations visible:

These are documented commands and a proposed validation procedure. No AD test results or event-log captures are claimed here.

Remediation: Restore Read Without Broadening Apply

1. Record the intended audience and current state

Before changing permissions, preserve the policy state and establish its owner, target users, login computers, link scope, and processing mode. Determine which computer population needs Read. Authenticated Users, Domain Computers, or a suitable computer group are choices to evaluate against that population; verify explicit Deny separately.

2. Grant computer Read through Delegation

In GPMC, open the affected GPO's Delegation tab, select Add, choose the group or computer object, select Read, and confirm. Keep Apply on the intended user group. Microsoft's troubleshooting page documents this route and the resulting distinction between plain Read and Read from Security Filtering.

For a PowerShell preview, this example uses parameters from Microsoft's Set-GPPermission documentation:

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

-WhatIf previews the operation; it does not apply the change. Use the actual GPO and trustee, review the preview, and perform the approved single-policy change through the chosen procedure.

3. Correct an accidental broad Apply grant

If Authenticated Users should only read this targeted GPO, preview replacement of its current permission level:

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

The documentation states that a higher existing permission level remains unchanged unless -Replace is used. Therefore, merely requesting GpoRead may leave an existing Apply grant in place. Replacement is appropriate only after confirming that the principal should lose its higher permission on this GPO. Preserve the target group's Apply permission and the recorded rollback state.

4. Validate application and resolve inventory findings

Repeat permission measurements and both user tests. Check expected application, exclusion of non-target users, and the relevant processing conditions. For orphans, validate both storage components before restoration or retirement. For disabled-but-linked policies, confirm intent and remove obsolete links where appropriate; do not reactivate settings automatically. Review questionable grants with their owner, including link-writing rights independently of policy-container permissions.

How EtcSec Detects This

The following descriptions reflect seven reviewed Detect() implementations in etc-collector commit c38a5bb9d0d847a56980c8ba02c7b0169abbc69f. They describe configuration signals, not seven proven attacks or an executed test of this environment.

Filtering checks

GPO_AUTHENTICATED_USERS_APPLY selects GPOs with an enabled link and an Authenticated Users ACL entry carrying the Apply bit. The LDAP adapter associates that bit with the relevant extended right; Microsoft documents Apply Group Policy as the right used to determine application. The Detect() itself does not reject Deny entries or calculate effective access, evaluate WMI, or check disabled sections. An intentional broad baseline can legitimately produce a review signal.

GPO_NO_SECURITY_FILTERING looks for enabled linked GPOs with Apply for Everyone or Authenticated Users and no other specific Apply trustee, excluding Domain Computers from that specific-trustee test. A specific group does not cancel a broad Apply grant, so the detector can miss an expansion when both coexist. It also does not calculate effective access or section state. These two checks overlap and should be reviewed as one filtering concern, rather than counted as independent proof of exposure.

Neither predicate establishes that computer Read is missing. Use the permission measurements and processing tests above for the MS16-072 diagnosis.

Inventory checks

GPO_ORPHANED consumes supplied SYSVOL findings of type orphaned_ldap or orphaned_sysvol. If no matching orphan finding is returned, its LDAP fallback flags an empty file path or an object with both DisplayName and CN empty. That fallback can run even when other SYSVOL findings were supplied. A complete LDAP object whose SYSVOL folder disappeared can escape that fallback. Record whether SYSVOL evidence was supplied; this is not a detector for a gPLink referencing a missing GPO.

GPO_DISABLED_BUT_LINKED requires Flags = 3, meaning both sections are disabled, and an enabled link. It identifies an inventory state to explain, not currently applied disabled settings.

GPO_UNLINKED finds GPOs without any inventoried link, including disabled links in the linked set, and excludes the two default GPO GUIDs. It does not mean the same thing as a disabled link, disabled sections, or an AD/SYSVOL orphan. Review lifecycle and intent before linking or retiring the object.

Delegation checks

GPO_MODIFY_RIGHTS checks direct or resolved primary-group membership in Group Policy Creator Owners, identified by RID 520. It does not follow nested membership. Microsoft's security-identifier reference describes the group's ability to create GPOs and the creator's ownership of new objects. Membership alone proves neither editing rights on every existing GPO nor permission to link them. Review membership and the policies and delegations those members own.

GPO_LINK_POISONING selects grant ACEs whose object DN contains CN=Policies,CN=System and whose mask includes GenericAll, GenericWrite, or WriteDACL. The Detect() does not itself exclude administrators, inspect each GPO's ACL, establish write access to an OU's gPLink, or identify an existing hostile link. Its Count represents distinct objects; TotalInstances can include multiple ACEs. Validate the trustee and delegation, then separately inspect the relevant site, domain, or OU link permissions. Microsoft's scope documentation locates gPLink on those objects, and its delegation procedure manages Link GPOs permissions there.