There is a particular category of Microsoft identity problem that catches people who have used the same email address for both a personal Microsoft account and a work Microsoft 365 account. The symptom is maddening: you sign in to an application and it asks "Work or school account? Personal account?" — and whichever you pick, something does not work as expected.
We diagnosed and fixed this for an environment where a user's primary email was associated with three separate Microsoft identities: a personal Microsoft account, an M365 business account, and a legacy MSN account. The device was authenticating against the wrong identity, and the user had been living with intermittent issues for months without understanding why.
The Symptom
The user reported a collection of seemingly unrelated problems:
- Azure portal sometimes prompted for MFA, sometimes did not
- Some Microsoft 365 apps (Teams, Outlook) signed in automatically, others required manual sign-in
- OneDrive was syncing to the personal account instead of the work account
- Intune showed the device as "registered" but not "compliant"
- Windows Hello was configured but not being accepted by some cloud applications
None of these individually pointed to a clear root cause. Together, they painted a picture of an identity confusion where the device and applications were not consistently using the same account.
The Diagnostic
The key diagnostic tool for Windows device identity issues is dsregcmd /status, run from an elevated command prompt:
dsregcmd /status
The output has several sections. The critical ones:
+----------------------------------------------------------------------+
| Device State |
+----------------------------------------------------------------------+
AzureAdJoined : NO
EnterpriseJoined : NO
DomainJoined : NO
+----------------------------------------------------------------------+
| Tenant Details |
+----------------------------------------------------------------------+
+----------------------------------------------------------------------+
| User State |
+----------------------------------------------------------------------+
WorkplaceJoined : YES
WamDefaultAuthority : consumers
Two findings jumped out:
-
WorkplaceJoined: YES, but AzureAdJoined: NO. The device was only "registered" with Entra ID (workplace join), not properly "joined." Registration is the lightweight option — it tells Entra ID the device exists but does not give Entra ID management authority over it. Full Entra join integrates the device into the organisation's management plane, enabling Conditional Access device policies, Intune compliance, and seamless SSO.
-
WamDefaultAuthority: consumers. This is the smoking gun. WAM (Web Account Manager) is the Windows component that handles authentication for Microsoft cloud services. The default authority being set to "consumers" means the device was defaulting to the personal Microsoft account for all authentication requests. Work applications would then need to override this default, which sometimes succeeded and sometimes did not — explaining the intermittent sign-in issues.
Why This Happens
The root cause is having the same email address associated with both a personal Microsoft account (created years ago for Outlook.com, Xbox, Skype, or other consumer services) and a work M365 account (created when the organisation set up Microsoft 365 with the same email domain).
When the user first signed in to Windows with their email, the operating system found the personal Microsoft account and registered the device against it. The workplace join happened later — perhaps when Intune or Company Portal was installed — but the device's primary identity remained the personal account.
Microsoft's identity system treats personal and work accounts as entirely separate identity providers, even when they share an email address. The device can be associated with one or the other, and the order in which the associations were created determines the default behaviour.
The Fix
The fix has two parts: fixing the device identity, and resolving the email overlap.
Part 1: Fix the Device Identity
Step 1: Create a local admin backup account.
Before changing device identity settings, create a local administrator account as a safety net. If the Entra join process fails or the device loses connectivity mid-process, you need a way to sign in.
net user LocalBackup /add
net localgroup Administrators LocalBackup /add
Set a strong password and document it.
Step 2: Disconnect the current workplace registration.
Go to Settings → Accounts → Access work or school. The current workplace registration will be shown. Click it and select "Disconnect." This removes the workplace-joined state and clears the stale registration.
Step 3: Perform a full Entra join.
From the same Settings page, click "Connect" and select "Join this device to Azure Active Directory" (the UI still uses the old name in some Windows versions). Sign in with the work account. The device will be properly Entra-joined with the work identity as primary.
Step 4: Verify.
Run dsregcmd /status again:
AzureAdJoined : YES
WorkplaceJoined : NO
WamDefaultAuthority : organizations
AzureAdJoined: YES confirms the device is properly joined. WamDefaultAuthority: organizations confirms that authentication will default to the work account.
Part 2: Resolve the Email Overlap
The underlying problem — the same email on two Microsoft identities — will continue to cause confusion in other contexts (web browser sign-ins, mobile apps, new devices) unless resolved.
The cleanest fix: change the primary alias on the personal Microsoft account to a new address that does not overlap with the work domain.
- Sign in to https://account.microsoft.com with the personal account
- Go to "Your info" → "Manage how you sign in"
- Add a new email alias (e.g., yourname@outlook.com)
- Set the new alias as the primary alias
- Remove the work email address as an alias (optional, but recommended to prevent future confusion)
After this change, the personal Microsoft account uses the new alias, and the work email is exclusively associated with the M365 account. No more "Work or personal?" prompts.
What you keep: All data associated with the personal Microsoft account (OneDrive personal, Xbox purchases, Outlook.com mail) remains intact. Changing the primary alias does not delete the account or its data — it just changes which email address is used to sign in.
After the Fix
With the device properly Entra-joined and the email overlap resolved:
- Azure portal uses the work account consistently, with MFA enforced by Conditional Access
- Microsoft 365 apps sign in automatically using Windows SSO
- OneDrive syncs to the work account
- Intune shows the device as "compliant" (assuming all compliance policies are met)
- Windows Hello works for cloud application authentication
The intermittent issues vanished because the device was no longer confused about which identity to use.
How to Spot This Problem
If a user reports inconsistent sign-in behaviour across Microsoft services, run dsregcmd /status first. The combination to watch for:
- WorkplaceJoined: YES + AzureAdJoined: NO — Device is registered but not joined
- WamDefaultAuthority: consumers — Personal account is the default
- Multiple accounts visible in Settings → Accounts → Access work or school
This pattern almost always indicates a personal/work email overlap with an incorrect device registration order.
Dealing with identity and access issues across your Microsoft 365 environment? Our consulting team helps organisations untangle identity configurations and implement proper Entra ID architecture.