🔐 Recipe · Entra ID & Identity
Troubleshoot Admin Consent Failures for Delegated Graph API Permissions
Diagnose why users with User Administrator role cannot grant admin consent, and assign the correct least-privilege role to enable consent for delegated Graph API scopes like User.Read.All
Complexity
Intermediate
Impact
security + access-management + least-privilege + troubleshooting
Context
Why This Matters
A common source of confusion in Microsoft Entra ID is when a user with the User Administrator role attempts to grant admin consent for a Graph API permission (such as User.Read.All) and is blocked with a consent error. Many admins assume that because User Administrator can manage users and groups, it also covers application consent — but this is not the case.
Admin consent for application permissions is controlled by a separate set of roles: Global Administrator, Privileged Role Administrator, Cloud Application Administrator, and Application Administrator. If a user holds only User Administrator, they will fail to consent for any Graph scope that requires admin approval.
Run this recipe when:
- A delegated admin reports they cannot approve consent prompts for internal tools (Dex CoAdmin, Power Platform connectors, custom apps)
- You need to enable a non-Global-Admin to grant consent on behalf of the tenant
- You want to verify your tenant's consent policy and identify which roles are assignable
- You are rolling out least-privilege admin delegation and need to split user management from app management
Expected Outcomes
After completing this recipe you will have:
- A clear diagnosis of why a given user cannot grant admin consent (role gap, tenant consent policy restriction, or missing service principal)
- The correct least-privilege role assigned to the affected user — typically Cloud Application Administrator — so they can grant consent without becoming a Global Admin
- Verified the tenant's authorization policy and permission grant policies
- A repeatable script to audit and remediate similar cases across multiple users
- Documentation of the role assignment for audit/compliance evidence
Risks & Considerations
Security and compliance considerations
- Cloud Application Administrator is privileged. It can grant consent to almost any Graph API permission (except RoleManagement.* and app role assignments requiring Privileged Role Administrator). Treat holders as Tier 1 admins: enforce MFA, Conditional Access, and PIM where possible.
- Do NOT default to Global Administrator. Granting Global Admin just to enable consent violates least-privilege. Always prefer Cloud Application Administrator or Application Administrator.
- Admin Consent Workflow is a safer alternative for large tenants: leave regular users with User Administrator and route consent requests to a reviewer queue instead of granting them consent rights directly.
- Tenant consent policy may still block the action even after role assignment. If
ManagePermissionGrantsForSelf.*policies are restrictive, or if the app is flagged as risky, the consent will still fail — you must also verify the permission grant policy. - Do not confuse delegated and application permissions. User.Read.All as delegated requires admin consent because it reads across the directory. The fix is role-based; the symptom looks identical to an app-permission consent failure.
- Log all role assignments in your change management system; Entra audit logs retain them but correlation with tickets speeds incident review.
Required Permissions
| Permission | Why It's Needed |
|---|---|
| RoleManagement.ReadWrite.Directory | Required to read role definitions and assign directory roles like Cloud Application Administrator. |
| Directory.Read.All | Required to look up the target user and verify their current role memberships. |
| Policy.Read.All | Required to inspect the tenant authorizationPolicy and permissionGrantPolicies to rule out tenant-level blocks. |
| Application.Read.All | Required to enumerate service principals and confirm the target app (e.g. Dex CoAdmin) is registered in the tenant. |
The fastest way to get this done: just ask Dex. Copy the prompt below and paste it into your Dex conversation.
For IT Admins
Paste into Dex Pro
For End Users
How an employee would ask Dex for help
Diagnose and fix admin consent failures via the Entra admin center
Step 1 — Confirm the symptom
- Have the affected user attempt to consent again and capture the exact error message and correlation ID.
- Typical error: "AADSTS65001: The user or administrator has not consented to use the application" or "Need admin approval" with no approve button visible.
Step 2 — Verify the user's current roles
- Navigate to .
- Search for the affected user (e.g.
{user_upn}) and open their profile. - Click Assigned roles in the left menu.
- If only User Administrator is listed, that is the root cause — User Administrator cannot grant application consent.
Step 3 — Check tenant consent settings
- Navigate to .
- Confirm which users are allowed to consent and for which permission classifications.
- Navigate to and note whether the Admin Consent Workflow is enabled.
Step 4 — Assign Cloud Application Administrator
- Go back to the user's Assigned roles blade.
- Click + Add assignments.
- Search for and select Cloud Application Administrator.
- Choose assignment type (Active or Eligible if using PIM) and scope (typically Directory).
- Provide a justification and click Assign.
Step 5 — Validate
- Have the user sign out and sign back in to refresh their token.
- Retry the consent flow. The "Consent on behalf of your organization" checkbox should now be available.
- Confirm the grant appears under .
Diagnose and remediate via Microsoft Graph API
1. Resolve the user and list current roles
GET https://graph.microsoft.com/v1.0/users/{user_upn}?$select=id,displayName,userPrincipalName,accountEnabledGET https://graph.microsoft.com/v1.0/users/{user_upn}/memberOf/microsoft.graph.directoryRole?$select=id,displayNameIf the response only contains User Administrator, the user lacks consent-granting permissions.
2. Inspect the tenant authorization policy
GET https://graph.microsoft.com/v1.0/policies/authorizationPolicyReview defaultUserRolePermissions.permissionGrantPoliciesAssigned — restrictive policies (e.g. removing microsoft-user-default-allow-consent-apps) can compound the issue.
3. Look up the Cloud Application Administrator role
The role template ID for Cloud Application Administrator is fixed: 158c047a-c907-4556-b7ef-446551a6b5f7. If the role is not yet activated in the tenant, activate it:
POST https://graph.microsoft.com/v1.0/directoryRoles
Content-Type: application/json
{
"roleTemplateId": "158c047a-c907-4556-b7ef-446551a6b5f7"
}4. Assign the role using unified role management
POST https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments
Content-Type: application/json
{
"principalId": "{user_object_id}",
"roleDefinitionId": "158c047a-c907-4556-b7ef-446551a6b5f7",
"directoryScopeId": "/"
}Successful response: 201 Created with the new assignment object.
5. Verify
GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments?$filter=principalId eq '{user_object_id}'The new assignment should be listed. Have the user re-authenticate to pick up the updated claims.
Automate diagnosis and remediation with PowerShell
The script below uses the Microsoft Graph PowerShell SDK to: (1) look up the target user, (2) list their current roles, (3) detect the User-Administrator-only pattern, (4) assign Cloud Application Administrator if -Remediate is passed, and (5) verify the result.
Prerequisites
Install-Module Microsoft.Graph -Scope CurrentUser- Sign in as a Global Administrator or Privileged Role Administrator:
Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory","Directory.Read.All","Policy.Read.All"
Usage
# Diagnose only
.\Fix-ConsentRole.ps1 -UserPrincipalName user@contoso.com
# Diagnose and remediate
.\Fix-ConsentRole.ps1 -UserPrincipalName user@contoso.com -RemediateThe script is idempotent — re-running it on a user who already has Cloud Application Administrator will not create duplicate assignments.
Next steps