GPO security filtering

You've spent hours crafting the perfect Group Policy Object (GPO), linked it to the correct organizational unit (OU), but it's still not applying correctly. Or worse, it's applying to everyone. The culprit is almost always a misunderstanding of GPO security filtering. This guide will demystify it once and for all.

GPO security filtering is a way of managing which users, computers, or groups a GPO targets. In the Group Policy Management Console (GPMC), security filtering defines the scope of a GPO regardless of its location in the Active Directory structure. GPO security filtering is one of the most significant targeting tools in Group Policy, the other two being Windows Management Instrumentation (WMI) filtering and OU structure.

What is GPO security filtering?

When a GPO is associated with an OU, domain, or site, it does not automatically target all objects in the container. Group Policy security filtering enables administrators to filter or extend the application of a GPO by using Active Directory security principals such as users, computers, or groups.

The default setting for every new GPO is to assign Read and Apply Group Policy permissions to the Authenticated Users group. This means the GPO will target all authenticated users and computers within its linked scope. The removal of the Authenticated Users group and the addition of a specific security group is the essence of security filtering.

Security filtering responds to one question: Although this GPO is linked to this location, who should receive this GPO?

How GPO security filtering works

Security filtering is controlled by two NTFS-style permissions applied to the GPO object itself, which form part of the GPO's Discretionary Access Control List (DACL) . The Scope tab's Security Filtering section in the GPMC is simply a user-friendly view of these underlying DACL permissions:

• Read: The principal can read the contents of the GPO.
• Apply Group Policy: The GPO is processed and applied to that principal.

Both of these permissions must be present for a GPO to be applied. If a user has Read but not Apply Group Policy, the GPO will not be applied. If a user has neither of these permissions, the GPO will be completely invisible to that user.

This permission check is done as part of the group policy processing order. When a Group Policy refresh cycle occurs, the client-side components list all GPOs that are linked to the site, domain, and OUs that contain the object. For each GPO, the system checks whether the principal has the necessary permissions. Only GPOs that pass the permission check are downloaded and applied.

The impact of MS16-072

The MS16-072 security patch, released in June 2016, introduced an important change to how Group Policy processes permissions. Prior to this patch, GPOs were evaluated in the context of the user. After MS16-072, the security context shifted: GPOs are now also evaluated using the computer account's credentials during policy processing.

This has a critical practical implication: Authenticated Users must retain the Read permission on every GPO, even if Apply Group Policy is removed from them. If Authenticated Users loses Read entirely, computer accounts (which authenticate as Authenticated Users during policy processing) will be unable to read the GPO at all, silently breaking computer policy application across the board.

Group policy processing order

It is important to understand how security filtering for GPOs works in relation to group policy processing order to effectively predict the outcome.

The order in which group policy is executed is as follows:

1. Local Group Policy
2. GPOs that are site-linked
3. GPOs that are domain-linked
4. GPOs that are OU-linked (parent to child)
5. GPOs that are child OU-linked (closest to the object, but which is the last one executed by default)

This order is sometimes referred to as the LSDOU rule for layering order for GPOs. The letters represent Local, Site, Domain, and Organizational Unit. However, in this order, those executed last take precedence unless overridden by "enforcement", or "No Override" in legacy terms.

Security filtering is another layer on top of this order. A domain-linked GPO might be filtered to apply to a single group, but in terms of order, it is still executed at domain level.

Important interactions between security filtering and processing order are as follows:

• Enforced GPOs: An enforced GPO will not be blocked by Block Policy Inheritance, but security filtering is still in effect. If a user is filtered out of the security filter, they will not receive the enforced GPO.
• Block policy inheritance: Blocking inheritance prevents GPOs from parent containers from being processed, but it does not override security filtering on GPOs that are linked into the affected OU.
• Loopback processing: When loopback processing is enabled, security filtering is still in effect to determine which GPOs are processed. User policy is processed in Replace or Merge mode, but the same permission check is made.

How to configure GPO security filtering

The modern, correct way (post-MS16-072)

The legacy approach of simply removing Authenticated Users from the Security Filtering list on the Scope tab is no longer sufficient and can break computer policy application. The correct modern approach involves two separate steps.

Step 1: Strip Apply Group Policy from Authenticated Users (via the Delegation tab)

1. Open the GPMC by typing gpmc.msc in the run prompt.
2. Navigate to the GPO under Group Policy Objects or under the linked OU.
3. Click the Delegation tab, then click Advanced.
4. Select Authenticated Users in the group or user names list.
5. In the permissions list below, find Apply Group Policy and uncheck the Allow checkbox. Leave the Read Allow checkbox checked.
6. Click OK.

Step 2: Add your target security group

1. Select the Scope tab of the same GPO.
2. In the Security Filtering section, click Add.
3. Type the name of the security group, user, or computer that should receive the GPO.
4. Click OK.

This ensures that Authenticated Users (and therefore computer accounts) can still read the GPO during policy processing, while only your target group actually receives and applies it.

Advanced: Using "Deny" to explicitly block GPO application

In addition to filtering who receives a GPO, you can explicitly block specific principals from receiving a GPO using Deny permissions—even when they would otherwise qualify through an Allow permission.

Use case example: You want to apply a policy to all Sales laptops, except those used by executives in the "SalesExecs" group.

To configure this:

1. Open the GPO in GPMC, go to the Delegation tab, and click Advanced.
2. Click Add and select the group you want to block (for example, SalesExecs).
3. In the permissions list, check Deny next to Apply Group Policy.
4. Click OK.

GPO security filtering vs. WMI filtering

Both security filtering and WMI filtering control GPO scope, but they work differently and serve different purposes.

Use Security Filtering when you know who or what group should receive the policy. Use WMI Filtering when the targeting criteria is based on the computer's state or configuration, such as OS version, hardware model, or free disk space.

Auditing your environment: The ultimate PowerShell report

Visually checking the Security Filtering settings of hundreds of GPOs in the GPMC is impractical. PowerShell provides a reliable way to audit your entire environment and spot misconfigurations before they become problems.

The following script exports GPO name, link status, security filtering groups, and permission levels to a CSV file:

What to look for in the output:

• GPOs where Authenticated Users still has GpoApply: These are pre-MS16-072 configurations and might be applying to unintended users or computers.
• GPOs with no security filtering groups (Principal = "NONE"): These GPOs will not apply to anyone and are likely broken or orphaned.
• Orphaned groups: Principals that no longer exist in Active Directory. These indicate stale configurations that should be cleaned up.
• GPOs where only GpoRead exists but not GpoApply for any group: The GPO is readable but will never be applied. This is a common result of incomplete security filter configuration.

Troubleshooting: GPO security filtering not working

The problem of GPO security filtering not working is one of the most common issues that administrators face. This problem occurs due to permission issues, group membership timing issues, or conflicts with other settings.

Authenticated Users are removed, but no group is added

If Authenticated Users has been removed and no group has been added, the Group Policy will not be applied to anyone. Open the Scope tab and verify the Security Filtering section contains at least one valid principal with both Read and Apply Group Policy permissions.

User is in the group, but the group policy is not applied

If the user is in the group but the Group Policy is not applying, the user's token might not yet reflect the new group membership. This is especially likely if the user was added to the group while already logged in. Log out and back in, or reboot.

Command to diagnose:

What to look for: Under the Applied Group Policy Objects section, verify whether the GPO appears. If it does not, check the Denied GPOs section. It will typically state the reason as Access Denied (Security Filtering), which is definitive confirmation that a permission is missing.

For an HTML report:

Computer policy does not apply after Authenticated Users are removed

Computer accounts are also subject to the permission check. If Authenticated Users loses Read permission entirely (not just Apply Group Policy), computer accounts will be unable to read the GPO. Verify on the Delegation tab > Advanced that Authenticated Users retains at least Read (Allow).

Command to diagnose:

What to look for: Check whether the GPO appears in the Denied GPOs section for the computer. An Access Denied reason confirms the computer account lacks Read permission.

Enforced GPO does not apply despite correct group membership

Verify the Delegation tab of the GPO. If the target group does not appear on the Delegation tab at all, it might lack the Read permission needed even to discover the GPO. Use the Add button on the Delegation tab to explicitly grant Read and Apply Group Policy to the target group.

The GPO applies to incorrect users

Run the Group Policy Results Wizard in GPMC for the affected user and computer combination. Alternatively, use gpresult /r on the target machine to display applied and denied GPOs. The Denied GPOs section will show the reason for each filtered GPO, making it straightforward to identify mismatches between the security filter and the user's group memberships.

GPO security filtering best practices

• Use specific security groups for GPO targeting. Do not filter directly on user accounts. Security groups are much easier to manage and less likely to be accidentally misconfigured.
• Never remove Authenticated Users entirely without understanding MS16-072. After the patch, the correct approach is to remove Apply Group Policy from Authenticated Users (via Delegation > Advanced) while keeping Read, then add your target group.
• Add Domain Computers to the security filter when the GPO contains Computer Configuration settings. This is a very common reason for computer policy failures.
• Use the Delegation tab to audit permissions. The Delegation tab of the GPMC displays all explicit permissions on a GPO. This tab should be checked when troubleshooting unexpected policy application.
• Document your filtering logic. Keep track of why each GPO filters to a particular group. Without documentation, inherited configurations will become increasingly hard to manage.
• Test changes in a non-production OU. Set up a test OU, apply the GPO, and add a test user to the filtered group before applying security filtering changes to the production user base.
• Use gpupdate /force after changes in testing. In production, wait for the standard refresh interval (90 minutes with a 30-minute offset for non-domain controllers) or use the Invoke-GPUpdate cmdlet in PowerShell to selectively push updates.

AGPM vs. native GPMC for security filtering management

The native GPMC offers complete functionality for the configuration of security filtering through the Scope and Delegation tabs. There is no need for additional tools to configure or modify security filters.

However, in scenarios with multiple administrators responsible for GPO management, changes to security filtering configured using GPMC are enforced immediately without review or approval. This is remedied by Advanced Group Policy Management (AGPM), which introduces a change control component. Changes to security filtering configured using AGPM are version-controlled, requiring approval before implementation and reversible through rollback.

GPO management with ADManager Plus

While managing GPO security filter settings natively using the GPMC tool works for small-scale environments, it has some inherent disadvantages. All changes take effect immediately, and there is no requirement for approvals. There is no audit trail available for who made changes to a particular GPO or security filter. For managing multiple GPOs across many OUs, this process can lead to many compliance issues.

ADManager Plus is a tool for managing and reporting AD objects, which helps address the disadvantages of native GPMC tool usage for managing GPOs. It is a governed, delegated, and centralized tool for end-to-end management of GPOs within your AD environment. Administrators can add, edit, link, unlink, enforce, and delete GPOs using this tool.

This solution performs these actions without using the native tool, and without elevating user privileges. ADManager Plus helps administrators back up and restore GPOs, which ensures that if something goes wrong, it can be fixed immediately. All actions performed using ADManager Plus for GPOs have an audit trail to meet compliance requirements without requiring additional scripting or third-party tools for logging.

FAQs

Does security filtering override OU-based GPO inheritance?

No. Security filtering and OU inheritance operate at different layers. A GPO linked to a parent OU can still be blocked by Block Policy Inheritance at a child OU, regardless of security filtering. Conversely, even if a user is in the correct security group, applying Block Policy Inheritance at their OU can prevent the GPO from reaching them. Both conditions must be satisfied for a GPO to apply.

Can you apply a GPO to a single user without a security filtering?

Technically yes, but it is not recommended. You could link a GPO directly to the OU containing only that user, but this creates OU sprawl and makes the environment harder to manage. Security filtering on a broader OU is the cleaner, supported approach.

What is the difference between the Scope tab and the Delegation tab in the GPMC?

The Scope tab shows the high-level Security Filtering list, which includes the groups or principals the GPO is targeting. The Delegation tab shows the full Discretionary Access Control List (DACL) with all explicit permissions on the GPO. Advanced troubleshooting should always reference the Delegation tab, as the Scope tab provides a simplified view that does not expose all permission entries.

Is it safe to remove Domain Users from a GPO's security filter?

If Domain Users is explicitly listed in the security filter and you remove it, the GPO will no longer apply to all domain users. Whether this is safe depends entirely on what the GPO does and who should receive it. Always verify intent before removing broad groups like Domain Users or Authenticated Users.

Can security filtering be managed with PowerShell?

Yes. The Set-GPPermission cmdlet in the GroupPolicy PowerShell module allows you to add or remove security filtering permissions programmatically. For example:

This is useful for bulk changes across many GPOs or for scripting GPO provisioning in new environments.

Does security filtering affect the Group Policy Results output?

Yes. When a GPO is filtered out due to a missing permission, the Group Policy Results Wizard will show the GPO in the Denied GPOs section with a reason of "Inaccessible" or "Security" depending on which permission is missing. This is one of the fastest ways to confirm that security filtering is working as intended—or identify why it is not.