PRT Broken or Local Admin Not Working After Entra Join — Step-by-Step Fix

Published 27 June 2026  ·  Intune  ·  Entra ID  ·  Device Management

Two of the most frustrating post-join complaints from end users and helpdesk engineers alike: Single Sign-On stops working (the browser keeps prompting for credentials, apps throw authentication errors), and a user who should be a local administrator still gets "Access Denied" even though their role was assigned in Entra. Both problems share a single root cause — the Primary Refresh Token (PRT) is either broken, expired, or has not yet been renewed since the role was granted. This guide walks through exactly how the PRT works, how to diagnose it, and every available remediation path from the quickest lock/unlock trick through to a full unjoin/rejoin.

What Is the Primary Refresh Token?

The Primary Refresh Token is a special long-lived credential issued by Entra ID to Windows devices that are Entra-joined or Hybrid Entra-joined. It is the cornerstone of Windows Hello for Business, Web Account Manager (WAM) seamless SSO, and — critically — the mechanism by which Entra role assignments are translated into local group membership on the device.

Key PRT lifecycle facts every admin should know:

• A PRT is valid for 90 days from issuance.
• Windows attempts a silent renewal every 4 hours while the device is online and the user session is active.
• Each renewal pulls fresh claims from Entra ID — including group memberships, role assignments, and the isLocalAdmin claim used to populate the local Administrators group.
• If the device goes offline for an extended period or the Entra token endpoint is unreachable, renewal silently fails until connectivity is restored.
• A broken PRT does not immediately lock the user out — cached credentials continue to work — but SSO to cloud resources will fail, and role claim updates will not arrive.

The authoritative technical deep-dive is on Microsoft Learn: What is a Primary Refresh Token?

Symptom Map — Which Problem Do You Have?

Step 1 — Diagnosing PRT Status with dsregcmd

The single most important diagnostic command for Entra-joined device health is dsregcmd /status. Run it as the affected user (not elevated, not as SYSTEM) — the PRT is per-user and running as a different account will show different data.

# Run as the AFFECTED USER (not elevated) to see their PRT state
# Open a standard PowerShell window and paste:

$prtStatus = dsregcmd /status
$prtStatus | Select-String "AzureAdPrt|AzureAdPrtUpdateTime|AzureAdPrtExpiryTime|OnPremTgt|CloudTgt"

# To see the full SSO State section:
$inSsoSection = $false
foreach ($line in $prtStatus) {
    if ($line -match "SSO State") { $inSsoSection = $true }
    if ($inSsoSection) { $line }
    if ($inSsoSection -and $line -match "^\s*$" -and $line -ne $prtStatus[0]) {
        break
    }
}

The key fields to examine in the SSO State section of the output:

Reference: Troubleshoot devices using dsregcmd command — Microsoft Learn

The Local Admin Claim Problem — Why the 4-Hour Wait Catches Everyone Out

When you assign a user the Entra ID Device Administrator role (or Global Administrator), Entra encodes an isLocalAdmin claim in the PRT. Windows reads this claim during user sign-in and dynamically adds the account to the local Administrators group. The group membership is not persistent in the SAM database — it exists only for the duration of the session, delivered fresh from the PRT on each logon.

Rudy Ooms (Call4Cloud), one of the most respected Microsoft MVPs in the Intune/endpoint space, has written extensively about PRT claim delivery and the confusion it causes in enterprise environments. Peter van der Woude (another prominent Intune MVP) has also documented the Entra Device Administrator role behaviour and its dependency on PRT claims in his Intune policy blog series.

Additionally, the Entra admin center device settings include a blade for additional local administrators:

• Navigate to Entra admin center → Devices → Device settings
• Scroll to Additional local administrators on Microsoft Entra joined devices
• Add users or groups here — these are also delivered via PRT claim and have the same 4-hour renewal dependency

Microsoft's official documentation on this: No local administrator privileges on Microsoft Entra joined device

Step-by-Step Remediation Guide

Work through these options in order — Option 1 is the fastest for a healthy device where only claims need refreshing. Option 4 is the nuclear option for a device that is genuinely broken.

Option 1 — Refresh PRT + Sign Out/In (Fastest, Non-Destructive)

This is the correct first response for both a stale local admin claim and a PRT that stopped renewing. dsregcmd /refreshprt forces an immediate PRT renewal attempt without requiring a full sign-out.

# Run as the AFFECTED USER in a standard (non-elevated) PowerShell window
# This forces an immediate PRT renewal attempt

dsregcmd /refreshprt

# Wait ~30 seconds then verify the UpdateTime has changed:
Start-Sleep -Seconds 30
dsregcmd /status | Select-String "AzureAdPrt|AzureAdPrtUpdateTime"

# If AzureAdPrt : YES and UpdateTime is recent — sign the user out and back in
# The new claims (including isLocalAdmin) are applied at next logon

Option 2 — Force Recovery (PRT is NO or dsregcmd /refreshprt Fails)

If AzureAdPrt shows NO and a refresh fails, the PRT credential state is corrupt or the device-level Entra registration has drifted. Use dsregcmd /forcerecovery which prompts the user to re-authenticate interactively and rebuilds the PRT from scratch.

# Run as the AFFECTED USER (non-elevated)
# This will open an interactive sign-in dialog — user must complete MFA

dsregcmd /forcerecovery

# A browser/WAM sign-in prompt will appear
# User signs in with their Entra credentials + satisfies any MFA requirement
# After completion, verify:

dsregcmd /status | Select-String "AzureAdPrt|AzureAdPrtUpdateTime|AzureAdPrtExpiryTime"

# Sign out and sign back in to pick up updated claims

Option 3 — Lock/Unlock to Trigger Background Renewal

If the device is online and the PRT is technically valid but just stale (update time is old but expiry is still future), Windows will attempt a background renewal. You can nudge this by locking and unlocking the device, which triggers the Cloud Authentication Provider (CloudAP) to check for a pending renewal.

# Capture the UpdateTime BEFORE triggering lock/unlock
$before = dsregcmd /status | Select-String "AzureAdPrtUpdateTime"
Write-Host "Before: $before"

# Lock the workstation (simulates the user pressing Win+L)
Add-Type -TypeDefinition @"
using System;
using System.Runtime.InteropServices;
public class LockWorkstation {
    [DllImport("user32.dll")]
    public static extern bool LockWorkStation();
}
"@
[LockWorkstation]::LockWorkStation()

# After the user unlocks, wait 60 seconds and check again
Start-Sleep -Seconds 60
$after = dsregcmd /status | Select-String "AzureAdPrtUpdateTime"
Write-Host "After:  $after"

# If the timestamp changed, the PRT renewed successfully
# Sign out and back in to apply the fresh claims to the session

Option 4 — Full Unjoin and Rejoin (Last Resort)

If all of the above fail — the device is stuck with AzureAdPrt : NO, /forcerecovery errors out, and the device shows unhealthy in Entra — a full unjoin/rejoin may be required. This should be a last resort as it will remove the device object from Entra (which can affect Intune policy targeting, compliance state, and certificate delivery).

# STEP 1: Capture device info before leaving (run as admin)
$deviceInfo = dsregcmd /status
$deviceInfo | Select-String "DeviceId|TenantId|DeviceName|JoinType"

# STEP 2: Leave the Entra join (requires admin elevation)
# /debug flag provides verbose output — useful for logging
dsregcmd /debug /leave

# STEP 3: Restart the device
Restart-Computer -Force

# STEP 4: After restart, rejoin via one of:
#   a) Settings > Accounts > Access work or school > Connect (for manual join)
#   b) Autopilot re-enrolment (if device is in AP profile)
#   c) Re-run the Intune enrolment via the Company Portal

# STEP 5: After rejoin, verify device registration is healthy:
dsregcmd /status | Select-String "AzureAdJoined|EnterpriseJoined|DomainJoined|AzureAdPrt"

# Expected healthy output:
#   AzureAdJoined    : YES
#   AzureAdPrt       : YES

Michael Niehaus (retired Microsoft engineer and prominent Autopilot MVP) has detailed Autopilot re-enrolment considerations after device unjoin in his blog at oofhours.com — essential reading if your devices use Autopilot deployment profiles.

Verifying Local Admin Group Membership

After any of the above remediations and a sign-out/sign-in cycle, verify local admin membership with the following:

# Method 1: whoami — fastest check (run as the affected user)
whoami /groups | findstr /i "S-1-5-32-544\|Administrators"

# If the user is a local admin, you will see a line containing:
# BUILTIN\Administrators   Alias   S-1-5-32-544   Mandatory group, Enabled by default

# Method 2: Enumerate the local Administrators group members (run elevated)
Get-LocalGroupMember -Group "Administrators" | Format-Table Name, PrincipalSource, ObjectClass -AutoSize

# Method 3: Check PRT claims — confirm isLocalAdmin is present
# (only visible in ETW traces or via the AAD CloudAP plugin output)
# Simplest confirmation is the whoami /groups check above

# Method 4: Full device health snapshot for helpdesk logs
$timestamp = Get-Date -Format "yyyyMMdd-HHmmss"
dsregcmd /status | Out-File "C:\Temp\dsregcmd-$timestamp.txt"
whoami /groups | Out-File "C:\Temp\whoami-groups-$timestamp.txt"
Write-Host "Logs saved to C:\Temp\"

Decision Tree — Which Fix to Use

Official Microsoft References

• What is a Primary Refresh Token? — Microsoft Learn
• Troubleshoot Primary Refresh Tokens — Microsoft Learn
• No local admin privileges on Microsoft Entra joined device — Microsoft Learn
• Troubleshoot devices using the dsregcmd command — Microsoft Learn