How to Identify Privileged Accounts in Active Directory

Introduction

Identifying privileged accounts in Active Directory sounds straightforward: list the members of Domain Admins and review the results. In practice, that only reveals part of the picture.

Administrative power can be granted through several routes. An account may inherit privilege through a nested group, hold delegated permissions over an organisational unit, control Group Policy, administer domain controllers or use a service identity with powerful rights. Some accounts may not look privileged at all until their effective access is examined.

A reliable review therefore needs to consider both explicit privilege, such as membership of a built-in administrative group, and effective privilege, which reflects what an identity can actually control.

What Is a Privileged Account?

A privileged account is any user, service account, computer account or other security principal with authority beyond that of a standard user.

This may include the ability to:

• Change directory configuration
• Create, modify or delete users and groups
• Reset passwords or alter group membership
• Manage domain controllers or servers
• Create or edit Group Policy Objects
• Read protected information or credentials
• Change permissions or take ownership of objects
• Run services, scripts or scheduled tasks with elevated rights

Privilege is not limited to named administrator accounts. A standard-looking user that can reset a Domain Admin password, modify a privileged group or edit a Group Policy Object linked to domain controllers may represent an equally serious risk.

Why Privileged Account Discovery Matters

Privileged identities are among the most valuable targets in an Active Directory environment. If compromised, they may allow an attacker to disable controls, access sensitive systems, establish persistence or take control of an entire domain or forest.

Privilege Accumulates Over Time

Administrators change roles, temporary access becomes permanent and project-specific permissions are forgotten. Without regular review, the number of privileged identities tends to grow.

Nested Membership Hides Access

A privileged group may contain another group rather than individual users. Reviewing only its direct members can conceal every account inside that nested group.

Delegation Is Easy to Overlook

Helpdesk and operational teams often receive narrowly scoped permissions through delegation. Poorly designed or undocumented delegation can provide more authority than intended.

Service Accounts May Hold Powerful Rights

Legacy applications, scheduled tasks and integration services frequently run under accounts with broad permissions, static passwords and unclear ownership.

Audit Evidence Requires More Than Assumptions

Security reviews and auditors may expect an organisation to show who has privileged access, why it is required, who approved it and when it was last reviewed.

Start with the Highest-Privilege Groups

Microsoft identifies the following as the highest-privilege built-in Active Directory groups:

• Enterprise Admins
• Domain Admins
• Administrators
• Schema Admins

Enterprise Admins and Schema Admins exist in the forest root domain, while Domain Admins and the built-in Administrators group must be considered in each domain.

Other groups can also confer significant administrative capability, including:

• Account Operators
• Backup Operators
• Server Operators
• Print Operators
• Group Policy Creator Owners
• DNSAdmins
• Key Admins
• Enterprise Key Admins
• Administrators created by products such as Microsoft Exchange or third-party applications

The significance of each group depends on the environment, its configuration and the systems it can influence. A useful inventory should include built-in groups, product-created groups and custom administrative groups.

How to Identify Privileged Accounts with PowerShell

Prerequisites

The following examples use the Active Directory PowerShell module. This is normally available on domain controllers and on administrative workstations with Remote Server Administration Tools installed.

Confirm that the module is available:

Get-Module -ListAvailable ActiveDirectory

List Direct Members of Domain Admins

This provides a quick view of the objects directly contained in Domain Admins:

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

This is a useful first check, but it does not expand nested groups.

Include Nested Group Membership

Use the recursive option to reveal accounts that receive access through nested groups:

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

Compare the direct and recursive results. Any difference indicates that nesting contributes to effective membership and should be documented.

Review Several Privileged Groups

The following example reports recursive membership across a defined set of administrative groups in the current domain:

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

foreach ($Group in $PrivilegedGroups) {
    try {
        Get-ADGroupMember -Identity $Group -Recursive -ErrorAction Stop |
        Select-Object @{Name="PrivilegedGroup";Expression={$Group}},
                      Name, SamAccountName, ObjectClass
    }
    catch {
        Write-Warning "Could not query ${Group}: $($_.Exception.Message)"
    }
}

Treat the group list as a starting point. Add product-specific and custom administrative groups used within your organisation.

Export the Results for Review

Results can be collected and exported to support owner validation and access reviews:

$Results = foreach ($Group in $PrivilegedGroups) {
    try {
        Get-ADGroupMember -Identity $Group -Recursive -ErrorAction Stop |
        Select-Object @{Name="PrivilegedGroup";Expression={$Group}},
                      Name, SamAccountName, ObjectClass
    }
    catch {
        Write-Warning "Could not query ${Group}: $($_.Exception.Message)"
    }
}

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

The exported report should be enriched with business owner, technical owner, purpose, approval status and last review date. A list without ownership information is difficult to govern.

Use adminCount as an Indicator, Not a Definitive List

The adminCount attribute can help identify user accounts associated with protected administrative groups:

Get-ADUser -LDAPFilter "(adminCount=1)" -Properties adminCount, Enabled, LastLogonDate |
Select-Object Name, SamAccountName, Enabled, LastLogonDate, adminCount

However, adminCount=1 is not a complete or current inventory of privilege. The attribute may remain set after an account has been removed from a protected group, and many delegated or locally privileged accounts will not have it set at all.

Use it as a useful investigative signal and compare it with current recursive group membership. Do not automatically clear the attribute or change permission inheritance without understanding why the account is protected and assessing the impact.

Identify Accounts with Direct Membership of Multiple Groups

Reviewing privilege from the account perspective can reveal identities with several administrative roles:

Get-ADUser -Filter * -Properties MemberOf |
Where-Object { $_.MemberOf.Count -gt 0 } |
Select-Object Name, SamAccountName,
    @{Name="DirectGroups";Expression={($_.MemberOf | ForEach-Object {
        (Get-ADGroup $_).Name
    }) -join "; "}}

This example reports direct group membership only and may be expensive in a large directory. Scope the query to relevant organisational units where possible, and use recursive group analysis when assessing effective privilege.

Look Beyond Privileged Groups

Group membership alone cannot identify every privileged identity. The next stage is to examine where permissions and control have been delegated.

Organisational Unit Delegation

Review access control entries on important organisational units, especially those containing administrators, service accounts, servers and domain controllers.

$OU = "OU=Users,DC=example,DC=com"

try {
    (Get-ADOrganizationalUnit -Identity $OU -ErrorAction Stop).GetSecurityDescriptor().Access |
        Where-Object { $_.ActiveDirectoryRights -ne "GenericRead" } |
        Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType, IsInherited, ObjectType
}
catch [Microsoft.ActiveDirectory.Management.ADIdentityNotFoundException] {
    Write-Host "Target OU '$OU' was not found in Active Directory." -ForegroundColor Yellow
}
catch {
    Write-Warning "Failed to retrieve ACL for '$OU': $($_.Exception.Message)"
}

Replace the example distinguished name with the OU being assessed. Investigate identities with rights such as GenericAll, GenericWrite, WriteDacl, WriteOwner, object creation and deletion, password reset, or the ability to modify group membership.

Group Policy Control

An identity that can create, edit or link an influential Group Policy Object may be able to change security settings or execute code on targeted computers. Review:

• Members of Group Policy Creator Owners
• Permissions on individual Group Policy Objects
• Who can link GPOs to sensitive organisational units
• Who can modify scripts or files referenced by a GPO

Local Administrator Rights

Accounts may be administrators on servers or workstations without holding elevated Active Directory group membership. Review local Administrators groups, Group Policy preferences, endpoint management policies and any custom groups used to grant local administrative access.

Control of Privileged Groups and Accounts

An identity does not need to belong to a privileged group if it can add itself to that group, reset the password of a privileged user or alter the object's permissions. These control paths should be treated as privilege.

Service and Automation Identities

Review accounts used by:

• Windows services
• Scheduled tasks
• Backup and monitoring platforms
• Deployment and remote management tools
• Microsoft Entra Connect and synchronisation services
• Scripts, integrations and application pools

Document where credentials are stored, which systems depend on the account, whether interactive logon is permitted and whether a group managed service account could be used instead.

Review the Accounts You Discover

Once privileged identities have been identified, assess whether each one is necessary and appropriately controlled.

For every account, record:

• The named business and technical owner
• The administrative purpose
• The source of privilege
• The systems and directory scope affected
• Whether the access is permanent or time limited
• The date of approval and last review
• Recent logon and password activity
• Whether the account is enabled and still required
• Whether stronger authentication and workstation controls apply

Pay particular attention to dormant accounts, shared administrator accounts, users combining everyday email and browsing with administrative access, accounts with passwords that never expire and privileged identities with no clear owner.

Common Mistakes to Avoid

Checking Only Domain Admins

Domain Admins is important, but it is not a complete definition of privilege. Forest-level groups, operators, custom roles and delegated permissions may all provide powerful access.

Ignoring Nested Groups

Direct membership reports can create false confidence. Always expand nested memberships and retain the path through which access is inherited.

Treating adminCount as Proof

The attribute is an indicator of protected-account history, not a live calculation of every form of effective privilege.

Removing Access Without Understanding Dependencies

Privileged service accounts and delegated roles may support critical operations. Validate ownership and dependencies, define a rollback plan and monitor the effect of any change.

Producing a Report but No Review Process

A point-in-time export becomes obsolete quickly. Privileged access discovery should feed an accountable process for approval, remediation and recurring certification.

Build a Repeatable Privileged Access Review

A sustainable review process should combine technical discovery with human validation.

1. Define the groups, permissions and systems considered privileged.
2. Inventory direct, nested, delegated, local and service-account access.
3. Map each identity to a named owner and documented purpose.
4. Assess whether the level and duration of access are justified.
5. Remove, reduce or time-limit unnecessary privilege through a controlled change process.
6. Record approvals and remediation decisions for audit purposes.
7. Repeat the review regularly and monitor changes between reviews.

High-impact groups and control paths should be monitored continuously. Broader certification can then take place monthly or quarterly, depending on organisational risk and change frequency.

Operational Limitations of Manual Discovery

PowerShell and native tools provide valuable visibility, but manual privileged-access reviews become difficult as environments grow.

Common challenges include:

• Combining group membership, nested access and delegated permissions
• Understanding effective rather than nominal privilege
• Finding product-specific and custom administrative groups
• Maintaining ownership and approval records
• Comparing current access with previous reviews
• Coordinating remediation without disrupting services
• Managing privilege across Active Directory and Microsoft Entra ID

Automating Privileged Account Governance

Active Directory management, auditing and identity governance platforms can help organisations move from occasional discovery to consistent control.

Depending on the platform, this may include:

• Automated privileged group and permission reporting
• Visibility of nested membership and effective access
• Alerts when sensitive accounts or groups change
• Approval workflows for administrative access
• Delegation through controlled, least-privilege roles
• Scheduled access reviews and owner certification
• Time-limited access and automated removal
• Historical reporting and audit evidence

Automation does not remove the need for ownership or judgement, but it can make the review process more complete, repeatable and defensible.

Final Thoughts

Identifying privileged accounts in Active Directory requires more than exporting the members of Domain Admins.

A complete review should examine the highest-privilege groups, nested memberships, protected-account indicators, organisational unit delegation, Group Policy control, local administration and powerful service identities. It should also consider accounts that can grant themselves privilege or take control of an existing administrator.

By combining technical discovery with clear ownership, regular certification and controlled remediation, organisations can reduce excessive privilege without preventing administrators from doing their jobs.