AADSTS500341: User account has been deleted from the directory (fix)

What does AADSTS500341 mean?

Microsoft’s error code reference doesn’t list AADSTS500341 (checked 30 October 2026).

Microsoft documents it on a Viva Goals page about Microsoft Entra errors, which gives the message as:

AADSTS500341: The user account <account ID> has been deleted from the <AAD> directory. To sign into this application, the account must be added to the directory

Its resolution: “The user account with which this connection was first created is no longer in an active state. Try creating a new connection.”

The same page lists 50034 as “The user account <account ID> doesn’t exist in the <AAD> directory.” So the two codes say different things: 50034 is a name that doesn’t exist, 500341 an account that existed and was deleted.

Microsoft’s page on restoring users explains the deleted state: “After you delete a user, the account remains in a suspended state for 30 days. During that 30-day window, the user account can be restored, along with all its properties.” After that, “the permanent deletion process automatically starts and can’t be stopped.” Microsoft doesn’t say whether 500341 is returned only during those 30 days or also after permanent deletion.

We tried to reproduce it in the lab three times on 30 October 2026 and never got 500341. What we got instead is worth knowing:

Time between deleting the user and signing in	Result
About 30 seconds	65001, consent not granted: the same answer an active user got in that run
About 30 seconds, with consent already granted	A token was issued. The sign-in succeeded for a user that no longer existed
About 12 minutes	50034, the user account does not exist

The middle row is the one to take away: a deleted account can still sign in successfully for a short window after deletion. That is a reason to revoke sessions and disable the account before you delete it, rather than relying on the delete alone.

None of the three runs produced 500341, so on this tenant a deleted user ends up at 50034 instead. Microsoft’s Viva Goals page gives both codes the same resolution, and we can’t tell from here which conditions produce which. The lab tenant’s exported sign-in log shows the first attempt in SigninLogs under the deleted user’s name, as 65001 with status Interrupted.

Is it an attack?

Usually not. It means something still uses an account you deleted.

Pattern	Likely meaning
A connection or integration stops working after an offboarding	It was set up with the deleted user’s account, as Microsoft’s Viva Goals page describes. Reconnect it with an active account.
One device or app keeps failing for a departed employee	A saved sign-in or a mail profile on a device that wasn’t wiped. Benign, but find the device.
A user deleted by mistake who suddenly can’t sign in	Restore them within 30 days.
Attempts on a deleted account from IP addresses the person never used	Someone else has the old credentials. The sign-in fails, but check where else those credentials work, for example other accounts with the same password. Our interpretation, not a documented pattern.

How do I find it in my logs (KQL)?

Microsoft doesn’t document which sign-in table 500341 is logged in. Check where it lands:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "500341"
| summarize Rows = count() by SourceTable

Which deleted accounts are still being used, from where and by what:

union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "500341"
| summarize Attempts = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
            IPs = make_set(IPAddress, 10), Apps = make_set(AppDisplayName, 10), Agents = make_set(UserAgent, 5)
          by UserPrincipalName, UserId
| sort by Attempts desc

Sign-ins for an account after it was deleted, whatever the result. Delete user is an activity name in Microsoft’s audit activity list. This joins on the object ID; whether UserId is still filled for a deleted account is our assumption, not checked:

let deletions =
    AuditLogs
    | where TimeGenerated > ago(30d)
    | where ActivityDisplayName == "Delete user"
    | extend UserId = tostring(TargetResources[0].id),
             DeletedBy = coalesce(tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName))
    | project DeletedAt = TimeGenerated, UserId, DeletedBy;
union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(30d)
| join kind=inner deletions on UserId
| where TimeGenerated > DeletedAt
| summarize Attempts = count(), Results = make_set(ResultType, 10), LastSeen = max(TimeGenerated)
          by UserPrincipalName, UserId, DeletedAt, DeletedBy
| sort by LastSeen desc

A "0" in Results means a sign-in succeeded after the deletion was logged. The lab run above didn’t show that: it got 65001, not a success. Look at how long after DeletedAt it happened before treating it as a problem.

How do I fix AADSTS500341?

For the user: your account was removed from the organization. Ask its IT team whether that was intended. If you moved to a new account, sign out of the app and sign in with the new one.

For developers: treat 500341 as “this account is gone”. Clear the cached account and send the user through an interactive sign-in instead of retrying the same account.

For admins:

1. Deleted by mistake: restore the user within 30 days. In the Microsoft Entra admin center, as at least a User Administrator, go to Entra ID > Users > Deleted users. Microsoft says restoring brings back the account’s properties and the licenses it had.
2. For a synced user, Microsoft warns that “if the user still exists in your on-premises directory, the sync engine may restore the user during the next synchronization cycle.” Fix the source object first if the deletion was intended.
3. Deleted on purpose: find what still uses the account with the second query, and reconnect each integration with an active account, as the Viva Goals page says.
4. Unknown IP addresses on a deleted account: treat the old password as known to someone else. If the same person has another account, reset its password and revoke its sessions.