AADSTS650052 fix: app needs a service your tenant lacks

What does AADSTS650052 mean?

Microsoft’s description:

The app needs access to a service ("{name}") that your organization "{organization}" hasn’t subscribed to or enabled. Contact your IT Admin to review the configuration of your service subscriptions.

Microsoft gives this code no name. The “service” is an API the app wants permissions on: the resource. Microsoft’s consent troubleshooting article says it plainly: “This error means the resource doesn’t exist in your organization.”

“Doesn’t exist” means the resource has no service principal in your tenant. Microsoft explains that “A service principal must be created in each tenant where the application is used”. An API owned by Microsoft or by another company only becomes usable in your tenant once that object exists.

Users often see a different wording. In a Microsoft Q&A thread the message read “The app is trying to access a service ‘d42ffc93-…’(Microsoft Advertising API Service) that your organization ‘xxxxx’ lacks a service principal for.” That version names the service’s app ID, which is what an admin needs.

How it differs from 500011: both mean the resource has no service principal in the tenant, and Microsoft’s consent article puts them under the same troubleshooting step. Our reading: 650052 tends to show up while the app asks for consent, and 500011 when it asks for a token. The root cause can be the same, but Microsoft’s consent article gives different first steps: admin consent for 650052, and checking the resource identifier and tenant with the app owner for 500011. If the missing object is the client app rather than the API, see 700016.

Is it an attack?

Not by itself. Nothing is granted. The request stops because the API has no object in your tenant to grant anything on.

Pattern	Likely meaning
650052 when connecting a tool to Microsoft Advertising	The most common report. The Microsoft Advertising API Service has no service principal in the tenant. Users also report it in third-party connectors such as Fivetran.
650052 for an app built in-house or with Terraform	The app asks for a scope on a custom API that only exists in the developer’s tenant. Users report this; the HashiCorp thread has no confirmed cause.
650052 for many users of one app, all at first sign-in	No admin has set the app up yet. Every user hits the same gap.
650052 for an unknown app asking for unusual APIs	Worth a look before you fix anything. Our interpretation: an admin who “fixes” the error by granting consent also grants whatever else the app asks for.

The risk is in the fix, not in the error. Microsoft warns that granting admin consent “is a sensitive operation, potentially allowing the application’s publisher access to significant portions of your organization’s data”. Check what the app requests before you consent on everyone’s behalf.

How do I find it in my logs (KQL)?

Microsoft doesn’t document which sign-in table 650052 lands in. Check where it lands in your workspace:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "650052"
| summarize Rows = count(), Users = dcount(UserPrincipalName) by SourceTable

Which client apps hit it, for how many users, and the error text (which should name the missing service):

SigninLogs
| where TimeGenerated > ago(30d)
| where ResultType == "650052"
| summarize Rows = count(),
            Users = dcount(UserPrincipalName),
            Resources = make_set(ResourceDisplayName, 5),
            Messages = make_set(ResultDescription, 3),
            FirstSeen = min(TimeGenerated)
          by AppId, AppDisplayName
| sort by Users desc

Whether ResourceDisplayName is filled for a resource that has no service principal isn’t documented. If it is empty, read the service name and ID from ResultDescription or from the message the user saw. ResultType is a string column, so compare it with "650052".

How do I fix AADSTS650052?

For the user: you can’t fix this yourself. Send your IT team the app name, and the service name and ID from the error message.

For developers: check which APIs your app’s registration requests. If you request a scope on your own API, that API needs a service principal in the customer’s tenant too, created by consent or by their admin. Tell customers which app IDs they need. Ask only for the APIs you actually call.

For admins:

1. Read the service’s app ID from the error. Check under Enterprise applications that it really is missing.
2. Decide whether you want the app to have this access. Review the permissions the app requests.
3. Create the missing service principal. Microsoft’s steps (Cloud Application Administrator or Application Administrator):

   Connect-MgGraph -Scopes "Application.ReadWrite.All"
   New-MgServicePrincipal -AppId <app ID from the error>

   The Azure CLI equivalent is az ad sp create --id <app ID>.
4. Or grant admin consent. Microsoft’s consent article gives an admin consent URL for this error. Microsoft’s article gives it as https://login.microsoftonline.com/<Tenant-ID>/oauth2/authorize?response_type=code&client_id=<App-URI-ID>&prompt=admin_consent, where client_id is the resource the app is trying to reach, not your own app. Microsoft also says that “Granting tenant-wide admin consent to the application adds it to your tenant.”
5. For Microsoft Advertising, an answer in the Microsoft Q&A thread suggests making sure at least one admin of your tenant is added to Microsoft Advertising and enabled for work accounts. One commenter suggests New-MgServicePrincipal -AppId "d42ffc93-c136-491d-b4fd-6f18168c68fd"; nobody in the thread confirms either worked. Fivetran’s knowledge base instead grants admin consent to the Microsoft Advertising app in the portal. Microsoft Learn doesn’t document a fix for Microsoft Advertising specifically.