In Microsoft 365 Tenant ,When a user requests access to an application and an admin approves it, the permission is often granted tenant-wide meaning all users can access the app without additional consent.
In many organizations, this behavior creates an unintended exposure surface.
Also there is a common misunderstanding I hear from customers when discussing App Consent in Microsoft Entra ID.
They often say:
I control app consent in Enterprise Applications. I approve requests, so I know exactly who is accessing which app.
That’s not entirely accurate.
Let’s break it down clearly
In this blog, we’ll explore:
- How admin consent works when user consent is disabled
- Why approval applies to all users
- How to restrict app access to specific users only
- A step-by-step lab test for App Consent and User Access
- Governance best practices
“Securing the Gates: Mastering Admin and User Consent in Microsoft Entra ID”
The Real Problem
When: User consent is set to “Do not allow user consent”
Admin approves the request
You might notice this small text displayed on the Admin Approval page.
If you accept, this app will get access to the specified resources for all users in your organization. No one else will be prompted to review these permissions.
Which means:
Admin Consent applies to the entire tenant , Not only the requesting user. That’s by design in Microsoft Entra ID.
So how do we control it?
Good Question!!
Understanding the Behavior
When admin approves: The Service Principal is updated- OAuth permissions are granted at the tenant level
- Any user allowed to access the application can now sign in
- Consent = Controls permissions
- Assignment = Controls access
Lets see this in Action
Demonstrate how consent applies tenant-wide and how to restrict it.
Step-1
Go to Entra Admin Center → Enterprise Applications → Consent and Permissions → User consent settings
Selected as:
Do not allow user consent
Note: If “Let Microsoft manage your consent settings (Recommended)” is selected, the Microsoft-managed policy will automatically apply Microsoft’s latest recommended default consent configurations. This option is also enabled by default for all new tenants.
Under the current policy rules:
End users can grant consent to any user-consentable delegated permissions, except the following restricted permissions.
Microsoft Graph (Restricted Permissions)- Files.Read.All
- Files.ReadWrite.All
- Sites.Read.All
- Sites.ReadWrite.All
- Mail.Read
- Mail.ReadWrite
- Mail.ReadBasic
- Mail.Read.Shared
- Mail.ReadBasic.Shared
- Mail.ReadWrite.Shared
- MailboxItem.Read
- Calendars.Read
- Calendars.ReadBasic
- Calendars.ReadWrite
- Calendars.Read.Shared
- Calendars.ReadWrite.Shared
- Chat.Read
- Chat.ReadWrite
- OnlineMeetings.Read
- OnlineMeetings.ReadWrite
- MailboxFolder.Read
- MailboxFolder.ReadWrite
- MailboxSettings.Read
- MailboxSettings.ReadWrite
- EAS.AccessAsUser.All
- EWS.AccessAsUser.All
- IMAP.AccessAsUser.All
- POP.AccessAsUser.All
- EAS.AccessAsUser.All
- EWS.AccessAsUser.All
- IMAP.AccessAsUser.All
- POP.AccessAsUser.All
In summary, while Microsoft-managed consent simplifies governance by applying recommended defaults, it blocks end users from consenting to high-impact permissions,particularly those involving full access to files, mailboxes, calendars, chat, and legacy mail protocols(Which basically needs an Admin Consent).
Step 2 – User Attempts to Access App
User tries to sign in to a 3rd party app (example: custom test app).in My case i am testing with Graph explorerThey receive: "Need admin approval" Page
They click: Request approval
Step 3 – Admin Reviews Request
Go to:Entra Admin Center → Enterprise Applications → Admin consent requests
Review the request. Click: Review permissions and consent
Step 4 – Observe the Behavior
Now: The service principal has permissions granted
If another user (who never requested access) attempts to sign in — for example, Demo1 requested consent and the admin approved it , then when Demo2 signs in afterward, they will be able to access Microsoft Graph without triggering any additional consent prompt.
Since admin consent was already granted at the tenant level, Graph Explorer will authenticate Demo2 automatically and allow access based on the previously approved permissions.
By default, once Admin Consent is approved, all users can access the application without any additional approval , unless access is explicitly restricted through assignment or policy controls.
This confirms: Consent was applied tenant-wide
How to Restrict Access to Only the Requesting User
The key is this: Consent ≠ User AssignmentControl is done via Application User Assignment.This is the cleanest enterprise control.
| Layer | What it Controls |
|---|---|
| Admin Consent | What permissions the application has in your tenant |
| User Assignment | Which users are allowed to sign in to the application |
How to do this Go to: Enterprise Applications → Select the App → Properties
Enable: Assignment required? = Yes (By default its set as No for every new application)
Now:
- Even if admin consent is granted
- Only assigned users can access the app
Now navigate to: Enterprise Applications → Users and Groups → Add user/group
Assign only the user who originally requested access.in our case demo1
We have added demo1 to the assignments
When a user who has not been assigned to the application tries to access Graph Explorer, they will receive the following error message:
Your administrator has configured the application Graph Explorer ('de8bc8b5-d9f9-48b1-a8ad-b748da725064') to block users unless they are specifically granted ('assigned') access to the application.
This confirms that enabling “Assignment required = Yes” successfully restricts access to only explicitly assigned users.
The Common Misunderstanding
Many administrators believe:
“If I approve a request, it applies only to that specific user.”
That is incorrect.
When an admin grants consent, the permission is granted tenant-wide.
Any user can potentially access the application unless you explicitly enable:
- User assignment required = Yes
- And restrict access to specific users or groups
The Correct Understanding
- Admin consent = tenant-level permission grant
- User assignment = user-level access control
If you don’t enforce assignment restrictions, approving consent effectively opens the door for all users.
Two different layers. Two different purposes. Both must be configured correctly.
Enterprise Governance Model Recommendation
In enterprise environments (especially those with:- P2 licenses
- Privileged Identity Management
- Access Reviews
- Security Governance frameworks
- Disable User App Consent: Set to, Do not allow user consent
- Enable Admin Consent Workflow: So requests are tracked and auditable
- Always Enable "Assignment Required": For all non-Microsoft Apps, if Not Assign Conditional Access Policy to Restrict App Access for specific users
- Use Access Reviews: Periodically review app assignments
Conclusion
Admin consent in Microsoft Entra ID is always tenant-wide by design.
When an administrator approves a permission request, the consent is granted at the service principal level, not the user level. This means future users can access the application unless additional access controls are enforced.
If user consent is disabled ,which is the recommended security posture in enterprise environments , organizations must understand that:
Consent controls permissions. Assignment controls access.
0 Comments