Microsoft Entra error 700003 on web-account RDP sign-in to Azure VM — how do I clear a deleted-device reference bound to a cloud-only user?

Hello hcetticz-9705

Thank you for reaching out to Microsoft Q&A.

What you are seeing is consistent with a stale Primary Refresh Token (PRT) / WAM broker state that still references a deleted Entra device object. The key signal in your case is that:

the VM itself is healthy (AzureAdJoined : YES, DeviceAuthStatus : SUCCESS)

the problem follows the user identity

the first join path created then deleted an earlier device object

browser-based RDP sign-in fails during token acquisition with AADSTS700003

Microsoft’s official guidance for AADSTS700003 is that the device identity referenced by the token no longer exists in the tenant. Microsoft explicitly states that the fix is to re-register/recover the device, because the issued PRT remains tied to the old device identity.

https://learn.microsoft.com/en-us/troubleshoot/entra/entra-id/app-integration/error-code-aadsts700003-device-object-not-found

Below is the root cause:-

The original provisioning-package join created a device identity and issued a PRT/WAM account relationship for your cloud-only user.

When the AADLoginForWindows extension later superseded that join and the original device object was deleted, the user’s cached WAM/PRT relationship continued referencing the deleted device GUID.

Because WAM token acquisition is device-aware, the broker still attempts token renewal against the deleted device, causing:

“Your organization has deleted this device”

AADSTS700003

Microsoft internal WAM guidance also confirms that stale WAM token caches and account bindings can survive normal “revoke sessions” operations because WAM persists cached account state locally in TokenBroker stores.

Below are the recommended resolution:-

1. Run dsregcmd /forcerecovery on the VM

For Microsoft Entra joined Windows devices, Microsoft’s current supported remediation for AADSTS700003 is:

dsregcmd /forcerecovery

Run from an elevated prompt on the Azure VM. Then:

1. Sign in when prompted
2. Sign out completely
3. Sign back in
4. Re-test browser-based RDP / Azure Files access

This is Microsoft’s documented path for deleted-device token binding scenarios.

https://learn.microsoft.com/en-us/troubleshoot/entra/entra-id/app-integration/error-code-aadsts700003-device-object-not-found

This step is more authoritative than only doing:

dsregcmd /cleanupaccounts

because /forcerecovery re-establishes the Entra join trust and refreshes the device-bound PRT relationship.

2. Verify there are no stale user-registered device records

You asked whether stale records can exist beyond “All Devices.”

Yes — especially with mixed join flows.

Check all of the following:

User’s registered devices

Entra Admin Center:

Users

→ <user>

→ Devices

OR Graph:

Get-MgUserRegisteredDevice -UserId <UPN>

Also check:

Get-MgDevice -All | ? {$_.DisplayName -match "<VMName>"}

Duplicate or soft-deleted registrations can survive transiently and still influence token flows. Microsoft device FAQ documentation references duplicate/stale device records caused by repeated join/unjoin operations.

https://learn.microsoft.com/en-us/entra/identity/devices/faq

3. Password reset — will it help?

Short answer:

Possibly, but it is not the preferred targeted fix.

A password reset forces new refresh-token issuance and can invalidate older refresh paths, but Microsoft documentation does not describe it as the authoritative remediation for AADSTS700003.

https://docs.azure.cn/en-us/entra/identity/users/users-revoke-access

In practice:

it may help if stale refresh tokens are still renewable

but device-bound PRT state can persist independently inside WAM/broker caches

So the better order is:

/forcerecovery

purge WAM cache

revoke sign-in sessions

only then consider password reset

4. Pragmatic workaround — new cloud-only test identity

Yes — this is a valid and often fastest workaround

Given your goal is specifically to validate:

cloud-only Entra Kerberos

Azure Files SMB

UK South supportability

using a fresh cloud-only user with zero device history is completely reasonable.

In fact, because the issue follows the user and not the VM, a fresh identity is strong confirmation the problem is token/device-history related rather than Azure Files or the VM extension itself.