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?

Question

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?

hcetticz 45

Follow-up: blocked validating cloud-only Entra Kerberos SMB in UK South — recurring Entra error 700003 (deleted device) on the test client

This is a follow-up to my open question on whether cloud-only Microsoft Entra Kerberos with per-group share-level RBAC is supported in UK South on Standard HDD. While building the test environment to validate it, I've hit a client-side identity blocker that's now preventing me from completing the test.

Original question >>> https://learn.microsoft.com/en-us/answers/questions/5913271/authoritative-confirmation-needed-is-cloud-only-mi

Goal

Obtain a user PRT on an Entra-joined Windows VM so I can mount the Azure Files share over cloud-only Entra Kerberos and confirm supportability in UK South.

Symptom

Web-account RDP sign-in to the VM with my cloud-only Entra identity fails at the browser authentication stage with error 700003 — "Your organisation has deleted this device." It persists across multiple remediation attempts and now follows the user account, not the device.

What I've confirmed

VM device join is healthy: AzureAdJoined : YES, DeviceAuthStatus : SUCCESS, and exactly one valid device record exists in Entra.
The error first appeared after a VM was joined two ways — a bulk-enrolment provisioning package, then the AADLoginForWindows extension — where the extension's join superseded and deleted the original device object.
I redeployed a clean VM using only the extension, but 700003 follows the user to the new VM, indicating cached/server-side token state still references a deleted device object.

Remediation already attempted (all unsuccessful)

Verified only one valid device record remains in Entra.
Revoked the user's sign-in sessions.
Cleared the client WAM token broker and removed the cached work account (dsregcmd /cleanupaccounts returned 0x0).
Deleted the orphaned bulk-enrolment service account.
Cleared stored RDP credentials on the initiating client.

Questions

After session revocation and broker cleanup, what else holds a deleted-device reference bound to a user (not a device), and how do I purge it authoritatively?
Will a password reset on the user reliably invalidate the device-bound token state behind 700003, or is there a more targeted supported method?
Are there stale registered-device records tied to the user I should check beyond the All Devices list?
Is a brand-new test identity with no device history the supported pragmatic fix, or can the existing user's device-token state be fully cleaned?

Environment

Cloud-only Entra Kerberos, Windows VM in Azure with the AADLoginForWindows extension, no on-premises AD. UK South. This blocks completion of the supportability validation in my original PCS question.

Shubham Sharma 17,930 Reputation points Microsoft External Staff Moderator

2026-06-09T08:59:56.7533333+00:00

hcetticz-9705

Following up to check if the resolution provided was helpful. Let us know if you need any further assistance.

Answer accepted by question author

Amira Bedhiafi 43,046 MVP Volunteer Moderator

Hello !

Thank you for posting on MS Learn Q&A.

This looks like a device registration or PRT problem not an Azure Files or UK South storage problem yet.

So try to re-register a Microsoft Entra registered device, run dsregcmd /forcerecovery for a Microsoft Entra joined device or dsregcmd /leave for hybrid joined devices.

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

Since your new VM shows:

AzureAdJoined : YES
DeviceAuthStatus : SUCCESS

the current VM device object is valid which means that the device is present and enabled in Microsoft Entra ID.

https://learn.microsoft.com/en-us/entra/identity/devices/troubleshoot-device-dsregcmd

The remaining suspect is the user Windows/Web Account Manager/CloudAP token state. A PRT is issued through Windows CloudAP/WAM components and is device bound and WAM and CloudAP are key Windows components for PRT issuance and use and the PRT as a secure artifact used for SSO.

https://learn.microsoft.com/en-us/entra/identity/devices/concept-primary-refresh-token

Start with the machine where the web-account RDP sign-in is being initiated, not only on the Azure VM, check the user’s Entra registration state:

dsregcmd /status

If that client is Microsoft Entra joined, run:

dsregcmd /forcerecovery

Then sign in again when prompted, sign out, and sign back in. That is the supported recovery path for an Entra joined device whose referenced device object was deleted.

If the client is only Microsoft Entra registered / workplace joined, remove the account from:

Settings > Accounts > Access work or school

Then disconnect the work/school account and register it again. That is the supported path for Entra registered devices.

You need also to check more than just the normal All devices blade and use Microsoft Graph to list devices linked to the user:

GET https://graph.microsoft.com/v1.0/users/{user-id}/registeredDevices
GET https://graph.microsoft.com/v1.0/users/{user-id}/ownedDevices

If an old/deleted/superseded VM registration still appears there, remove the bad device object or recreate the user/device registration cleanly. If it no longer appears anywhere, then the reference is probably not a visible directory object anymore, but stale local token-broker state.

Revoking sign-in sessions is still the right step, but it is not always sufficient by itself. Microsoft Graph revokeSignInSessions invalidates refresh tokens and browser session cookies by resetting the usersignInSessionsValidFromDateTime but there can be a delay before revocation takes effect.

https://learn.microsoft.com/en-us/graph/api/user-revokesigninsessions?view=graph-rest-1.0

A password reset can help force fresh authentication but I would not treat it as the authoritative fix for 700003 error.

hcetticz 45 Reputation points

2026-06-14T21:17:37.96+00:00
Hello! Thank you :)

Resolved. Root cause was a stale client-side device registration, not the VM or

Azure Files.

Posting the resolution for anyone hitting AADSTS700003 on web-account RDP to an

Entra-joined VM.

Root cause

The initiating client held a local Entra registered (workplace-joined) device

certificate whose matching device object had already been deleted from the tenant.

The All Devices blade listed only the VM, confirming the client object was gone.

The orphaned certificate poisoned the WAM token broker, so every web-account RDP

attempt presented a reference to a deleted device and failed with 700003. Because

the bad state lived in the user's broker cache, the error followed the user even

across a clean VM redeploy.

Why the standard guidance did not apply directly

The client was Entra registered, not Entra joined, so dsregcmd /forcerecovery was not the right tool. forcerecovery is the documented path for Entra joined devices.

dsregcmd /leave was a no-op, because the registration was created by automatic device registration and bound to the WAM work account rather than a standalone join.

The web-account RDP method has no client registration requirement, so re-registration was never needed for connectivity. The orphan simply had to go.

What resolved it

Confirmed on the client with dsregcmd /status that it was WorkplaceJoined: YES while the directory held no matching device object.

Removed the work account from Settings > Accounts > Email and accounts. This dropped the WAM-bound registration. dsregcmd /status then showed WorkplaceJoined: NO and the Work Account block gone.

Reconnected via mstsc using the web-account option and the VM's Entra device name (not an IP, with a HOSTS entry for resolution), and signed in with the cloud-only work account.

Result

Clean logon. On the VM, whoami returns the AzureAD user and dsregcmd shows the user

PRT (AzureAdPrt: YES) and cloud TGT (CloudTgt: YES), which unblocks the original

cloud-only Entra Kerberos and Azure Files validation.

Thanks @Amira Bedhiafi. Your steer to start on the initiating client rather than the

VM, and to treat the registered-device path separately from the joined-device path,

was the correct direction. @Shubham Sharma thanks for the detailed write-up and the

fresh-identity workaround.

1 additional answer

Your answer

Shubham Sharma 17,930 Reputation points Microsoft External Staff Moderator

2026-06-09T08:59:56.7533333+00:00

hcetticz-9705

Following up to check if the resolution provided was helpful. Let us know if you need any further assistance.

Answer 1

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:

Sign in when prompted
Sign out completely
Sign back in
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.