Troubleshooting consent in Azure AD

This is a general guide for troubleshooting consent in Azure AD. It will help resolve majority of the consent related scenarios (Not all of them). In general, the application is trying to sign-in or get an access token for a resource which has not been consented by the user or admin. In general, you want to make sure all of the permissions needed by the application have been consented to.

This article only applies to OpenID Connect and OAuth2 based authentications. SAML based applications which may throw the same type of errors however may have a different solution. Generally, the issue will be inside the SAMLRequest. Either the configuration on the third-party SAML Service Provider or Azure AD does not match.

Overview

You get one of the following similar messages…

Need admin approval
AADSTS65001: The user or administrator has not consented to use the application with ID ‘{App-Id}’ named ‘{Name-of-App}’. Send an interactive authorization request for this user and resource.
AADSTS650056: Misconfigured application. This could be due to one of the following: The client has not listed any permissions for ‘AAD Graph’ in the requested permissions in the client’s application registration. Or, The admin has not consented in the tenant. Or, Check the application identifier in the request to ensure it matches the configured client application identifier. Please contact your admin to fix the configuration or consent on behalf of the tenant.
AADSTS90094: An administrator of <tenantDisplayName> has set a policy that prevents you from granting <name of app> the permissions it is requesting. Contact an administrator of <tenantDisplayName>, who can grant permissions to this app on your behalf.
AADSTS90008: The user or administrator has not consented to use the application with ID ‘162841d6-3c61-4676-a2c1-5a9c1e68ccf3’. This happened because application is misconfigured: it must require access to Windows Azure Active Directory by specifying at least ‘Sign in and read user profile’ permission

As you can see from the list above, there are lots of variations of how we basically say, an admin needs to consent to the application.

There are a lot of different reasons for getting a message about admin approval or admin consent is required, or one of the other various messages.

Here are some of the high-level scenarios of what to look for…

User.Read permission is missing.
User consent is disabled.
User Assignment required is enabled.
Service principal does not exist in tenant for client app.
Service principal does not exist in tenant for resource.
Hitting the consent url (prompt=admin_consent & prompt=consent).
Scopes requested in sign-in request that have not been consented to yet.
The scope/permission requires Admin consent.
User Consent Blocked For Risky Apps

Simply adding permissions to an application registration is NOT consenting to the permissions. This is probably the most common mistake. So, what do we mean when we say “consented” to permissions?

Understand Application registrations vs Enterprise applications

In Azure AD, we have an application model that consists of “Application” objects also called “Application registrations” and “ServicePrincipal” objects also called “Enterprise applications” and how their relationship works together based on the required permissions set up on the Application object.

To learn more about that relationship, review the following article…

https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals

Assigning permissions to the ServicePrincipal object is what defines when we say “consented” to.

Understand Delegated permissions vs Application permissions

There are two types of permissions: Delegated and Application permissions.

To learn more about permissions in Azure AD, review the following articles…

https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent

Understanding the difference between application and delegated permissions from OAuth2 Authentication Flows perspective

You need to make sure you apply the correct permission configuration in the Application registration and consent to that permission.

Understand the Azure Active Directory Consent Framework model

There is a reason why we are asking for consent. In most cases, the sign-in request or based on the application configuration, something has not been consented to yet that requires consent. Understand our consent framework…

Make sure the Application has the permission to allow a user to sign in. (I.e. User.Read permission)

First and foremost before we go into any troubleshooting, lets make sure your app allows users to sign in.

If you own the Application registration, at minimum, any application where you expect a user to sign in, you should at least have the Microsoft Graph “User.Read” or “Openid” Delegated permission added to the Application registrations API Permissions and the permission has been consented to…

Troubleshooting

I suppose that’s enough of concepts and theory. Let’s start with the troubleshooting.

Step 1: Get the sign-in request sent to Azure AD.

Based on the parameters being passed to Azure AD, we can start figuring out why the consent screen is being prompted and why it is failing.

First, we need to understand the request sent to Azure AD.

A sign-in request looks something like this…

Azure AD V1 OAuth2 endpoint:
https://{Aad-Instance}/{Tenant-Id}/oauth2/authorize?client_id={App-Id}&response_type=code&redirect_uri={redirect-uri}&resource={App-URI-Id}&scope={Scope}&prompt={Prompt}

Azure AD V2 OAuth2 endpoint:
https://{Aad-Instance}/{Tenant-Id}/oauth2/v2.0/authorize?client_id={App-Id}&response_type=code&redirect_uri={redirect-uri}& scope={Scope}&prompt={Prompt}

If you’re not sure how to get this or see this sign-in request…

If you’re using a browser, look at the address bar
If you’re not using a browser or still can’t see the address bar in the browser, then a HTTP capture tool like Fiddler will be required.

If you just want to skip finding the root cause and go straight to resolving the issue, go to Step: Perform admin consent.

Here is a quick table for you to use and track the information obtained from the sign-in request.

Property	Sign-in request portion	Value
Aad-Instance	{Aad-Instance}
Tenant-Id	{Tenant-Id} portion of the sign-in request
App-Id	{App-Id} portion of the sign-in request
Scope	{Scope} portion of the sign-in request
App-URI-Id	{App-URI-Id} portion of the sign-in request
Prompt	{Prompt} portion of the sign-in request

For example, your table might look like this…

Property	Sign-in request portion	Value
Aad-Instance	{Aad-Instance}	login.microsoftonline.com
Tenant-Id	{Tenant-Id} portion of the sign-in request	common
App-Id	{App-Id} portion of the sign-in request	1f92960d-1442-4cd2-8c76-d13c5dcb30bf
Scope	{Scope} portion of the sign-in request	Openid+User.Read+Directory.Read.All
App-URI-Id	V1 endpoint: {App-URI-Id} portion of the sign-in request V2 endpoint: For resources other than Microsoft Graph, this would be the portion before the scope name. For example… https://analysis.windows.net/powerbi/api/App.Read.All App.Read.All is the scope name so the App-Uri-Id is https://analysis.windows.net/powerbi/api	https://graph.microsoft.com
Prompt	{Prompt} portion of the sign-in request

The information obtained from this sign-in request will be used throughout the troubleshooting steps. I will reference them like this…

{App-Id} from the table above.

Step 2: Do you allow users to consent?

First check if User consent is allowed in your organization…

Sign in to the Azure portal @ https://portal.azure.com
Go to Azure Active Directory
Go to Enterprise applications
Go to User settings
Review “Users can consent to apps accessing company data on their behalf“
1. If “Yes” is selected, then users can consent to permissions which do not require Admin consent. Move on to the next step.
2. If “No” is selected, Users will always get the “Need admin approval” message. An admin must perform admin consent.
  Go to Step: Perform admin consent
Note: If an admin believes he has already consented to these permissions, most likely either not all of the required permissions listed in the sign-in request were consented to or the wrong application was used based on the {App-Id} from the table above.

Step 3 will cover the App-Id in more detail.
Step 4 will cover the permissions in more detail.

Step 3: Verify the application being used.

Verify if the application exists in the tenant.

Sign in to the Azure portal @ https://portal.azure.com
Ensure you switch to the correct tenant based on the {Tenant-Id} from the table above.
Go to Enterprise applications.
Switch Application Type to All Applications and search for the {App-Id} from the table above.
If the application is not found, this would be the cause of you getting the consent messages. Go ahead and skip to Step: Perform admin consent.

If the application is found, go to the next step.

Step 4: User assignment required

While in the Enterprise application, go to Properties and review the User assignment required setting.

If user assignment is required, an admin must consent to this application. Go to Step: Perform admin consent.

If user assignment is not required, go to next step.

There is always confusion that when you consent to an application for all users in the organization that this will allow all users to access the application. This is not true; we will still follow the user assignment rules. Only those users assigned to the application can access it.

Otherwise, if you really do not want to perform admin consent, then the only other option would be to turn off user assignment required, have the user consent when they access the application, and turn user assignment required back on.

Step 5: Verify the permissions.

Let’s next verify that the scopes (or also called permissions) in the sign-in request are listed in the permissions section of the Enterprise App…

If the application is found from the step above (Step 3), go ahead and select that application.
Go to permissions…
Compare what is listed on the permissions page and what is listed as {Scope} from the table above in the sign-in request. The permissions listed on this page are the permissions that have been consented.Note: Pay extra attention to the permission type. Keep in mind that Delegated permissions are for when users sign in and Application permissions are for when the service principal is used to authenticate via the client credential flow. Note: OpenID Connect scopes are generally not listed in the Enterprise application. Don’t worry if the following are not listed…

Openid: Sign users in
Email: View users’ email address
Profile: View users’ basic profile
Offline_access: Maintain access to data you have given it access to

Note: if {Scope} from table above is blank or contains less than what is listed on the permissions page, go ahead to the next step.

If there are other scopes in {Scope} from the table above that are not on the permissions page, then go to Step: Perform admin consent. These missing permissions still need to be consented.

Step 6: Verify the resource exists in your tenant.

Easiest way to do this is generate a request that looks like this…

https://{Aad-Instance}/{Tenant-Id}/oauth2/authorize?response_type=code&client_id={App-Id}&resource={App-Uri-id}

You might get one of 4 behaviors…

You will be allowed to sign-in (This is the behavior you want to see) Your good to go to next step. In most cases, if you see the “code” parameter in the address bar, this means authentication piece was successful.
AADSTS650052: The app needs access to a service (\”https://api.contosocloud.williamfiddes.onmicrosoft.com\”) that your organization \”mycloude5.onmicrosoft.com\” has not subscribed to or enabled. Contact your IT Admin to review the configuration of your service subscriptions. This means the resource does not exist in your organization. To resolve this, use the following consent URL… https://login.microsoftonline.com/{Tenant-Id}/oauth2/authorize?response_type=code&client_id={App-Uri-id}&prompt=admin_consent
AADSTS650057: Invalid resource. The client has requested access to a resource which is not listed in the requested permissions in the client’s application registration. Client app ID: {App-Id}({App-Display-Name}). Resource value from request: ‘{App-Uri-Id}‘. Resource app ID:{Resource-App-Id}. List of valid resources from app registration: 00000002-0000-0000-c000-000000000000 In order for a client application to sign-in and get an access token for a resource, that resource must be assigned to the client applications required API permissions… For example, for a client application to access Azure Key Vault…
Only the application owner can do this.
AADSTS500011: The resource principal named ‘{App-Uri-Id}‘ was not found in the tenant named ‘{Tenant-Id}‘. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You might have sent your authentication request to the wrong tenant.This means either the {App-Uri-Id} specified is not valid at all or is only available as a single tenant application. Otherwise meaning this resource can not be accessed by external organizations or does not exist. You will need to work with the application owner. You will need to verify that {App-Uri-Id} and {Tenant-Id} is correct. If the {App-Uri-Id} is owned by a different {Tenant-Id} then the app registration for {App-Uri-Id} must be set up as a multi-tenant application. Otherwise the {Tenant-Id} must be the same tenant as where the app registration for {App-Uri-Id} is located.

Step 7: Verify if the prompt parameter is being passed.

Sometimes, the way in which your signing into the application is always passing the prompt parameter of consent or admin_consent. Once the application has been consented to, make sure the prompt parameter is not specified. Otherwise, your users might always get the consent error.

You sign-in request might look something like this…

https://login.microsoftonline.com/contoso.onmicrosoft.com/oauth2/authorize?client_id=1f92960d-1442-4cd2-8c76-d13c5dcb30bf&response_type=code&redirect_uri=https://www.contoso.com&scope=openid+profile+User.Read+Directory.Read.All&prompt=consent

So simply remove the prompt parameter and now it should look something like this…

https://login.microsoftonline.com/contoso.onmicrosoft.com/oauth2/authorize?client_id=1f92960d-1442-4cd2-8c76-d13c5dcb30bf&response_type=code&redirect_uri=https://www.contoso.com&scope=openid+profile+User.Read+Directory.Read.All

Step: Perform admin consent.

Have the admin (user with the Global/Company administrator role or a Application Administrator role) access the application normally.
When the consent screen appears, review the request permissions.
Note: If an admin is not sure what the permissions allow, then the admin must work with the application vendor to understand the permissions and what they are used for. Microsoft support may not know what these permissions do or why the permissions are needed.
If the admin approves the permissions requested, ensure the checkbox is selected to “Consent on behalf of your organization”

Step: Force Admin Consent

If the admin does not get the consent screen,

Remember step 1? Grab that sign-in address and add &prompt=consent

So, for example, the sign-in request the admin should use will look something like this…

https://login.microsoftonline.com/contoso.onmicrosoft.com/oauth2/authorize?client_id=1f92960d-1442-4cd2-8c76-d13c5dcb30bf&response_type=code&redirect_uri=https://www.contoso.com&scope=openid+profile&tresource=https://graph.microsoft.com&prompt=consent

If the permissions needed are not in the application registration, then the V2 endpoint can be used… (V2 endpoint requires each permission scope to be passed in the scope parameter)

https://login.microsoftonline.com/contoso.onmicrosoft.com/oauth2/v2.0/authorize?client_id=1f92960d-1442-4cd2-8c76-d13c5dcb30bf&response_type=code&redirect_uri=https://www.contoso.com&scope=openid+profile+User.Read+Directory.Read.All&prompt=consent

Permission scopes used by the application must be provided by the application owner.

Other tips

Consent for Application permissions will always require admin consent from a Global/Company administrator. Application permissions must be added within the application registration on the applications owning tenant.
Application admins can also consent to Delegate permissions which require admin consent.
When using the adminconsent URL, the permissions must already be configured with the application registration. Otherwise meaning, the application owner must have their application correctly configured with Azure AD. adminconsent URL looks something like this… https://login.microsoftonline.com/{Tenat-Id}/adminconsent?client_id={App-Id}

For more information about troubleshooting consent issues…

You can use the Azure AD Audit logs to get more details…

Sign in to the Azure Portal @ https://portal.azure.com (Use a account that has permission to read Audit logs. Like a Global Admin or Security Reader).
Go to Azure Active Directory.
Go to Audit logs.
Set your filter to…
1. Category: ApplicationManagement
2. Status: Failure
3. Activity: Consent to application
Find and select the app that’s failing to consent.
Observe the STATUS REASON. This might give you more details. For certain scenarios like “Microsoft.Online.Security.UserConsentBlockedForRiskyAppsException” will require you to perform a Admin consent even though you may allow users to consent and the permission normally does not require an admin to consent.

For more information, see the following…

https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-sign-in-unexpected-user-consent-error#requesting-not-authorized-permissions-error

https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-sign-in-unexpected-user-consent-prompt

One Thought to “Troubleshooting consent in Azure AD”

Leave a Comment Cancel reply

Recent Posts

Archives

Categories