Azure AD Login error

4 ways to fix error AADSTS65001 (The user or administrator has not consented to use the application)

This post was most recently updated on September 10th, 2020.

Reading Time: 6 minutes.

Have you run into error AADSTS65001 with your application, that tries to authenticate against Azure AD? I sure have – seems to happen at least every other time when I’m building something that uses AAD to authenticate against SharePoint.

Fixing issues with Azure AD authentication for Enterprise applications can be tricky. But a lot of the time, this is just another Azure Active Directory error that we can fix easily. This article contains multiple different solutions to the issue, where granting admin consent has somehow failed.

Not all of the different solutions will work for all situations, though! That’s why I included a couple of different options to try. Changes are, one of them works for you!

What’s the reason for issues with Admin Consent (like AADSTS65001)?

Imagine this: You’re trying to add or use an app, but the requires such permissions from your tenant, that only an administrator can grant. Typically to add this kind of an app, you’ll have to be a global administrator.

This is when admin consent is required for the usage of the app – and if that hasn’t been granted, you’ll get errors about administrators not having consented to the use of the app you’re accessing. This way, you also can’t add the app yourself.

Additionally, just to make the investigation just a bit more complicated, if it’s an enterprise application, it could also be in an invalid state after someone tried adding the app without sufficient permissions. This could stop you from adding the app, even if you do have sufficient permissions!

Fun, right? But no worries, as there’s always a workaround or two available!

I’ve been investigating a lot of these issues in relation to organizations using a mobile app, which the customer has been deploying as an enterprise application. Most of the things should apply for web-based apps or console programs or whatever else you’re deploying, too – especially if they’re enterprise applications in Azure AD!

The whole error might look something like this:

Failed to authenticate #1: 
Error: Request authority:https://login.windows.net/common resource:https://tenant.sharepoint.com clientid:[appId]  ErrorCode:invalid_grant ErrorDescription:AADSTS65001: The user or administrator has not consented to use the application with [appid]. 
Send an interactive authorization request for this user and resource.

Trace ID: 5b92cb30-6321-4e2a-99e3-b4b2b6a46c94
Correlation ID: fc8a84ec-1578-4290-b49b-42322b791a3a
Timestamp: 2016-11-17 11:49:30Z

Or you get something like this:

{  
 "error":"invalid_grant",  
 "error_description":"AADSTS65001: The user or administrator has not consented to use the application with ID [appId]"
}

How to fix these issues?

Solutions

Okay, there’s a bunch of solutions, which I’m going to outline here. I’ll be starting from the easy ones and progressing to more difficult and exotic ones.

Please note: if you have an issue, where only admin users are able to log in (without any dialogs or warnings about granting permissions), and everyone else gets an error, please jump directly to solution 2.

Solution 1: Get help from an admin

First of all, maybe it’s true. Simple, but worth trying first. Maybe an admin really hasn’t consented to the permissions. Just get someone with global administrator permissions to try the app, and see what happens.

If it doesn’t work for him/her either, check out the next solution.

Solution 2: Make sure your Azure AD settings allow adding such apps

There are a couple of properties under Azure AD Application > Manage > User settings that affect how the app is registered. Someone in your organization may have turned app registration off altogether, or limited the options severely. You could check these settings out – they should look something like this:

Older Portal versions (the UI updates are rolled out in batches) will look something like this:

Azure AD Application settings - these selections should enable adding new apps to your organization!
Azure AD Application settings – these selections should enable adding new apps to your organization! However, they might not be what your organization can enable, so please evaluate.

The latest Portal version (as of 7.3.2019) has split the settings to 2 different areas. You’ll have the settings concerning app registrations “local” to just this directory under Directory > Manage > User settings. The settings only affecting Enterprise Applications are accessible by either clicking a link on the aforementioned page, or by navigating to Directory > Enterprise applications > User settings.

See the 2 screenshots below – first, you can edit the “user settings” from the AAD.

The "User Settings" view for your Azure Active Directory instance's Enterprise Applications. It's accessible through Directory > Enterprise applications > User settings.
The “User Settings” view for your Azure Active Directory instance’s Enterprise Applications. It’s accessible through Directory > Enterprise applications > User settings.

And when you select to access the end-user settings from there, you’ll be able to change the settings for Enterprise Applications in particular.

"User Settings" view for your Azure Active Directory instance in general. Accessible via Directory > Manage > User settings.
“User Settings” view for your Azure Active Directory instance in general. Accessible via Directory > Manage > User settings.

Note: If you absolutely need to have the ability to register apps turned off (for example, to comply with GDPR or similar regulation), I have another article in the works on possible workarounds of Azure AD app registration.

Ping me or send me a nudge via comments or https://www.koskila.net/contact/ to remind me to finish that article!

Solution 3: Remove the app, and be sure to ask a global admin to log in once

If the settings above where ok, check this tip out. This solution itself only applies to Enterprise Applications, since the method for registering a “normal app” is different from enterprise ones. Enterprise apps are registered to your Azure AD instance automatically based on their application ID. More or less it should just provision a service principal based on the app id, which in turn is specified in the manifest that stays wherever the enterprise app was originally registered in. From an user’s point of view, this should happen automatically. It always doesn’t.

Typically, someone might try to add an enterprise application without having permissions to do so. Apparently this causes your Azure AD instance to get quite confused, and the app won’t work. Not for admins (who could grant the consent), but also especially not for you.

That means, that this particular instance of the app will not work. Ever.

You can fix this quite easily, though. Global administrator just needs to browse to Azure AD (remember to choose the right one, though), remove the app (see screenshot below), and then log in to the app. With some apps it’s pivotal, that the first person to log in is a global administrator, to make it possible for them to give admin permission in the first place (duh).

Azure AD - how to remove an enterprise application (registration) from your AAD instance
Azure AD – how to remove an enterprise application (registration) from your AAD instance

Solution 4: Craft a specific log in & admin consent url for a global admin to test

If you don’t have admin permissions, and maybe none of the global administrators can user any apps or something, maybe you could try this next. You can just send them a url they can use to grant admin consent to an enterprise application. Easy? Maybe.

https://login.microsoftonline.com/[tenant_name_in_onmicrosoft.com-form]/oauth2/authorize?client_id=[appId]&response_type=code&redirect_uri=http://&nonce=1234&resource=https://graph.windows.net&prompt=admin_consent

This url should prompt the user, who should have global admin permissions, to grant admin consent on for the app.

Solution 5: Are you using Connect-PnPOnline when getting this error?

This is a pretty new one! Try this:

Connect-PnPOnline -PnPManagementShell -Url

If that didn’t help, you could also try enabling Legacy Auth Protocols (ask your admin for permission first!) – this article will tell you how:

Got this tip from these 2 GitHub issues – will update when there’s more information!:

Did none of these solutions work?

I’ve been resolving a lot of different authentication issues with Azure AD lately. Maybe something new has come up after writing this article – let me know in the comments!

mm
4.8 6 votes
Article Rating
Subscribe
Notify of
guest
47 Comments
most voted
newest oldest
Inline Feedbacks
View all comments