AADSTS Errors in Power BI Scheduled Refresh: Causes and Fixes

When a Power BI scheduled refresh fails with an error code starting with AADSTS, the failure did not originate in Power BI. AADSTS is the Azure Active Directory (now Microsoft Entra ID) sign-in error namespace. The code is returned by Microsoft's identity platform when it rejects an authentication request — before Power BI even gets to query your data source.

This matters for diagnosis. The problem is not in your dataset, your Power Query logic, or your data source connectivity. The problem is in the authentication chain between Power BI Service, the credential it holds for your data source, and Azure AD. Every AADSTS error has a specific numeric code that tells you exactly what went wrong in that chain.

The eight codes below account for the large majority of authentication failures in scheduled refresh contexts. Each one has a distinct cause and a distinct fix.

AADSTS50126 (InvalidUserNameOrPassword) is the most straightforward: the credentials stored in Power BI Service for this data source are wrong. Either the password has changed since the credentials were last saved, or the username was entered incorrectly when the dataset was first configured.

In a scheduled refresh context, this almost always means a service account password was rotated without updating the stored credentials in Power BI. The refresh that ran successfully last week used the old password; the one that ran this morning used the same stored credentials after the password changed.

Fix: go to the dataset settings in Power BI Service, find the data source credentials section, and re-enter the credentials with the current password. If this keeps recurring, consider switching to a service account with a non-expiring password policy, or to an OAuth-based connection that doesn't rely on stored passwords.

AADSTS50076 (UserStrongAuthClientAuthNRequired) and AADSTS50079 (UserStrongAuthEnrollmentRequired) both indicate that the identity being used to authenticate requires multi-factor authentication — and a scheduled refresh cannot complete MFA because there is no interactive session to present a challenge.

ADADSTS50076 fires when the admin applied a Conditional Access policy requiring MFA after the Power BI connection was configured. AADSTS50079 fires when MFA enrollment is required but the account has never completed it. In both cases, the refresh cannot proceed interactively.

Fix: scheduled refreshes must authenticate non-interactively. The options are: (1) use a service principal with OAuth credentials instead of a user account — service principals are not subject to MFA policies applied to users; (2) configure a Conditional Access exclusion for the service account used by Power BI if your organization requires MFA for all user accounts; (3) switch to OAuth-based credentials using a service principal registered in Azure AD with the Power BI Service application granted the appropriate API permissions. Service principals are the long-term correct answer for any automated process.

AADSTS53003 (BlockedByConditionalAccess) is the most abrupt of the authentication errors: an Azure AD Conditional Access policy is explicitly blocking the token request from completing. Unlike MFA errors, there is no fallback — the policy does not allow token issuance, period.

Common triggers in Power BI refresh scenarios: a Conditional Access policy requiring compliant devices (Power BI Service is not a device); a policy restricting sign-ins to specific IP ranges (Power BI Service's IP addresses are not in the allowed range); a policy requiring app-enforced restrictions that Power BI does not support.

Fix: go to Azure AD Conditional Access policies and identify which policy is blocking the request. The sign-in log in Azure AD (Monitoring → Sign-in logs) shows the exact policy name that blocked the authentication. Options from there: create a policy exclusion for the service account used by Power BI; create a named location that includes Power BI Service IP addresses; or switch to a service principal — service principals can be explicitly excluded from user-targeted Conditional Access policies.

AADSTS65001 (DelegationDoesNotExist) means the Azure AD application that Power BI is using to authenticate has not been granted admin consent to access the requested resource. The application exists, the credentials are valid, but the delegated permission — the explicit grant to access a specific resource on behalf of a user — has not been approved by a tenant administrator.

This error often appears after an organization changes its Azure AD app consent policies, or when Power BI's OAuth connection is being configured for the first time with a new data source that requires admin-approved permissions (such as SharePoint Online or Dynamics 365).

Fix: a tenant administrator must grant admin consent for the required permissions. In Azure AD, go to the relevant app registration → API permissions and click "Grant admin consent for [tenant]." The permissions required depend on the data source: Power BI Service needs delegated access to the API of the target service. If using a service principal, the permission model switches to application permissions, which require their own admin consent.

AADSTS50055 (InvalidPasswordExpiredPassword) is distinct from AADSTS50126. The password isn't wrong — it's expired. Azure AD is rejecting the authentication because the account's password has reached its expiration date and must be reset before any new sessions can be created.

This error is common when organizations use regular user accounts (rather than service principals) to authenticate Power BI data sources. Standard user accounts are subject to password expiration policies. When the password expires, every scheduled refresh using that account fails simultaneously, across all datasets configured with those credentials.

Fix: reset the password for the service account and update the stored credentials in every Power BI dataset that uses it. This is a recoverable incident, but if the account authenticates many datasets, the re-credentialing process takes time. The root fix is to switch to a service principal — service principals do not have password expiration — or to configure the service account with a non-expiring password policy if your organization's security policy allows it.

AADSTS50034 (UserAccountNotFound) means the user account referenced in the credential does not exist in the Azure AD tenant that Power BI is authenticating against. This is different from a wrong password — the account itself cannot be found.

Typical causes in scheduled refresh scenarios: the service account was deleted from Azure AD (or disabled); the username in the stored credentials contains a typo or references an old domain that no longer exists; the account was in an external or guest tenant that has since revoked access.

Fix: verify that the service account still exists and is active in Azure AD. If it was deleted, restore it from the Azure AD recycle bin (accounts are recoverable for 30 days after deletion) or create a replacement account and re-enter credentials across all affected datasets. If the account was in a guest tenant, recheck the cross-tenant access configuration.

AADSTS70011 (InvalidScope) fires when the OAuth scope requested during the authentication flow is malformed or not recognized by Azure AD for the target resource. The access token cannot be issued because the resource definition in the request is invalid.

In Power BI contexts, this surfaces when a custom data connector or a manually-configured OAuth connection requests a scope that does not match the Azure AD app registration's configured API permissions, or when the resource URI is wrong (pointing to the wrong environment — for example, a government cloud resource URI used in a commercial tenant).

Fix: review the Azure AD app registration for the application being used. Under API permissions, verify that the scopes configured match exactly what the Power BI connection is requesting. For built-in Power BI connectors, this error can also appear after a tenant change or app registration update — re-registering the OAuth connection from scratch in Power BI Desktop and republishing often resolves it.

Power BI Service shows refresh failures with a generic error message that often buries the AADSTS code three clicks deep in the refresh history. By the time you've navigated to the specific run, opened the error detail, and decoded the error code, five minutes have passed and you haven't started the fix yet.

MetricSign captures the full error detail — including the AADSTS code — at the moment of failure and surfaces it directly in the incident. Instead of "Scheduled refresh failed for Sales Overview," the incident reads "Sales Overview refresh failed: AADSTS53003 — Blocked by Conditional Access." The engineer on call knows where to look before opening a second browser tab.