The ticket usually reads "Outlook keeps asking for my password" or "Conditional Access says my device isn't compliant, but Intune says it is." You run dsregcmd /status on the laptop, and in the SSO State section it says:
AzureAdPrt : NO
That line explains a lot of strange symptoms. Without a primary refresh token (PRT), Windows can't do single sign-on to Microsoft 365, and it can't prove the device's identity to Entra ID. So apps prompt for a password, and Conditional Access policies that require a compliant or hybrid joined device fail even when the device itself is fine.
The good news is that Windows usually tells you why the PRT is missing, if you know where to look. This post goes through that in order. Every step is read-only until the very end, where we talk about when a re-registration is really needed.
TL;DR
- Run
dsregcmd /statusas the affected user, in a normal (not elevated) prompt. The SSO State section is per-user. - First check the Device State:
AzureAdJoinedmust beYES, andDeviceAuthStatusshould beSUCCESS. If not, you have a device registration problem, not a token problem. - Under
AzureAdPrt : NO, read Attempt Status (the client error) and Server Error Description (theAADSTScode). Together they point at the cause in most cases. - The usual causes are: a deleted or disabled device object, the user not synced or a UPN mismatch, a recent password change that hasn't synced yet (hybrid with password hash sync), and a proxy or network block.
-
AzureAdPrt : YESbut CA still fails? Check the browser and the sign-in log's device details before you touch the device.
What is the primary refresh token, briefly?
The PRT is a token that Windows gets from Entra ID when a user signs in to an Entra joined or hybrid joined device. It's bound to the device, and Windows uses it to get access tokens for apps without asking for the password again. It also carries the device's identity, which is what Conditional Access checks for "require compliant device" and "require Microsoft Entra hybrid joined device."
Three things follow from that:
- No device registration, no PRT. The device has to be Entra joined or hybrid joined, and the device object has to exist and be enabled in Entra ID.
- No valid user, no PRT. The signed-in user has to exist in Entra ID (synced, for hybrid), with a UPN Entra ID can find.
-
No route to Entra ID, no PRT. Windows has to reach
login.microsoftonline.com, through your proxy if you have one.
Most AzureAdPrt : NO cases fail one of those three. The steps below check them in that order.
Step 1: Run dsregcmd the right way
Sign in as the user who has the problem, open a normal Command Prompt or PowerShell window, and run:
dsregcmd /status
Two details that trip people up:
-
Run it as the user. The SSO State section shows the PRT for the account that ran the command. If you run it from an elevated prompt as a separate admin account, you're looking at the admin's token, not the user's. Microsoft also notes that
WamDefaultSetcan show an error from an elevated prompt. -
Times are in UTC.
AzureAdPrtUpdateTimeandPrevious Prt Attemptare UTC, so convert before you compare them with when the user says the problem started.
On Windows 10 21H1 and later, failed attempts show diagnostic fields right under AzureAdPrt. Older builds don't show them, so you have to use Event Viewer (Step 4).
Step 2: Check the Device State before the token
Scroll up to the Device State and Device Details sections. If these are wrong, there's no point chasing the PRT yet.
| Field | What you want | If it's wrong |
|---|---|---|
AzureAdJoined |
YES |
The device isn't Entra joined or hybrid joined, so no PRT can exist. For a domain-joined device, this is a hybrid join problem. Look at the Previous Registration section under Diagnostic Data. |
DomainJoined |
YES for hybrid, NO for cloud-only Entra join |
Tells you which join type you're troubleshooting. |
DeviceAuthStatus |
SUCCESS |
FAILED. Device is either disabled or deleted means the device object in Entra ID is gone or disabled. FAILED. ERROR means the test couldn't reach Entra ID, which points at the network. |
TpmProtected |
Usually YES on modern hardware |
NO isn't automatically a problem, but note it if you later see key errors. |
If DeviceAuthStatus shows the device is disabled or deleted, you've probably found your answer already. A stale-device cleanup, a script, or an admin removed the object while the laptop was still in use. The server side of the same problem shows up as AADSTS50155: Device authentication failed.
Step 3: Read Attempt Status and the AADSTS code
Back in the SSO State section, a failed PRT looks like this (trimmed):
AzureAdPrt : NO
AcquirePrtDiagnostics : PRESENT
Previous Prt Attempt : 2026-10-13 14:20:09.760 UTC
Attempt Status : 0xc000006d
User Identity : user@contoso.com
Credential Type : Password
HTTP status : 400
Server Error Code : invalid_grant
Server Error Description : AADSTS50126: Error validating credentials due to invalid username or password.
Attempt Status is the client-side HRESULT. Server Error Description is what Entra ID sent back. Read both. The client code often just says "the server said no," and the AADSTS code says why.
One caveat from Microsoft's documentation: the diagnostics only appear if the failure happened after the last successful PRT update. On a shared device, the last attempt might also belong to a different user, so check User Identity.
Here are the codes I'd expect to see most, with what they usually mean. The causes and fixes come from Microsoft's PRT troubleshooting guide.
| You see | Usually means | What to check (read-only first) |
|---|---|---|
AADSTS50155 Device authentication failed |
The device object was deleted or disabled in Entra ID | Find the device by DeviceId in Entra ID (script below). If it's gone or disabled, the fix is re-registration. |
AADSTS50034 user account does not exist |
Entra ID can't find the user | Is the user synced? Does the UPN Windows sent match the Entra UPN? Run whoami /upn on hybrid devices. |
AADSTS50126 invalid username or password, on a hybrid device |
Often a recent password change that password hash sync hasn't delivered yet | Check when the password changed and when Entra Connect last synced. Once sync has run, lock and unlock to get a fresh PRT. |
0xc000006d / 0xc000006a / 0xc00000d0
|
The server returned an error (often HTTP 400) | Not the root cause on its own. Read the AADSTS line or Event ID 1081 (or 1088 for federated WS-Trust). |
0xc000005f STATUS_NO_SUCH_LOGON_SESSION |
Realm discovery failed: Entra ID doesn't know the user's domain | Is the UPN suffix a verified custom domain? A .local UPN won't work without Alternate Login ID. |
0xc004844c USERNAME_IS_MALFORMED |
The UPN isn't in internet (user@domain) format |
whoami /upn on hybrid devices; check what the domain controller returns. |
0xc000023c, 0xc00000be, 0xc00000c4, or WinHTTP 12002 / 12007 / 12029 / 12030
|
Network: timeout, name not resolved, can't connect | Proxy and firewall. On hybrid devices, the computer account must be able to find and silently authenticate to the outbound proxy. |
0xc0048442, 0xc00484c1, 0xc004848b, 0xc004848c
|
Something in the path changed or broke the response: proxy inspection, or federation (MEX) config | Check for TLS inspection of Microsoft sign-in endpoints, and the federation server's MEX configuration. |
When AzureAdPrt is YES but the token is stale
AzureAdPrt : YES doesn't always mean healthy. Microsoft's guidance is that if AzureAdPrtUpdateTime is more than four hours old, something is likely stopping the refresh. Lock and unlock the device (that triggers a refresh), run dsregcmd /status again, and see whether the time moves. If it doesn't, look for RefreshPrtDiagnostics and treat it like the table above.
Step 4: Use the AAD event logs when dsregcmd isn't enough
On older builds, or when the AADSTS line is blank, the details are in Event Viewer under Applications and Services Logs > Microsoft > Windows > AAD.
- Operational has the errors. Event ID 1081 holds the Entra ID server error and description. 1088 holds the WS-Trust (federated) error. 1084 holds the network sub-error.
- Analytic is hidden by default (View > Show Analytic and Debug Logs). Event IDs 1006 and 1007 mark the start and end of a PRT attempt. 1022 shows the URL being called, and 1144 shows the UPN Windows used.
A read-only way to pull the recent errors without clicking through Event Viewer:
# Read-only: last 20 errors/warnings from the AAD Operational log
Get-WinEvent -LogName 'Microsoft-Windows-AAD/Operational' -MaxEvents 200 |
Where-Object { $_.LevelDisplayName -in 'Error','Warning' } |
Select-Object -First 20 TimeCreated, Id, LevelDisplayName,
@{ n = 'Message'; e = { ($_.Message -split "`r?`n" | Select-Object -First 6) -join ' ' } } |
Format-List
A read-only PRT snapshot script
This turns dsregcmd /status into one object with the fields that matter, plus a couple of plain-English flags. It only reads. It doesn't join, leave or change anything. Run it as the affected user in a normal PowerShell window.
# Read-only. Parses dsregcmd /status for the current user.
$raw = dsregcmd /status
$f = @{}
foreach ($line in $raw) {
if ($line -match '^\s*([A-Za-z][A-Za-z0-9 ]*?)\s*:\s(.*)$') {
$key = $Matches[1].Trim()
# Keep the first value: AzureAd fields are listed before Enterprise fields
if (-not $f.ContainsKey($key)) { $f[$key] = $Matches[2].Trim() }
}
}
$prtAgeHours = $null
if ($f['AzureAdPrtUpdateTime']) {
try {
$t = [datetime]::ParseExact(($f['AzureAdPrtUpdateTime'] -replace ' UTC$',''),
'yyyy-MM-dd HH:mm:ss.fff', [Globalization.CultureInfo]::InvariantCulture)
$prtAgeHours = [math]::Round(((Get-Date).ToUniversalTime() - $t).TotalHours, 1)
} catch { }
}
$joinType = switch ("$($f['AzureAdJoined'])/$($f['DomainJoined'])") {
'YES/YES' { 'Hybrid joined' }
'YES/NO' { 'Entra joined' }
'NO/YES' { 'Domain only (not hybrid joined)' }
default { 'Not joined / unknown' }
}
$flags = @()
if ($f['AzureAdJoined'] -ne 'YES') { $flags += 'Not Entra/hybrid joined: fix registration first' }
if ($f['DeviceAuthStatus'] -and
$f['DeviceAuthStatus'] -ne 'SUCCESS') { $flags += "DeviceAuthStatus: $($f['DeviceAuthStatus'])" }
if ($f['AzureAdPrt'] -eq 'NO') { $flags += 'No PRT: read AttemptStatus and ServerError' }
if ($prtAgeHours -gt 4) { $flags += "PRT last refreshed $prtAgeHours h ago: lock/unlock and recheck" }
[pscustomobject]@{
User = "$env:USERDOMAIN\$env:USERNAME"
JoinType = $joinType
DeviceId = $f['DeviceId']
TenantName = $f['TenantName']
DeviceAuthStatus = $f['DeviceAuthStatus']
AzureAdPrt = $f['AzureAdPrt']
PrtUpdateTimeUtc = $f['AzureAdPrtUpdateTime']
PrtAgeHours = $prtAgeHours
AttemptStatus = $f['Attempt Status']
ServerError = $f['Server Error Description']
Flags = ($flags -join '; ')
} | Format-List
Paste the output into the ticket (redact the tenant and device IDs if the ticket system is shared). It's a lot easier to escalate "PRT NO, AADSTS50155, DeviceAuthStatus FAILED" than a screenshot of the whole dsregcmd output.
The same device from the admin side
Take the DeviceId from the snapshot and look the device up in Entra ID with Microsoft Graph PowerShell. Device.Read.All is a read-only scope.
# Read-only
Connect-MgGraph -Scopes 'Device.Read.All' -NoWelcome
$deviceId = '<DeviceId from dsregcmd>'
Get-MgDevice -Filter "deviceId eq '$deviceId'" `
-Property displayName,deviceId,accountEnabled,trustType,isCompliant,isManaged,approximateLastSignInDateTime |
Select-Object DisplayName, DeviceId, AccountEnabled, TrustType, IsCompliant, IsManaged, ApproximateLastSignInDateTime
How to read it:
-
No result: the device object is gone. That matches
AADSTS50155, and re-registration is the fix. -
AccountEnabled = False: someone disabled it. Find out who and why (the Entra audit log) before you re-enable it. -
TrustType:AzureAdis Entra joined,ServerAdis hybrid joined,Workplaceis registered only. If the laptop thinks it's hybrid joined and the only record isWorkplace, that's your mismatch. -
IsCompliant = Truebut CA still blocks: go to the next section.
AzureAdPrt is YES, but Conditional Access still says "not compliant"
This one wastes a lot of time. The device has a healthy PRT and Intune shows it compliant, but the user still gets AADSTS53000 (device not in the required state) in the browser.
Open the failed sign-in in Entra admin center > Monitoring & health > Sign-in logs and look at the Device info tab:
-
Device ID is blank and Join type is empty: the browser didn't send the device identity. The device is fine. The browser isn't using the PRT. Common reasons are an InPrivate or incognito window, Chrome without Windows accounts sign-in enabled (the Microsoft Single Sign On extension or the
CloudAPAuthEnabledpolicy), or Firefox without its Windows single sign-on setting turned on. - Device ID is present, Compliant = No: the PRT is working and the problem really is compliance. That's an Intune question, not a token question. See the compliance posts linked below.
-
Device ID is present, but a different one than the laptop's
DeviceId: you're looking at a duplicate or stale record. Compare the records.
When re-registration is actually the answer
Everything above is read-only on purpose, because the common "fix" for a missing PRT is dsregcmd /leave and a rejoin. That works when the device object really was deleted or disabled, or when the device keys are broken. Otherwise it just adds a second problem: BitLocker key escrow, Intune enrollment, Windows Hello and the user's profile can all be affected by leaving and rejoining.
Before you re-register a device, check that:
- You've seen
AADSTS50155orDeviceAuthStatus : FAILED. Device is either disabled or deleted, or the Graph lookup returns nothing. - Its BitLocker recovery key is escrowed somewhere you can reach.
- You know which join path the device will take back (Autopilot, user-driven join, or the hybrid join scheduled task), and the user can be offline for that long.
- You've written the change down. Disjoins and rejoins are exactly the kind of change that makes a good post-incident note.
If none of those registration errors are there, keep going on identity, sync or network. Re-registering won't fix a UPN mismatch or a proxy.
FAQ
Why does dsregcmd show AzureAdPrt NO when the device is Entra joined?
The device is joined, but Windows couldn't get a token for this user. Read Attempt Status and Server Error Description under SSO State. The most common causes are a deleted or disabled device object (AADSTS50155), a user Entra ID can't find (AADSTS50034), or a network or proxy block.
Should I run dsregcmd /status as administrator?
For the PRT, no. Run it as the affected user in a normal prompt, because the SSO State is per-user. Elevation is only needed for a few device checks, such as KeySignTest.
How do I force a PRT refresh?
Lock and unlock the device, or sign out and back in. Then run dsregcmd /status again and check whether AzureAdPrtUpdateTime changed. On hybrid joined devices, give it about a minute after unlocking.
AzureAdPrt is NO right after the user changed their password. Why?
On hybrid joined devices with password hash sync, the new password might not be in Entra ID yet, so the PRT request fails with AADSTS50126. Wait for the next Entra Connect sync, then lock and unlock.
Does AzureAdPrt NO break Conditional Access?
It breaks any policy that needs the device's identity, such as "require compliant device" or "require Microsoft Entra hybrid joined device," because the sign-in arrives without proof of which device it came from. Users also lose silent single sign-on, so they see more password prompts.
Related posts
- Company Portal can't connect / device not syncing: a 10-minute triage order for Intune admins
- A Tier-1 helpdesk card for "Outlook keeps asking for my password": symptoms, checks and when to escalate
- Intune compliance "Not applicable", "Is active" and minimum OS
- Conditional Access Report-Only Results: Logs vs On
Free checklist
If you're planning a "require compliant device" or "require hybrid joined device" policy, PRT problems are one of the things to find in report-only mode, not on Monday morning. The free Conditional Access pre-enforcement checklist puts the device, pilot group and report-only checks on one page:
If you handle a lot of these tickets, the Intune & M365 Admin Starter Pack has enrollment hygiene notes, break/fix cards and a read-only local enrollment snapshot script built on the same dsregcmd fields: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=azureadprt-no
Admin Pack Studio; not affiliated with Microsoft. The scripts above only read. Test any change to device registration in a pilot or lab first.
Top comments (0)