GPO Security Filtering vs Delegation in Active Directory: critical differences for audits and hardening

Context

In Active Directory, GPO Security Filtering and Delegation are often confused. The result is that many environments look well organized, but in reality the policy reaches the right recipients while the administrative permissions remain too broad. This is a governance and operational security issue, not just a technical configuration issue.

This guide explains in a practical way the difference between:

• who should receive the policy, through Security Filtering;
• who can administer or modify it, through Delegation.

Why is this distinction important? Because a GPO can be well targeted and still remain fragile if the delegations are wrong. This becomes especially critical during audits, hardening exercises, and least-privilege reviews.

Table of contents

• 1. How GPO application works
• 2. Security Filtering: what it really controls
• 3. Delegation: who can administer the GPO
• 4. Why the two layers must be read separately
• 5. Common risk scenarios
  • Case 1: filtering is correct, but the GPO is still exposed
  • Case 2: administrative delegation is too broad
  • Case 3: use of overly generic groups
• 6. A practical example of the difference
• 7. Quick checklist for least-privilege design
  • Concrete abuse examples
  • Very basic quick check
• Conclusion

1. How GPO application works

Before discussing Security Filtering, it is helpful to understand at a high level how a GPO is actually applied in Active Directory.

A GPO is not “executed” everywhere by magic. It applies to a domain object, an OU, or a site only if it has been linked there. If a policy affects users, the link must be placed where the target user objects exist, for example in an OU containing the users or in a context where the targeting allows the policy to reach the right users. If the GPO affects computers, the link must be placed where the target computers exist.

This matters because a GPO linked to computers that should apply user settings does not automatically become a user policy, and vice versa. In other words, the starting point is not Security Filtering, but the location where the GPO is linked and the object type the policy is intended to affect.

There are exceptions. For example, loopback can change the normal behavior of a policy: instead of applying the computer configuration to the actual user, the GPO can invert the context so that user policy is evaluated as if it were applied to the computer. It is an advanced mechanism, but helpful in specific environments.

This introductory point helps clarify a simple idea: Security Filtering is not the first step in applying a GPO. First, the GPO must be linked in the right place and designed for the object type that should receive it.

2. Security Filtering: what it really controls

Security Filtering decides which objects a GPO is applied to. In practice, it defines the effective recipients of the policy.

Operationally, this means:

• who receives the policy;
• which computers or users it is applied to;
• whether the targeting is consistent with the business or infrastructure logic.

A simple example: a GPO linked to an OU with Security Filtering set to a specific group will be applied only to objects that belong to that group and satisfy the scope requirements. If the goal is to limit a policy to a subset of workstations, filtering is the right tool.

The important point is that Security Filtering does not grant administrative privileges. It does not say who can modify the GPO. It says who is expected to receive the GPO.

3. Delegation: who can administer the GPO

Delegation, on the other hand, concerns administrative permissions. It defines who can:

• edit the settings of the GPO;
• link it to a domain object or OU;
• remove it;
• change the security permissions of the GPO;
• manage its contents or distribution.

This is the key distinction: Security Filtering is an application mechanism; Delegation is a governance and administrative control mechanism.

A person can be included in Security Filtering without having any right to modify the GPO. Conversely, an administrator can have the right to manage the GPO without that policy being applied to any specific computers.

4. Why the two layers must be read separately

During hardening reviews, the confusion often comes from the fact that Security Filtering and Delegation appear in the same Group Policy Management context and both rely on security permission logic. On one side you see an ACL, on the other a target of application, and the risk is to read everything as if it were the same thing.

In reality, the two layers serve different purposes:

• filtering concerns the application of the policy to the right recipients;
• delegation concerns administrative control over who can manage the GPO.

This distinction matters because a GPO can be very well targeted and still be managed too broadly. Conversely, a GPO can have a narrow delegation but an overly generic target. In both cases, the risk management approach is different.

This distinction also matters for operational accountability. In mature environments, a poorly governed GPO can create drift, confusion, and hidden privilege paths that are hard to detect until an audit or incident exposes them.

5. Common risk scenarios

Case 1: filtering is correct, but the GPO is still exposed

Imagine a GPO that is applied only to a very small group of computers. At first glance, everything looks under control. The problem is that the policy can still be risky if anyone who has access to its distribution or content can modify it. In practice: the targeting is correct, but the control over the content of the policy is not.

This is the key difference. Security Filtering says which objects the policy should reach. It does not say who can modify it or interfere with its content. For that reason, even a well-targeted GPO can remain fragile if its administrative protection is weak.

Case 2: administrative delegation is too broad

Imagine a very common situation: a GPO management delegation is assigned to the entire IT department. On paper this seems reasonable because IT has technical skills. The problem is that this group often includes both productivity administrators, such as those managing Exchange, Teams, or other services, and Active Directory administrators. In this case, the delegation becomes too broad for the actual context of the GPO.

The least-privilege design should instead ensure that only the system administrators or the team specifically authorized for that domain have access to manage the policy. Least privilege means granting only the permissions strictly needed to perform a specific task, without giving broader access than required. The result is an increased risk of both human error and abuse of privileges.

Case 3: use of overly generic groups

Using groups such as Authenticated Users, Domain Computers, or shared support groups can make it hard to understand whether a policy is really intended for the people who should receive it. In some cases, however, generic groups are unavoidable: for example, if a GPO is applied at the domain root and the target is the entire set of users or computers in the domain, then the default targeting can be very broad by definition.

What is still a problem, however, is using these groups in Delegation. Delegation should never use Authenticated Users or Domain Computers, because these groups do not represent a real administrative perimeter. If a delegation is assigned to those kinds of groups, control over who can actually administer the GPO is lost.

6. A practical example of the difference

Imagine a GPO intended for a group of production workstations.

• Security Filtering is configured so the GPO is applied only to that group.
• The Delegation permission allows a support team to modify it.

In this case:

• the policy reaches only the intended computers;
• the support team can still alter its contents.

This is why GPO design must be evaluated on both planes: targeting and governance.

7. Quick checklist for least-privilege design

Before considering a GPO "safe", verify at least these points:

1. Security Filtering truly reflects the intended target of the policy.
2. Delegation is limited to those who must administer the GPO.
3. The groups used for filtering and delegation have clear names and a well-defined scope.
4. Permissions are not assigned too broadly to generic groups.
5. The ACLs related to the GPO content and its distribution are reviewed separately.
6. Every exception is documented and tied to an operational owner.

From a governance-as-security perspective, the real question is not only "does this policy reach where it should?", but also "who really has the power to modify it, alter it, or use it for unintended effects?" If delegations are wrong, a GPO that looks like a simple administration object can become an abuse vector. An attacker or malicious insider can exploit an overly broad delegation to cause effects far more serious than they initially appear.

To go deeper into ACLs and permissions that make a GPO truly fragile, see SYSVOL permissions audit in Active Directory: who can really modify your GPOs?. The topic is also closely related to hardening administrative accounts, for example in Protected Users in Active Directory: what it is, limits, adminCount, and rollout without lockout.

Concrete abuse examples

1. A security or password GPO modified by an overly broad group: an unauthorized operator or attacker who gains access to a support group can alter a GPO that sets security criteria, disable controls, remove restrictions, or introduce more permissive settings.
2. A desktop or application-access GPO modified maliciously: if a delegation has been granted to a broad group, a user with inappropriate access can change policies controlling application access, network restrictions, client behavior, or local security rules.
3. A distribution or logon GPO used as a persistence mechanism: an attacker who gains access to a poorly managed GPO can add logon scripts, modify user profiles, or introduce settings that apply automatically to targeted computers, creating persistence and making the malicious action harder to remove.

Very basic quick check

If you want a first-pass check without diving into too much complexity, you can use a simple PowerShell inspection to look for obvious signs of overly broad delegations or generic groups:

Import-Module GroupPolicy

Get-GPO -All | ForEach-Object {
    $gpo = $_
    $permissions = Get-GPPermission -Name $gpo.DisplayName -All

    [PSCustomObject]@{
        GPO = $gpo.DisplayName
        Delegations = ($permissions | ForEach-Object {
            "$($_.Trustee) [$($_.PermissionLevel)]"
        }) -join "; "
    }
} | Format-Table -AutoSize

In practice, look for at least these signs:

• delegations assigned to generic groups such as Authenticated Users or Domain Computers;
• delegations assigned to entire departments or very broad groups without a clear scope;
• GPOs that appear to be managed by more teams than necessary.

For a more structured review, tools like GPOZaurr can help highlight anomalies and out-of-standard delegations, but they do not replace a proper governance and least-privilege review.

Conclusion

Security Filtering and Delegation are not interchangeable. The first describes who should receive the policy; the second describes who can manage it. When designing, auditing, or correcting GPOs in production, it is essential to treat them as two distinct controls, each with its own risks and authorization model.

This distinction helps avoid false assumptions, reduce the chance of configuration errors, and enable a stronger and easier-to-verify GPO governance model.