Troubleshooting Primary Refresh Token failures on Hybrid Entra Joined devices

This post covers why AzureAdPrt : NO appears in dsregcmd /status on Hybrid Entra Joined machines, what causes it, and how to fix it. The focus is on enterprise deployments running Windows 10 21H1 and later or Windows 11.

What the PRT is and why it matters

The Primary Refresh Token (PRT) is a device-bound credential issued by Entra ID during Windows sign-in. It is used by the Web Account Manager (WAM) broker to silently obtain access tokens for Microsoft applications without prompting the user again. Without a valid PRT, Single Sign-On fails and Conditional Access policies that require a compliant or registered device will block access.

The PRT is not a simple session token. It is cryptographically bound to the device at issuance time. During registration, the dsreg component generates two key pairs. The private keys are stored in the TPM. Entra ID receives the public keys and uses them to validate subsequent PRT requests. If the TPM state changes after issuance, the PRT becomes invalid because Windows can no longer prove possession of the private keys.

Sources: Understanding PRT  ·  Token Protection

Because the PRT carries both user and device claims, Conditional Access can evaluate device state as part of the authentication decision. A device can appear compliant in Intune and still be blocked by Conditional Access if the PRT is missing or invalid. Intune compliance status alone does not satisfy CA policy requirements.

Root causes

Sync race condition

Entra Connect runs delta sync every 30 minutes by default. If a user logs in before the domain join is reflected in Entra ID, the Token Broker requests a PRT and Entra ID has no matching device object. No PRT is issued. The login succeeds with no visible error. The failure shows up later when the user hits a Conditional Access protected resource.

Source:  Entra Connect Scheduler

To force an immediate sync, run this on the Entra Connect server:

Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Delta
Get-ADSyncConnectorRunStatus

After sync completes, trigger the device registration task from Task Scheduler or run the re-registration steps in the remediation section below.

UPN mismatch

Entra ID correlates on-premises and cloud identities using the User Principal Name. If the on-premises UPN suffix is a non-routable domain (for example contoso.local) and the cloud UPN is contoso.com, the authentication bridge fails unless Alternate Login ID is configured end to end across Entra Connect, pass-through auth or ADFS rules, and any Conditional Access policies that reference user attributes.

Verify by comparing the on-premises UPN against what Entra ID shows:

Get-ADUser -Identity jsmith -Properties UserPrincipalName

The values must match exactly. If they do not, either update the on-premises UPN suffix to a routable domain or configure Alternate Login ID through Entra Connect.

TPM state change

Any of the following will invalidate the PRT binding without triggering a visible re-registration prompt: a BIOS or firmware reset that clears the TPM, a TPM ownership reset in tpm.msc, a motherboard replacement, or a failed Windows Update that touches Secure Boot key management. Windows detects the failure and should initiate a recovery flow. On Hybrid Joined devices this recovery is silent. If it does not complete, the device remains in a broken state.

Source:  PRT and TPM recovery

Check TPM health before attempting any re-registration:

Get-Tpm | Select-Object TpmPresent, TpmReady, TpmEnabled, LockedOut

If TpmReady is false, resolve the TPM issue first. Re-registering with a broken TPM will not produce a valid PRT.

Diagnosing the failure

dsregcmd fields to check

On Windows 10 21H1 and later you can get the error code directly from the command output. Look for the AcquirePrtDiagnostics and Attempt Status fields under the SSO State section. These show the HRESULT or AADSTS code from the last failed attempt without requiring Event Viewer.

Source:  Troubleshoot Hybrid Join

Event Viewer

Navigate to the following path in Event Viewer:

Applications and Services Logs
  Microsoft
    Windows
      User Device Registration
        Admin

For deeper tracing, also check the AAD Operational logs at:

Applications and Services Logs
  Microsoft
    Windows
      AAD
        Operational

Event ID 1006 marks the start of a PRT acquisition attempt. Event ID 1007 marks the end. All events logged between those two IDs are part of that acquisition flow.

Source:  Troubleshoot PRT

AADSTS50076 in Event 305

AADSTS50076 means MFA was required but the authentication flow did not satisfy it. In a device registration context this typically happens when a Conditional Access policy targeting the Device Registration service or the Microsoft Intune Enrollment app requires MFA, but the machine-context sign-in used during the Automatic Device Join task cannot complete an interactive MFA challenge.

Check your Conditional Access policies for any policy that includes the Device Registration service or Intune Enrollment as a target app. Machine-context authentication during device registration cannot perform interactive MFA. Exclude the Device Registration service from MFA requirements, or use a named location or compliant device exemption to scope the policy correctly.

Sources:  AADSTS error codes

Network connectivity check

The Token Broker requires HTTPS access to these endpoints from the device, running in system context. Proxy SSL inspection on these URLs will break client certificate authentication and prevent PRT issuance.

Test-NetConnection -ComputerName login.microsoftonline.com -Port 443
Test-NetConnection -ComputerName device.login.microsoftonline.com -Port 443
Test-NetConnection -ComputerName enterpriseregistration.windows.net -Port 443

If your proxy intercepts TLS, exclude device.login.microsoftonline.com and enterpriseregistration.windows.net from inspection. This is a documented Microsoft requirement, not a workaround.

Source:  Configure Hybrid Join (proxy / TLS requirements)

Remediation steps

Work through these in order. Each step is less disruptive than the next.

Step 1: Trigger the registration task manually

Open Task Scheduler, navigate to Microsoft\Windows\Workplace Join, and run the Automatic Device Join task. Check Event IDs 304 or 307 within 60 seconds. This does not affect the user session and requires no reboot.

Step 2: Force Entra Connect delta sync

Use this when the device object has not yet appeared in Entra ID, or when a recent domain join has not synced.

Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Delta

Wait for the sync to complete, then re-run the registration task from Step 1.

Step 3: Full re-registration (requires reboot)

Use this when the device object is stale, the registration state is corrupted, or the previous steps produced no change.

1. Run as Administrator: dsregcmd /leave
2. Reboot the machine.
3. After reboot, verify TPM health: Get-Tpm | Select-Object TpmPresent, TpmReady, TpmEnabled
4. Force re-registration: dsregcmd /debug /join
5. Wait 5 minutes, then verify: dsregcmd /status

Do not skip the reboot between dsregcmd /leave and dsregcmd /debug /join. The leave command removes local registration state. The reboot clears any in-memory credential state tied to the previous registration. Skipping it can result in a failed re-join.

Source:  dsregcmd reset

PRT present but Conditional Access still blocks

AzureAdPrt : YES and KeySignTest : PASSED in dsregcmd does not guarantee that CA will accept the device. Three distinct issues can produce this state.

First, the PRT exists but the Token Broker cannot exchange it for an access token for the specific application. This is a PRT-to-access-token exchange failure, not a PRT issuance failure. They look identical from the user’s side.

Second, the device compliance state in Intune is stale. CA evaluates the last known compliance state. If the device has not checked in recently, CA may enforce the previous state.

Third, the PRT was issued without device health claims because TPM attestation was skipped during issuance. The PRT exists but it does not carry the claims that CA requires for device trust evaluation.

To identify which of these is the actual cause, use the Sign-in Diagnostic tool in the Entra admin portal. Go to Diagnose and Solve, then Sign-in Diagnostic. Paste the correlation ID from the failed sign-in log entry. The tool will identify whether the failure occurred at PRT issuance, token exchange, or CA policy evaluation.

Pre-deployment checklist

• On-premises UPN suffix matches cloud UPN in Entra ID
• Service Connection Point (SCP) is configured in AD or via Entra Connect
• Entra Connect delta sync interval is documented and monitored
• TPM 2.0 is present, enabled, and showing Ready in tpm.msc
• Proxy bypass rules include all required Microsoft auth endpoints
• TLS inspection is excluded for device.login.microsoftonline.com and enterpriseregistration.windows.net
• Automatic Device Join scheduled task is enabled via GPO
• CA policies targeting Device Registration service do not require interactive MFA
• Event ID 304 confirmed on at least one test machine after join