AADSTS500014 fix: resource service principal is disabled

What does AADSTS500014 mean?

Microsoft’s description:

InvalidResourceServicePrincipalDisabled: The service principal for resource ‘{identifier}’ is disabled. This indicates that a subscription within the tenant has lapsed, or that an administrator for this tenant has disabled the application’s service principal, preventing tokens from being issued for it. For more information, see Disable user sign-in for application.

The disabled object is the resource: the API the token is for, named in the error. The client app the user opened can be perfectly fine.

The switch is the enterprise application’s Enabled for users to sign-in? property. Microsoft describes what No does: “no users are able to sign in to the application, even if they’re assigned to it. Tokens aren’t issued for the application. This setting not only prevents users from signing in but also restricts service principals from accessing the application using application permissions.” In Microsoft Graph it is the service principal’s accountEnabled property.

How it differs from 7000112: both come from the same switch. Our reading: 7000112 is returned when the disabled app is the client being signed in to, and 500014 when it is the resource a token is requested for. Microsoft’s Exchange Online troubleshooting article shows 7000112 for a disabled Exchange Online service principal on the Microsoft 365 portal. Users report 500014 for the same disabled service principal when Exchange is the resource, for example in Outlook sync tools. Which code you get depends on the request; Microsoft doesn’t spell this out. Treat the split as a rough guide: in Microsoft’s own Exchange example, Exchange is arguably the resource, and it still shows 7000112.

How it differs from 500011: 500011 means the resource has no service principal in the tenant. 500014 means it has one and it is switched off.

Is it an attack?

The error itself is not. It is a block working. What matters is who disabled the resource, and whether it was a Microsoft service.

Pattern	Likely meaning
500014 for your own API, after someone disabled it	Working as intended. Clients can no longer get tokens for it.
500014 naming a Microsoft service (Exchange Online, a Microsoft app ID) for many users, or on the Azure portal	Someone disabled a Microsoft service principal in your tenant, or a subscription lapsed. Users report it for the Azure portal, with Microsoft Graph as the resource, and for Dynamics environments. Check the audit log first.
500014 for a Dynamics 365 environment URL with an active subscription	Users report this too. The environment’s service principal may be disabled; check its Enabled for users to sign-in? setting.
500014 after a licence or trial ended	Microsoft names a lapsed subscription as a cause.

A disabled Microsoft first-party service principal is worth a second look. Our reading, not a Microsoft statement: if nobody on your team disabled it on purpose, treat the account that did as suspect until you know, because switching off a core service is a quick way to cause a tenant-wide outage.

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

Microsoft doesn’t document which sign-in table 500014 lands in. A disabled resource blocks both user and app-only tokens, so it can appear in all three. Check where it lands:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(7d)
| where ResultType == "500014"
| summarize Rows = count(), Resources = dcount(ResourceIdentity) by SourceTable

Which resources are disabled, how many users and apps are hitting them, and since when:

union SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(7d)
| where ResultType == "500014"
| summarize Rows = count(),
            Users = dcount(UserPrincipalName),
            ClientApps = make_set(coalesce(AppDisplayName, ServicePrincipalName), 10),
            FirstSeen = min(TimeGenerated)
          by ResourceIdentity, ResourceDisplayName
| sort by Users desc

Who changed a service principal, and when. Microsoft’s audit log reference lists Update service principal in the ApplicationManagement category. Disabling an enterprise app is likely logged as that activity; Microsoft doesn’t say so:

AuditLogs
| where TimeGenerated > ago(30d)
| where Category == "ApplicationManagement"
| where OperationName == "Update service principal"
| mv-expand Target = TargetResources
| mv-expand Prop = Target.modifiedProperties
| where tostring(Prop.displayName) == "AccountEnabled"
| project TimeGenerated,
          App = tostring(Target.displayName),
          ServicePrincipalId = tostring(Target.id),
          OldValue = tostring(Prop.oldValue),
          NewValue = tostring(Prop.newValue),
          ByUser = tostring(InitiatedBy.user.userPrincipalName),
          ByApp = tostring(InitiatedBy.app.displayName)
| sort by TimeGenerated desc

The modified property name AccountEnabled is an assumption based on the Graph property, not checked against Microsoft documentation. If the query returns nothing, drop that line and read the modifiedProperties of the rows yourself. Non-interactive and service principal sign-in rows are aggregated, so row counts there are not request counts. ResultType is a string column, so compare it with "500014".

How does Conditional Access affect it?

• 500014 is not a Conditional Access block. A disabled resource gets no tokens, whatever your policies say.
• Don’t confuse it with 53003, which is a Conditional Access block. The fix and the owner are different.

How do I fix AADSTS500014?

For the user: you can’t fix this yourself. Tell your IT team which resource the error names.

For developers: if your API is the resource and a customer gets 500014, the customer’s admin disabled your API’s service principal in their tenant, or their subscription lapsed. You can’t re-enable it from your side.

For admins:

1. Read the resource from the error. Find it under Enterprise applications (remove the default filters and search by application ID).
2. Find out who disabled it and why with the audit log query, before changing anything. If it was disabled during an incident, leave it.
3. Check that the subscription behind the service is active. Microsoft names a lapsed subscription as the other cause.
4. If it was a mistake: in Enterprise applications > the app > Properties, set Enabled for users to sign-in? to Yes. In Microsoft Graph, set accountEnabled to true. Microsoft documents accountEnabled as “true if the service principal account is enabled”. With Microsoft Graph PowerShell:

   Connect-MgGraph -Scopes "Application.ReadWrite.All"
   $sp = Get-MgServicePrincipal -Filter "appId eq '<resource app ID>'"
   $sp.AccountEnabled
   Update-MgServicePrincipal -ServicePrincipalId $sp.Id -AccountEnabled:$true

   This mirrors Microsoft’s disable command with $true. Microsoft’s page shows only the disable direction.
5. For Exchange Online, the app ID is 00000002-0000-0ff1-ce00-000000000000. Microsoft’s article uses the deprecated MSOnline module for this; use Microsoft Graph PowerShell as above.
6. If the app registration was deactivated globally by its owner, that is a different switch (isDisabled). Microsoft notes that reactivating it “doesn’t enable tenant-local sign-in if a service principal’s accountEnabled remains false”. Check both.