Review Privileged Role Assignments in Entra ID

Practical intro

Before changing security controls, I want to know who has privileged access. Otherwise, it is too easy to break the wrong workflow or miss an account that needs extra scrutiny.

Why I check this

Many admins inherit environments where roles have grown over time. A repeatable role export gives the first review a clear starting point before Conditional Access, authentication, device, or admin workflow changes begin.

What this check tells you

This starter check reviews active Entra directory roles and current role members returned by Microsoft Graph PowerShell. It helps identify which users, groups, service principals, or other directory objects appear in active role membership before security changes begin.

What this helps you decide

This helps you decide where privileged access needs explanation before you adjust security controls. The first pass is practical: list the active role members, separate user accounts from groups and service principals, and decide which assignments need an owner, a reason, or a deeper PIM and governance review.

What this does not prove

This check does not provide a complete Privileged Identity Management review. It may not show eligible PIM assignments, assignment schedules, time-bound activations, access packages, custom governance workflows, or every modern role management view. It is still useful as a first read-only visibility check before security changes.

When I would run this

• Before changing Conditional Access or authentication settings.
• Before admin role cleanup discussions.
• During tenant discovery, security review, or documentation refresh work.

Permissions and modules

Review and approve the scopes before running the example. Microsoft Learn lists RoleManagement.Read.Directory as a delegated read permission for Get-MgDirectoryRole, with Directory.Read.All also listed for directory role reads.

• Microsoft.Graph.Authentication
• Microsoft.Graph.Identity.DirectoryManagement

Read-only PowerShell example

This example reads active directory roles and role members, then exports a CSV. The Microsoft documentation notes that the directory role must be activated in the tenant for Get-MgDirectoryRole to return it.

# SecureOps Playbooks | secureopsplaybooks.com
# Read-only example: privileged role assignment review. Validate in a lab first.

Connect-MgGraph -Scopes "RoleManagement.Read.Directory","Directory.Read.All"

$roles = Get-MgDirectoryRole -All
$rows = foreach ($role in $roles) {
  $members = Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id -All

  foreach ($member in $members) {
    $memberType = $member.AdditionalProperties["@odata.type"]
    $displayName = $member.AdditionalProperties["displayName"]
    $userPrincipalName = $member.AdditionalProperties["userPrincipalName"]
    $appId = $member.AdditionalProperties["appId"]

    [pscustomobject]@{
      RoleName = $role.DisplayName
      RoleId = $role.Id
      MemberId = $member.Id
      MemberType = $memberType
      DisplayName = $displayName
      UserPrincipalName = $userPrincipalName
      AppId = $appId
      ReviewNote = "Active directory role member returned by this Graph check; review member type and confirm whether PIM or other role views need separate review."
    }
  }
}

$rows |
  Sort-Object RoleName, DisplayName |
  Export-Csv ".\entra-privileged-role-review.csv" -NoTypeInformation

Expected output columns

• RoleName
• RoleId
• MemberId
• MemberType
• DisplayName
• UserPrincipalName
• AppId
• ReviewNote

How to read the results

Start with highly privileged roles and members you cannot explain. Do not assume every member is a user account: the output can include users, groups, service principals, or other directory objects, and some fields may be blank depending on the object type returned. Finding an object in a privileged role does not automatically mean it is wrong. It means the assignment should be reviewed in context.

Common findings

• Admin roles assigned to accounts that need a current business reason.
• Role membership that is not documented anywhere else.
• Non-user members that need a separate review path.

False positives or normal explanations

Some role assignments may support emergency access, automation, delegated administration, or approved operational workflows. The export should help document those decisions, not assume they are incorrect.

What to verify before action

• Whether each assignment has an owner and current reason.
• Whether the member is a user, group, service principal, or another object type.
• Whether Privileged Identity Management has eligible assignments that need a separate export.
• Whether emergency access accounts are documented and monitored according to tenant policy.
• What evidence supports changing, keeping, or escalating each role assignment for review.

Troubleshooting

• If Graph prompts for consent, confirm the read scope with the tenant owner.
• If some member fields are blank, inspect the member type and review it separately.
• If expected roles are missing, confirm whether the role is active in the tenant.
• If the export is hard to review, sort by role risk and start with the most privileged roles first.

Limitations

This example focuses on active directory roles and current role members returned by the Graph cmdlets shown. It does not replace a complete privileged access review, PIM review, eligible assignment review, activation schedule review, access review process, or governance workflow.

Sources and documentation to review

• Microsoft Graph PowerShell Connect-MgGraph documentation
• Microsoft Graph directory roles documentation
• Microsoft Graph directory role member documentation
• Microsoft Entra role documentation

Validation status

This is an example read-only playbook. Review the Microsoft documentation, permissions, and output in a test or lab environment before using it as part of a production change process.

Related playbooks

• Audit MFA Registration
• Find External Mailbox Forwarding
• M365 Admin Quick-Check Pack