Entra ID authentication errors for Dynamics 365

Every Dynamics 365 sign-in and every service-to-service integration authenticates through Microsoft Entra ID, so an authentication failure almost never originates in the Dynamics 365 app itself — it's Entra rejecting the sign-in or token request, and the app is just the messenger. The error codes are prefixed AADSTS followed by a number; that number, not the surrounding sentence, is what to search or quote when asking for help, since Microsoft occasionally reworks the wording around the same code.

"AADSTS50126: Invalid username or password"

Symptom. A user's sign-in to any Dynamics 365 app fails at the Microsoft sign-in page, before Dynamics 365 itself ever loads.

Cause. The credentials entered don't match the account, or the account uses a different authentication method (federated sign-in, passwordless) than the password box implies.

Fix. Verify the username is the actual UPN registered in Entra (not a display name or an email alias that isn't the primary UPN), and use "Forgot password" if genuinely locked out. For federated tenants, confirm the identity provider redirect is working.

Prevention. Communicate the exact sign-in UPN format to new users at onboarding; a mismatch between "the email everyone uses" and "the UPN Entra actually expects" is a common source of repeated lockout tickets.

"AADSTS50034: The user account does not exist in the directory"

Symptom. Sign-in fails immediately with no password prompt, or fails right after entering a username.

Cause. The account genuinely doesn't exist in this tenant's Entra directory — often because the user is trying to sign in with a personal Microsoft account, a different organisation's work account, or a mistyped domain.

Fix. Confirm the correct tenant domain and that an Entra account (and Dynamics 365 licence) actually exists for that person. Create or invite the account if it's missing.

Prevention. For guest/external users, use a deliberate B2B invitation flow rather than assuming an external email automatically has access.

"AADSTS700016: Application not found in the directory" / "AADSTS650057: Invalid resource"

Symptom. A service-to-service integration (a custom connector, a background job, an Azure Function calling Dataverse or Business Central) fails to authenticate, while interactive user sign-in works fine.

Cause. The app registration's client ID is wrong, belongs to a different tenant, or was deleted; or the resource/scope the code is requesting a token for doesn't match what's actually exposed (a common mismatch after a Dataverse environment URL or a Business Central API scope changes).

Fix. Re-check the client ID, tenant ID, and requested scope against the actual app registration in the Entra admin center; regenerate the client secret if it may have expired or been rotated without updating the integration's configuration.

Prevention. Store app registration IDs and secrets in a secrets manager (Key Vault, GitHub Secrets) referenced by name rather than hard-coded, and set a calendar reminder well ahead of client-secret expiry — a lapsed secret fails every dependent integration at once, usually discovered at the worst moment.

"AADSTS53003: Access has been blocked by Conditional Access policies"

Symptom. A sign-in that used to work suddenly fails with a Conditional Access block, often after a device, location, or network change.

Cause. A Conditional Access policy — requiring MFA, a compliant device, or a specific network location — is evaluating this sign-in attempt as non-compliant. This is the policy working as designed, not a bug.

Fix. The user needs to satisfy the policy (register the device as compliant, complete MFA, connect from an approved network) or a tenant admin needs to review whether the policy is unintentionally blocking a legitimate scenario (a new office location, a new integration's IP range).

Prevention. When rolling out a new Conditional Access policy, stage it in report-only mode first and review the sign-in logs for who it would have blocked before enforcing it — this catches unintended blast radius (an integration's service account, a partner's office IP range) before it causes an outage.

Where to go next

The tenant-wide identity layer these errors sit under is covered in Dynamics 365 and Conditional Access and Dynamics 365 data protection and compliance. For the app-registration side of service-to-service authentication specifically, see Entra External ID for customer access and B2C authentication with Dynamics 365. A user who authenticates fine but then can't see or edit the record they expect is a different problem — Dataverse sharing and security errors decodes that class of failure.