Skip to main content
Azure Active Directory (Azure AD) — now rebranded as Microsoft Entra ID — is the identity and access management backbone for Microsoft 365, Azure resources, and thousands of integrated third-party applications. When sign-in fails, Azure AD returns a structured error code known as an AADSTS code, which pinpoints the exact category of failure. Understanding these codes, combined with knowledge of Conditional Access policies and device join states, allows you to resolve the vast majority of sign-in issues quickly and without guessing.

​
Understanding AADSTS Error Codes

AADSTS error codes appear on the Microsoft sign-in error page and in Azure AD sign-in logs. Each code maps to a specific failure category. The three most common codes you will encounter are described below.
Meaning: The username or password provided is incorrect. This is the most common sign-in error and typically indicates a straightforward credential failure.Common causes:
  • User entered the wrong password
  • The account’s password was recently changed and the user has not updated cached credentials
  • Caps Lock is enabled
  • The account is configured with a different UPN than the user expects (e.g., [email protected] vs. [email protected])
Resolution steps:
  1. Ask the user to verify their username (UPN) at https://login.microsoftonline.com.
  2. Initiate a self-service password reset (SSPR) at https://aka.ms/sspr if the user has forgotten their password.
  3. If SSPR is not enabled, reset the password from the Microsoft 365 admin centre → Users → Active Users → Reset password.
  4. Clear cached credentials in Credential Manager (Windows) or Keychain Access (macOS).
  5. If failures continue after a password reset, check that the account is not locked in Azure AD → Users → [User] → Sign-in logs — look for repeated AADSTS50126 entries that could trigger a smart lockout.
Meaning: The user account does not exist in the target tenant in the expected form. This error commonly occurs when:
  • A user from an external organisation (a “guest” user) tries to sign in to a tenant they have not been invited to
  • A personal Microsoft account (MSA) is being used to access a tenant that only accepts work/school accounts
  • The invited guest user has not yet accepted their invitation
Resolution steps:
  1. Verify whether the user is an internal user or an external guest. In Azure AD → Users, check the User type column (Member vs. Guest).
  2. If the user should be a guest, send a new B2B invitation via Azure AD → Users → New guest user with the correct external email address.
  3. Ask the external user to check their email inbox for the invitation and accept it before attempting to sign in.
  4. If the user is internal but receiving this error, verify their account is in the correct tenant and is not a duplicate or shadow account.
  5. Check whether the user is attempting to use a personal Microsoft account. If the tenant is configured to block personal accounts, the user must use their work/school account exclusively.
Meaning: The application the user is attempting to sign in to is not registered or consented to in the target tenant. This error appears when accessing a third-party SaaS app, a custom-built application, or a Microsoft application that requires explicit provisioning.Resolution steps:
  1. In the Azure AD admin centre (https://aad.portal.azure.com), navigate to Enterprise Applications and search for the application by name or application ID.
  2. If the application is not listed, it has not been added to the tenant. Add it via Enterprise Applications → New Application and search the gallery, or add a custom application.
  3. If the application is listed but users cannot sign in, check the Properties blade: ensure Enabled for users to sign in is set to Yes.
  4. Review User and group assignments — if Assignment required is enabled, the user or a group they belong to must be explicitly assigned to the application.
  5. For first-party Microsoft applications, the service principal may need to be re-created. Contact Microsoft Support if this is suspected.

​
Reviewing Azure AD Sign-In Logs

Sign-in logs are your primary diagnostic tool for any Azure AD authentication failure.
1

Open the Sign-in logs

In the Azure AD admin centre (https://aad.portal.azure.com), navigate to Monitoring → Sign-in logs (under Azure Active Directory).
2

Filter by user and time range

Apply filters for the affected user’s UPN and narrow the time range to when the failures occurred. Failed sign-ins display a red Failure status.
3

Read the error details

Click a failed sign-in entry to open the Activity Details panel. Review:
  • Error code: The AADSTS code
  • Failure reason: Plain-language description
  • Conditional Access: Whether a CA policy applied or blocked the sign-in
  • Device: The device ID and join state at time of sign-in
4

Note the Correlation ID

Copy the Correlation ID from the sign-in details. This ID uniquely identifies the sign-in request and is required when opening a Microsoft support ticket.
Sign-in logs are retained for 30 days on Azure AD Free/P1 and 90 days on P2. Export logs to Azure Monitor, a Storage Account, or Event Hub if you need longer retention.

​
Checking Conditional Access Policies

Conditional Access (CA) policies can block or restrict sign-in based on user, device, location, application, or risk signal. A blocked sign-in due to CA does not always produce a user-facing error — sometimes it silently fails or prompts the user to take an action (like enrolling a device) that they cannot complete.
1

Navigate to Conditional Access

In the Azure AD admin centre, go to Security → Conditional Access → Policies. Review the list of enabled policies.
2

Use the What If tool

Click What If at the top of the Conditional Access page. Enter:
  • The affected user’s account
  • The target application
  • The device platform and compliance state
  • The sign-in risk level
Click What If to see which policies would apply and what the outcome would be. This is the fastest way to determine if a CA policy is responsible for the sign-in failure.
3

Review individual policy conditions

For any policy shown as Grant with controls or Block, open the policy and check each condition:
  • Users/Groups: Is the user included or excluded?
  • Cloud apps: Does the policy apply to the application the user is trying to access?
  • Conditions: Check device compliance, device join state, location (named locations/trusted IPs), and sign-in risk.
  • Grant controls: What is required? (MFA, compliant device, hybrid join, approved client app)
4

Temporarily exclude the user for testing

If you suspect a CA policy is causing the block, add the user to the Exclude list of the suspected policy temporarily to confirm. Remember to remove the exclusion after testing.
Excluding users from Conditional Access policies reduces security. Only do this for testing, in a change-controlled manner, and for the minimum time required.

​
Re-Joining a Device to Azure AD

If a device’s Azure AD trust relationship has broken — often after a reimaging, time sync failure, or Azure AD certificate expiry — users on that device may be unable to sign in even with correct credentials. Re-joining the device to Azure AD resolves this.

​
Step 1: Check Current Device Join State

1

Run dsregcmd /status

Open a Command Prompt as the affected user (not elevated) on the affected device and run:
Review the output under the Device State section:
Key fields to check:
  • AzureAdJoined: YES — Device is Azure AD joined
  • AzureAdJoined: NO — Device is not currently joined (needs to be joined)
  • WorkplaceJoined: YES — Device is registered only (not a full Azure AD join)
  • DomainJoined: YES alongside AzureAdJoined: YES — Device is hybrid-joined
Run dsregcmd /status as the signed-in domain user, not from an elevated prompt. User-state fields such as AzureAdPrt only populate in the user context. Running it elevated will show those fields as blank, which can mislead troubleshooting.
2

Check the SSO and token state

Still within dsregcmd /status, scroll to the User State and SSO State sections. Look for:
  • AzureAdPrt: YES — Primary Refresh Token is valid (sign-in should work)
  • AzureAdPrt: NO — PRT is missing or expired; re-join may be required

​
Step 2: Leave and Re-Join Azure AD

Leaving Azure AD removes the device’s Azure AD trust relationship. Ensure the user’s data (Desktop, Documents, etc.) is backed up or synced to OneDrive or SharePoint before proceeding. Local accounts may also be required to complete the re-join.
1

Leave Azure AD

Run the following command in an elevated Command Prompt to leave Azure AD:
You will see a confirmation message. Restart the device.
2

Re-join Azure AD — Self-Service

After the restart, if the device is in a Work or School account setup (not Autopilot or MDM-provisioned), sign in with a local administrator account and go to:Settings → Accounts → Access work or school → ConnectEnter the user’s Azure AD credentials and follow the prompts to re-join.
3

Re-join Azure AD — Via Autopilot or MDM (enterprise)

In enterprise environments using Intune/Autopilot, re-join by wiping the device and running through the Out-of-Box Experience (OOBE) again. Contact your Intune administrator to trigger a Wipe from the Intune portal if needed.
4

Verify the new join state

After re-joining and signing in, run dsregcmd /status again and confirm:
  • AzureAdJoined: YES
  • AzureAdPrt: YES

​
Escalation

Microsoft Entra ID Support

Open a support ticket at https://admin.microsoft.com → Support → New service request. Select Azure Active Directory / Microsoft Entra ID as the product. Provide the Correlation ID from the sign-in logs.

Azure AD Sign-In Logs Export

Export the sign-in logs for the affected user via Azure AD → Sign-in logs → Export → Download CSV or stream them to Azure Monitor for longer retention before the 30-day log expiry.

Microsoft Entra Diagnostic Tool

Use the built-in diagnostic at https://entra.microsoft.com → Diagnose & solve problems to run automated checks for sign-in failures, CA policy issues, and MFA registration problems.

Collect dsregcmd Output

When escalating device join issues, attach the full output of dsregcmd /status to the ticket. Redact the device certificate thumbprint and any sensitive token values before sharing.