Azure AD Login error

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

Fixing issues with Azure AD authentication for Enterprise applications can be tricky. This article contains multiple different fixes to an 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: resource: 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?


Okay, there’s a bunch of solutions, starting from easy and progressing to more difficult and exotic ones.

Please note: if you have an issue, where only admin users are able to log in, 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:

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!

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 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.[]/oauth2/authorize?client_id=[appId]&response_type=code&redirect_uri=http://&nonce=1234&resource=

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

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!

The following two tabs change content below.

Antti K. Koskela

Solutions Architect / Escalations Engineer at Koskila / Norppandalotti Software / Valo Solutions
Antti Koskela is a proud digital native nomadic millenial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as a Solutions Architect for Valo Intranet, the product that will make you fall in love with your intranet. Working with the global partner network, he's responsible for the success of Valo deployments happening all around the world. He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff. This is his personal professional (e.g. professional, but definitely personal) blog.

Let me know your thoughts!