Microsoft Defender for Identity Recommended Actions: GPO assigns unprivileged identities to local groups with elevated privileges

by thalpius

Identity leverages Secure Score with twenty-seven recommended actions. In a series of blog posts, I will go through all twenty-seven recommended actions and what they mean, a plan of approach, their impact, and my security recommendations, hopefully helping others. The nineteenth  one in the series is the “GPO assigns unprivileged identities to local groups with elevated privileges” recommended action.

Introduction

You have twenty-seven recommendations if you filter the Secure Score recommended actions for Microsoft Defender for Identity.

Some recommended actions are easy to configure, but others require time, proper planning, auditing, and expertise. This blog post will review the recommended action of “GPO assigns unprivileged identities to local groups with elevated privileges.”

Update: Microsoft keeps updating the recommended actions list. I will do my best to keep the list up-to-date.

Group Policy Objects

A Group Policy Object (GPO) is a collection of settings in a Windows environment used to manage and control the working environment of user accounts and computer accounts within Active Directory. GPOs allow system administrators to centrally enforce rules such as password policies, software installation, desktop restrictions, and security settings. GPOs are linked to containers in Active Directory, such as sites, domains, or organizational units (OUs), and are automatically applied when a user logs in or a computer starts up. This ensures consistency, improves security, and reduces the need for manual configuration across multiple systems.

Local Users and Groups

A Group Policy Object (GPO) that adds a group like Everyone to the local Administrators group instructs all targeted computers to include that group as a member of their local admin group. This means that every user, regardless of role or privilege level, gains full administrative access to those systems. As a result, users can install software, change security settings, manage accounts, and even execute malicious code with full control. This creates a serious security risk, as it effectively removes privilege separation and opens the door for malicious actors or unprivileged users to compromise the entire environment.

Image 1: Local Users and Groups policy

Risks

Adding the Everyone group or similarly broad groups like Authenticated Users or Domain Users, to the local Administrators group via a Group Policy Object (GPO) introduces a significant security vulnerability. It grants full administrative rights to all users on affected machines, regardless of their intended access level. This breaks the principle of least privilege, which is essential for maintaining a secure and controlled environment. Any user, intentionally or not, would be able to make critical system changes, install or remove software, disable security features, or access sensitive data.

From a threat perspective, this configuration dramatically increases the attack surface. If a malicious actor gains access to any standard user account, they automatically inherit administrative privileges on every system governed by that GPO. This makes privilege escalation trivial and enables lateral movement across the network. Furthermore, malicious insiders or compromised devices can use this access to disable defenses, implant persistent threats, and exfiltrate data with little resistance. Such a misconfiguration undermines the entire security model of a Windows domain.

Security Assessment

Microsoft Defender for Identity monitors for this type of misconfiguration, such as adding broad groups like Everyone, Authenticated Users, or Domain Users to the local Administrators group, and reports it as a security issue within Microsoft Secure Score. This detection helps organizations identify and remediate risky privilege assignments that could allow unauthorized users to gain elevated access across multiple systems. By flagging this issue, Microsoft Defender for Identity supports proactive security posture management and encourages adherence to the principle of least privilege.

Identify Sensitive Groups

This PowerShell script scans all Group Policy Objects (GPOs) in an Active Directory domain to identify whether any of them use Group Policy Preferences to add sensitive groups, such as Everyone, Domain Users, or Authenticated Users, to local groups on domain-joined computers, especially the Administrators group. It searches for these configurations by parsing the Groups.xml files stored in the SYSVOL directory, which define local user and group modifications. If it detects any risky group memberships being assigned, it outputs the GPO name, affected group, the action performed, and the specific member added. This helps administrators identify and remediate dangerous privilege assignments that could expose systems to unauthorized access or lateral movement.

Import-Module GroupPolicy

# Define risky groups to check
$RiskyAccounts = @("Everyone", "Domain Users", "Authenticated Users")
$KnownSIDs = @("S-1-1-0", "S-1-5-11") # Known SIDs for Everyone and Authenticated Users

# Get domain and SYSVOL path
$Domain = (Get-ADDomain).DNSRoot
$SysvolPath = "\\$Domain\SYSVOL\$Domain\Policies"

# Get all GPOs
$GPOs = Get-GPO -All

foreach ($gpo in $GPOs) {
    # Check both Machine and User configurations
    $xmlPaths = @(
        "$SysvolPath\{$($gpo.Id)}\Machine\Preferences\Groups\Groups.xml",
        "$SysvolPath\{$($gpo.Id)}\User\Preferences\Groups\Groups.xml"
    )

    foreach ($xmlPath in $xmlPaths) {
        if (Test-Path $xmlPath) {
            try {
                [xml]$xml = Get-Content $xmlPath -ErrorAction Stop

                foreach ($group in $xml.Groups.Group) {
                    $groupName = $group.Properties.groupName
                    $action = $group.Properties.action

                    foreach ($member in $group.Properties.Members.Member) {
                        $name = $member.name
                        $sid = $member.sid

                        if ($RiskyAccounts -contains $name -or ($sid -and ($KnownSIDs | Where-Object { $sid -like "$_*" }))) {
                            [PSCustomObject]@{
                                GPO           = $gpo.DisplayName
                                XMLPath       = $xmlPath
                                LocalGroup    = $groupName
                                Action        = $action
                                MemberAdded   = $name
                                SID           = $sid
                            }
                        }
                    }
                }
            } catch {
                Write-Warning "Error reading XML in GPO $($gpo.DisplayName): $_"
            }
        }
    }
}

Identify Overly Permissive GPO

This PowerShell script audits all Group Policy Objects (GPOs) in an Active Directory domain to identify cases where broad or non-restrictive groups, such as Everyone, Authenticated Users, or Domain Users, have permissions to edit or fully control a GPO. Using the Get-GPPermissions cmdlet, the script examines the access control list of each GPO and filters for entries that grant Edit or FullControl rights to those groups. If any such permissions are found, it outputs the GPO name, the group with access, the permission type, and whether the access is inherited. This is critical for security because overly permissive GPO rights can allow unauthorized users to change group policy settings, potentially leading to privilege escalation or domain compromise.

Import-Module GroupPolicy

# Define risky groups to check for
$RiskyGroups = @("Everyone", "Authenticated Users", "Domain Users")

# Get all GPOs
$GPOs = Get-GPO -All

foreach ($gpo in $GPOs) {
    # Get permissions for each GPO
    $permissions = Get-GPPermissions -Guid $gpo.Id -All | Where-Object {
        $_.Permission -match 'Edit|FullControl' -and
        $RiskyGroups -contains $_.Trustee.Name
    }

    foreach ($perm in $permissions) {
        [PSCustomObject]@{
            GPOName       = $gpo.DisplayName
            Trustee       = $perm.Trustee.Name
            TrusteeType   = $perm.Trustee.SidType
            Permission    = $perm.Permission
            Inherited     = $perm.Inherited
        }
    }
}

Conclusion

Group Policy Objects (GPOs) are a powerful tool for managing and securing Windows environments, but they must be configured carefully to avoid introducing critical security risks. Adding broad groups like Everyone, Domain Users, or Authenticated Users to the local Administrators group, or granting them permissions to modify GPOs themselves, undermines the principle of least privilege and exposes systems to privilege escalation and lateral movement.

By proactively auditing GPO configurations, both in terms of local group membership and GPO access control, administrators can detect and remediate these high-risk settings before they are exploited. Tools like Microsoft Defender for Identity and PowerShell scripts that inspect Groups.xml files and GPO permissions provide essential visibility into these misconfigurations. Strengthening GPO hygiene is a key step toward securing the Active Directory environment and maintaining operational integrity.