How to Review Privileged Group Membership in Active Directory

Verify who has powerful access, how they received it and whether they still need it.

Introduction

Privileged Active Directory groups provide the access needed to administer domains, manage critical systems and perform sensitive operational tasks. Their membership should be small, deliberate and regularly reviewed.

A useful review involves more than exporting a list of names. It must identify direct and nested members, establish how each account receives access, confirm that the access is still required and record who approved it. It should also highlight dormant, disabled, shared or poorly controlled identities that warrant investigation.

If you have not yet established which identities and control paths are privileged, begin with our guide to identifying privileged accounts in Active Directory. This guide focuses specifically on reviewing and certifying membership of known privileged groups.

What Should a Privileged Group Review Establish?

For every member of every group in scope, the review should answer five questions:

1. Who or what is the member? Identify whether it is a named administrator, service identity, computer, nested group or external security principal.
2. How is access granted? Distinguish direct membership from access inherited through one or more nested groups.
3. Why is access required? Link the membership to a current role, operational responsibility or documented technical dependency.
4. Who owns and approved it? Record accountable business and technical owners rather than relying on an informal understanding.
5. Should it remain? Confirm that the access is proportionate, appropriately controlled and still necessary.

The outcome should be an evidence-backed decision for each membership: retain, reduce, time-limit, replace or remove.

Define the Groups in Scope

Start with the highest-privilege built-in groups in every relevant domain and forest:

• Enterprise Admins
• Domain Admins
• Administrators
• Schema Admins

Then include other groups that can administer sensitive systems or create a route to wider control, such as:

• Account Operators, Backup Operators and Server Operators
• Group Policy Creator Owners
• DNSAdmins
• Key Admins and Enterprise Key Admins
• Groups with administrative access to domain controllers, identity servers, backup platforms or virtualisation infrastructure
• Product-created administrative groups
• Custom helpdesk, support, deployment and infrastructure groups
• Groups delegated control over privileged users, groups or organisational units

Do not decide scope from group names alone. A harmless-looking custom group may be nested into Domain Admins or hold permission to change the membership of another privileged group. The related article Domain Admin Isn’t the Only Privilege You Need to Monitor explains why effective privilege extends beyond the most familiar group names.

Review Privileged Group Membership with PowerShell

Prerequisites

The examples below use the Active Directory PowerShell module. Run them from an appropriately secured administrative workstation with an account permitted to read the required directory information.

Confirm that the module is available:

Get-Module -ListAvailable ActiveDirectory

Inspect the Group Itself

Before reviewing its members, confirm the identity, scope, category and description of the group:

Get-ADGroup -Identity "Domain Admins" -Properties Description, ManagedBy |
Select-Object Name, DistinguishedName, GroupScope, GroupCategory,
              Description, ManagedBy

A missing description or owner does not prove that a group is unmanaged, but it is a governance gap worth resolving. Record the purpose of each custom privileged group and nominate an owner responsible for certifying its membership.

List Direct Members

Begin with the objects directly added to the group:

Get-ADGroupMember -Identity "Domain Admins" |
Select-Object Name, SamAccountName, ObjectClass, DistinguishedName

Direct membership matters because it shows the immediate structure of the group. If the results contain another group, the identities inside it receive access indirectly and must also be reviewed.

Expand Nested Membership

The -Recursive parameter returns the leaf members found through the group hierarchy:

Get-ADGroupMember -Identity "Domain Admins" -Recursive |
Select-Object Name, SamAccountName, ObjectClass, DistinguishedName

Compare this output with the direct-member report. A user that appears only in the recursive output receives access through a nested group.

Recursive output identifies effective members, but it does not show the chain of groups through which each one inherits access. Retaining that path makes ownership validation and remediation considerably easier.

Report the Nested Membership Path

The following function walks the group hierarchy and records the route from the privileged group to each leaf member:

function Get-ADGroupMembershipPath {
    param(
        [Parameter(Mandatory)]
        [string]$GroupIdentity
    )

    $RootGroup = Get-ADGroup -Identity $GroupIdentity

    function Expand-ADGroup {
        param(
            [Microsoft.ActiveDirectory.Management.ADGroup]$CurrentGroup,
            [string[]]$Path,
            [string[]]$Ancestors
        )

        foreach ($Member in Get-ADGroupMember -Identity $CurrentGroup) {
            if ($Member.ObjectClass -eq "group") {
                if ($Ancestors -contains $Member.DistinguishedName) {
                    Write-Warning "Circular nesting detected at $($Member.Name)"
                    continue
                }

                $NestedGroup = Get-ADGroup -Identity $Member.DistinguishedName
                Expand-ADGroup -CurrentGroup $NestedGroup `
                    -Path ($Path + $Member.Name) `
                    -Ancestors ($Ancestors + $Member.DistinguishedName)
            }
            else {
                [PSCustomObject]@{
                    PrivilegedGroup = $RootGroup.Name
                    MemberName     = $Member.Name
                    SamAccountName = $Member.SamAccountName
                    ObjectClass    = $Member.ObjectClass
                    MembershipPath = (($Path + $Member.Name) -join " > ")
                }
            }
        }
    }

    Expand-ADGroup -CurrentGroup $RootGroup `
        -Path @($RootGroup.Name) `
        -Ancestors @($RootGroup.DistinguishedName)
}

Get-ADGroupMembershipPath -GroupIdentity "Domain Admins" |
Format-Table -AutoSize

Test recursive scripts carefully in large or heavily nested environments. Cross-forest membership, unresolved foreign security principals and directory connectivity can require additional handling.

Review Several Privileged Groups Consistently

Define the groups in scope explicitly rather than querying every group whose name contains words such as “admin”. This makes the review repeatable and prevents changes in naming from silently altering its scope.

$PrivilegedGroups = @(
    "Domain Admins",
    "Administrators",
    "Account Operators",
    "Backup Operators",
    "Server Operators",
    "Group Policy Creator Owners",
    "DNSAdmins"
)

$Results = foreach ($GroupName in $PrivilegedGroups) {
    try {
        $Group = Get-ADGroup -Identity $GroupName -ErrorAction Stop

        # Get recursive members safely
        $Members = Get-ADGroupMember -Identity $Group -Recursive -ErrorAction Stop

        foreach ($Member in $Members) {
            $Enabled = $null
            $LastLogonDate = $null
            $PasswordNeverExpires = $null

            if ($Member.ObjectClass -eq "user") {
                $User = Get-ADUser -Identity $Member.DistinguishedName `
                    -Properties Enabled, LastLogonDate, PasswordNeverExpires

                $Enabled              = $User.Enabled
                $LastLogonDate        = $User.LastLogonDate
                $PasswordNeverExpires = $User.PasswordNeverExpires
            }

            [PSCustomObject]@{
                PrivilegedGroup      = $Group.Name
                MemberName           = $Member.Name
                SamAccountName       = $Member.SamAccountName
                ObjectClass          = $Member.ObjectClass
                MemberSID            = $Member.SID.Value
                Enabled              = $Enabled
                LastLogonDate        = $LastLogonDate
                PasswordNeverExpires = $PasswordNeverExpires
            }
        }
    }
    catch {
        # Fixed variable expansion syntax using ${GroupName}
        Write-Warning "Could not query ${GroupName}: $($_.Exception.Message)"
    }
}

$Results |
    Sort-Object PrivilegedGroup, SamAccountName |
    Export-Csv -Path ".\Privileged-Group-Review.csv" -NoTypeInformation

Add the forest-root groups when appropriate and extend the list with your product-specific and custom administrative groups. In a multi-domain environment, run the review against the relevant domains and retain the domain or forest identity in the output.

The LastLogonDate value is useful for triage, but it is based on replicated logon information and should not be treated as a precise record of the account’s most recent activity. Confirm apparent inactivity using the evidence available across your domain controllers and dependent systems.

Investigate High-Risk Memberships

The report should drive investigation rather than become a simple tick-box inventory. Prioritise:

Nested Groups with Broad Membership

A single nested group can place many accounts into a privileged role. Confirm why nesting is required, who controls the nested group and whether its wider membership is appropriate for the privilege it inherits.

Disabled or Apparently Dormant Accounts

A disabled account should not normally require privileged membership. An apparently inactive account may be obsolete, but it could also support an infrequent process. Investigate before removal.

Shared Administrative Accounts

Shared identities weaken accountability because actions cannot be reliably attributed to an individual. Prefer named administrative identities and document any genuine technical exception.

Everyday User Accounts

Administrators should not ordinarily use a highly privileged identity for email, web browsing and routine productivity work. Where the same person needs administrative access, use a separate, controlled account appropriate to the role.

Service and Automation Accounts

Do not approve a service account merely because removing it might break something. Identify the application or process, technical owner, affected systems, credential controls and minimum permissions required. Consider whether a group managed service account or a more narrowly delegated identity could replace it.

Unexpected Object Types

Privileged groups may contain users, groups, computers or foreign security principals. An unfamiliar object or unresolved SID should be investigated rather than excluded from the report.

Accounts with Passwords That Never Expire

This setting may indicate a legacy service dependency or weak account governance. Confirm the reason, the controls protecting the credential and whether a more suitable identity design is available.

Add Ownership and Review Decisions

Technical data alone cannot determine whether access is justified. Enrich the exported results with:

• Business owner
• Technical owner
• Administrative purpose
• Source and path of membership
• Systems or directory scope affected
• Approval authority
• Approval and last-review dates
• Whether access is permanent or time limited
• Reviewer decision and rationale
• Remediation owner and target date

Ask the owner to validate the specific access, not simply the person’s employment status. “Still works in IT” is not evidence that Domain Admin or an equivalent privilege remains necessary.

Compare Membership Between Reviews

Point-in-time certification is stronger when the current membership is compared with the previous approved baseline. Export each snapshot using stable identifiers such as the member SID as well as display names.

$PreviousFile = ".\Privileged-Group-Review-Previous.csv"
$CurrentFile  = ".\Privileged-Group-Review.csv"

# Check if both required files exist
if (-not (Test-Path -Path $PreviousFile)) {
    Write-Warning "Baseline file missing: Could not find '$PreviousFile'. Run a baseline export first."
}
elseif (-not (Test-Path -Path $CurrentFile)) {
    Write-Warning "Current file missing: Could not find '$CurrentFile'. Please run the collection script."
}
else {
    $Previous = Import-Csv -Path $PreviousFile
    $Current  = Import-Csv -Path $CurrentFile

    Compare-Object -ReferenceObject $Previous -DifferenceObject $Current `
        -Property PrivilegedGroup, MemberSID -PassThru |
    Select-Object PrivilegedGroup, MemberName, SamAccountName, ObjectClass,
        @{Name="Change"; Expression={
            if ($_.SideIndicator -eq "=>") { "Added" } else { "Removed" }
        }}
}

A difference report helps reviewers focus on new, removed and changed access. It does not replace a full periodic certification: a longstanding membership can still become inappropriate when a person changes role or a service is retired.

Monitor Membership Changes Between Reviews

Periodic snapshots show what changed between two points, but they do not explain who made the change or exactly when it occurred. Enable and retain appropriate security group management auditing so relevant domain controllers record membership activity.

Important Windows security events include:

• 4728 and 4729 — member added to or removed from a security-enabled global group
• 4732 and 4733 — member added to or removed from a security-enabled domain local group
• 4756 and 4757 — member added to or removed from a security-enabled universal group

Events are only useful if the required auditing was enabled when the change occurred and the logs are retained or forwarded for long enough. Prioritise alerting for unexpected changes to the most sensitive groups rather than relying solely on the next scheduled review.

Remove or Reduce Access Safely

When a membership is no longer justified, use a controlled remediation process:

1. Confirm the account, membership path, owner and dependency.
2. Decide whether to remove direct membership, change a nested group or replace broad access with narrower delegation.
3. Assess the effect on every member when changing a nested group.
4. Record approval, the planned change and a rollback route.
5. Make the change through an accountable administrative identity.
6. Verify that the intended effective access has been removed.
7. Monitor the affected service or operational process.
8. Update the approved baseline and review evidence.

Where permanent access is unnecessary, consider time-limited membership, approval-based elevation or delegated permissions that cover only the required task and scope.

Common Review Mistakes

Reviewing Direct Members Only

This misses users and other principals receiving access through nested groups. Review both the effective members and the complete path through which access is inherited.

Approving a Nested Group as One Item

The reviewer must understand the identities inside the nested group and who can change them. Certifying only the group name conceals the real population receiving privilege.

Relying on Names Instead of Stable Identifiers

Display names and account names can change. Retain SIDs or other stable directory identifiers in snapshots so comparisons are less likely to misclassify a rename as an access change.

Assuming No Change Means No Risk

An unchanged membership may still be excessive after a role change, project closure or system retirement. Every retained membership needs current justification.

Removing Access Without Checking the Membership Path

Removing a direct membership will not help if the account also inherits access through another group. Equally, removing a nested group may affect many users and services at once.

Keeping Review Evidence in an Uncontrolled Spreadsheet

A spreadsheet can support an initial review, but it becomes difficult to maintain ownership, approvals, remediation and history as the environment grows.

Build a Repeatable Review Process

A sustainable privileged group review should follow a consistent cycle:

1. Maintain the authoritative list of privileged groups and their owners.
2. Collect direct, recursive and membership-path data.
3. Enrich identities with account status and governance information.
4. Compare the results with the last approved baseline.
5. Ask accountable owners to certify or reject each membership.
6. Remediate rejected, unexplained or excessive access.
7. Verify changes and preserve an audit trail.
8. Monitor high-risk membership changes between certifications.

The review frequency should reflect risk and change volume. The most powerful groups warrant continuous change monitoring and frequent owner review; lower-tier administrative groups may be certified monthly or quarterly. Re-run a review after significant organisational, infrastructure or security changes.

Operational Limitations of Manual Reviews

Native tools and PowerShell provide valuable visibility, but manual reviews become harder to sustain when organisations have many domains, nested groups and administrative roles.

Common challenges include:

• Maintaining an accurate list of privileged groups
• Preserving nested membership paths
• Combining account status, ownership and approval data
• Detecting changes between review cycles
• Routing certifications to the correct owners
• Following up rejected or overdue access
• Producing consistent evidence for auditors
• Coordinating changes without disrupting services

Automating Privileged Group Governance

Active Directory reporting, access governance and permissions management, and Active Directory management platforms can help organisations replace occasional exports with a controlled and repeatable process.

Depending on the platform, this may include:

• Scheduled reporting of direct and nested group membership
• Alerts when privileged memberships change
• Historical comparisons and audit trails
• Ownership and approval workflows
• Time-limited access with automatic expiry
• Delegation through controlled least-privilege roles
• Automated remediation after approval

Platforms such as Adaxes can support controlled administration, approval workflows, automation and reporting across Active Directory. The appropriate approach depends on whether the immediate need is visibility, formal access certification, change control or broader identity governance.

Final Thoughts

Reviewing privileged group membership is not simply a matter of confirming that a list of familiar names looks reasonable.

An effective review identifies direct and nested access, retains the path through which privilege is inherited, validates every membership with an accountable owner and records a clear decision. It also monitors sensitive group changes between certifications and removes or reduces unnecessary access through a controlled process.

By turning group membership into an owned, evidence-backed and recurring review, organisations can reduce privilege accumulation without undermining the access administrators and services genuinely need.