Removed Authenticated Users From a GPO's Security Filter and Broke Policy Delivery

Symptom

A Group Policy Object (GPO) that previously applied correctly to a target OU stops applying to some or all computer accounts after an administrator edits its security filtering. gpresult /r on an affected machine lists the GPO under “The following GPOs were not applied because they were filtered out” with the reason “Denied (Security)”. Event Viewer’s Group Policy Operational log (Microsoft-Windows-GroupPolicy/Operational) records event ID 4098 or an access-denied condition during processing. No error is raised in the GPMC console itself; the GPO still shows as linked to the correct OU and enabled.

False Assumption

The administrator assumes that adding a specific security group to the GPO’s Security Filtering tab in GPMC is purely additive: that the new group is granted apply rights while the existing default “Authenticated Users” entry continues to allow standard read/apply behaviour for everything else. In fact, GPMC’s Security Filtering list is the complete allow-list for who may apply the GPO. Adding a group without deliberately removing Authenticated Users is fine, but the common trap is the reverse: an administrator removes Authenticated Users specifically to “scope” the GPO to a named group, believing the named group alone is now sufficient because it has been granted Read and Apply Group Policy permissions. What is missed is that Authenticated Users is a group that includes computer accounts as well as user accounts, and many delegation models only add user or group objects to the filter, not the computer objects or the group representing them, leaving computers without the applicable permissions needed to even evaluate the GPO.

Root Cause

Group Policy application requires the requesting computer account (during computer policy processing) or user account (during user policy processing) to hold both Read and Apply Group Policy permissions on the GPO, evaluated via the Discretionary Access Control List (DACL) on the GPO’s Active Directory object, not merely by inheriting the parent OU’s link. Security Filtering in GPMC is a convenience view over this same DACL: removing Authenticated Users deletes the ACE that historically granted every authenticated security principal, including computers, the Apply Group Policy right. If the replacement scoping group contains only user accounts, or was granted permissions without the Apply Group Policy extended right (only Read was set), computer-side policy processing during startup and background refresh fails permission evaluation silently. There is no policy conflict, no replication issue and no linkage error, so every layer of GPMC reporting appears normal while affected machines simply stop receiving the policy.

Impact

Configuration drift accumulates invisibly: security baselines, firewall rules, software restriction policies or logon scripts delivered by the affected GPO silently stop being enforced on some or all machines, with no alert generated by Group Policy infrastructure itself. Because the change looks correct in GPMC (link present, GPO enabled, security filter shows an intentional-looking group), the misconfiguration can persist through change reviews. The operational consequence ranges from moderate (a convenience setting stops applying) to severe if the affected GPO enforces security controls such as firewall profiles, password policy fallback, or restricted group membership, in which case affected hosts silently run without the intended control while appearing managed.

Diagnosis

Confirm the failure is a security-filtering permission gap rather than replication lag, WMI filtering or a link-disabled state before changing anything.

• On an affected computer, run gpresult /r /scope:computer and check the “Denied” list and reason code for the specific GPO.
• In GPMC, open the GPO’s Delegation tab, switch to “Advanced”, and confirm whether the computer’s account, its OU, or a group it belongs to holds both Read and Apply Group Policy permissions; a missing Apply Group Policy ACE is the specific defect.
• Cross-check the Security Filtering tab against the Delegation “Advanced” view; GPMC’s simplified Security Filtering list only reflects principals with both Read and Apply Group Policy set to Allow, so a principal present under Delegation but absent from Security Filtering has incomplete permissions.
• Review the Group Policy Operational event log on the target machine around the last background refresh interval for access-denied or filtering events correlated with the GPO’s GUID.

Correction

Restore Apply Group Policy permission to the correct principal set without reverting to an unscoped Authenticated Users grant if scoping was genuinely intended.

1. In GPMC, select the GPO, open the Delegation tab, click Add, and add the security group that should legitimately receive the policy (for computer-targeted policy, this must be a group containing the relevant computer objects, not only user objects).
2. Click Advanced on the Delegation tab, select the newly added group, and explicitly tick Allow for both Read and Apply Group Policy; adding a group via the basic Security Filtering tab performs this correctly, but groups added only via raw ACL edits or scripts frequently miss the Apply Group Policy bit.
3. If the original intent was simply to limit which computers receive the policy, keep the scoping group but verify computer objects, not just user objects, are direct or nested members, since Group Policy computer-side processing evaluates the computer’s own token, not the logged-on user’s.
4. Do not re-add Authenticated Users unless the intended scope is genuinely “all authenticated computers and users”; if broad application was the actual requirement, restoring Authenticated Users is the correct fix rather than maintaining a narrower group.

Validation

Confirm the GPO is evaluated as applied, not merely linked, on a representative sample of previously affected machines before treating the change as resolved.

• On a test machine that is a member of the corrected scoping group, run gpupdate /force then gpresult /r /scope:computer; the GPO must appear under “The following GPOs were applied”, not under the filtered/denied list.
• Run gpresult /h report.html /scope:computer to generate a full report and confirm the specific settings delivered by the GPO (for example a firewall rule or restricted group entry) are present under the applied policy’s settings summary.
• Check the Group Policy Operational event log for a successful processing event for the GPO’s GUID at the next background refresh, with no denial reason.
• Repeat the check on at least one machine that should remain excluded from the GPO, confirming it still correctly shows the GPO as filtered out, to prove the scoping boundary itself was not lost during the fix.

Rollback

If the corrected permissions cause unexpected policy delivery to out-of-scope machines, or settings conflict with another GPO, revert the Delegation tab change rather than deleting the GPO or its link.

1. Note the exact prior state before change: which principals held Read and Apply Group Policy, captured from the Delegation Advanced view, ideally exported with Get-GPPermlight or an equivalent read-only permissions export run before editing.
2. Stop condition: if any machine outside the intended scope reports the GPO as applied in gpresult /r within one background refresh cycle after the change, treat this as a rollback trigger rather than continuing to tune scope.
3. To roll back, return to the Delegation tab, select the group added during correction, and remove the Apply Group Policy Allow permission (or remove the principal entirely) to restore the exact pre-change ACE set recorded in step one.
4. Re-run gpresult /r /scope:computer on both a previously-affected and a previously-excluded test machine to confirm the permission state and applied/filtered outcome match the pre-change baseline before considering rollback complete.

Prevention

Treat Group Policy security filtering as an access-control change requiring the same review as firewall or RBAC edits, not as a cosmetic GPMC convenience setting. Require that any change removing Authenticated Users from a GPO’s filter be paired with an explicit verification step confirming the replacement group’s membership includes the correct object class (computer or user) for the policy’s target, and that Apply Group Policy, not only Read, is granted via the Delegation Advanced view. Maintain a pre-change export of GPO permissions for any security-relevant GPO so that scoping edits have a documented, restorable baseline, and schedule a follow-up gpresult check on a sample of in-scope and out-of-scope machines within one background refresh interval of any security filtering change.