> ## Documentation Index
> Fetch the complete documentation index at: https://docs.derekdinh.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Troubleshooting Azure AD and Entra ID Sign-In Issues

> Diagnose Azure AD and Entra ID sign-in errors including AADSTS codes, conditional access blocks, device join status, and re-join procedures.

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.

<Accordion title="AADSTS50126 — Invalid Username or Password">
  **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., `user@company.onmicrosoft.com` vs. `user@company.com`)

  **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.
</Accordion>

<Accordion title="AADSTS50020 — Guest Account / Tenant Mismatch">
  **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.
</Accordion>

<Accordion title="AADSTS700016 — Application Not Found in Tenant">
  **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.
</Accordion>

***

## Reviewing Azure AD Sign-In Logs

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

<Steps>
  <Step title="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**).
  </Step>

  <Step title="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.
  </Step>

  <Step title="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
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Tip>
  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.
</Tip>

***

## 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.

<Steps>
  <Step title="Navigate to Conditional Access">
    In the Azure AD admin centre, go to **Security → Conditional Access → Policies**. Review the list of enabled policies.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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)
  </Step>

  <Step title="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.**

    <Warning>
      Excluding users from Conditional Access policies reduces security. Only do this for testing, in a change-controlled manner, and for the minimum time required.
    </Warning>
  </Step>
</Steps>

***

## 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

<Steps>
  <Step title="Run dsregcmd /status">
    Open a Command Prompt **as the affected user** (not elevated) on the affected device and run:

    ```cmd theme={null}
    dsregcmd /status
    ```

    Review the output under the **Device State** section:

    ```text theme={null}
    +----------------------------------------------------------------------+
    | Device State                                                         |
    +----------------------------------------------------------------------+

             AzureAdJoined : YES
          EnterpriseJoined : NO
              DomainJoined : NO
    ```

    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

    <Note>
      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.
    </Note>
  </Step>

  <Step title="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

    ```cmd theme={null}
    dsregcmd /status | findstr /i "AzureAdJoined AzureAdPrt DomainJoined"
    ```
  </Step>
</Steps>

### Step 2: Leave and Re-Join Azure AD

<Warning>
  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.
</Warning>

<Steps>
  <Step title="Leave Azure AD">
    Run the following command in an **elevated Command Prompt** to leave Azure AD:

    ```cmd theme={null}
    dsregcmd /leave
    ```

    You will see a confirmation message. Restart the device.
  </Step>

  <Step title="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 → Connect**

    Enter the user's Azure AD credentials and follow the prompts to re-join.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Verify the new join state">
    After re-joining and signing in, run `dsregcmd /status` again and confirm:

    * `AzureAdJoined: YES`
    * `AzureAdPrt: YES`
  </Step>
</Steps>

***

## Escalation

<CardGroup cols={2}>
  <Card title="Microsoft Entra ID Support" icon="headset">
    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.
  </Card>

  <Card title="Azure AD Sign-In Logs Export" icon="file-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.
  </Card>

  <Card title="Microsoft Entra Diagnostic Tool" icon="stethoscope">
    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.
  </Card>

  <Card title="Collect dsregcmd Output" icon="terminal">
    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.
  </Card>
</CardGroup>