SAMaccountname or UPN?

Devices can be registered and co-managed without users signing in to Windows with UPN, but the UPN behind the account must be valid and routable in Microsoft Entra ID, and the MDM/Intune scopes must be configured correctly. The Windows logon name format (SAMAccountName vs UPN-style) is not the deciding factor; the underlying user object’s UPN and Entra configuration are.

From the enrollment side, a common failure pattern for auto-enrollment/co-management is:

• Auto-enrollment task runs (GPO or co-management),
• The user’s UPN in AD uses an unverified or non-routable suffix (for example, user@contoso.local),
• Or the MDM user scope is set to None,
• Result: auto-enrollment fails with errors like 0x8018002b.

In that scenario, the fix is to correct the UPN and/or MDM scope, not to force users to log on with UPN instead of SAMAccountName.

Key points from the documented behavior:

1. UPN must be routable and verified
   • If the on-premises UPN uses a non-routable suffix (such as .local), it causes auto-enrollment failures.
   • The guidance is to change the UPN suffix in AD to a valid, verified domain (for example, contoso.com) on the user account. This can be done per-user or in bulk via Active Directory Users and Computers:
     • Open dsa.msc → locate user(s) → Properties → Account tab → change User logon name suffix to a valid UPN suffix (for example, contoso.com).
2. MDM user scope must include the users
   • If MDM user scope is set to None, auto-enrollment fails even if the UPN is valid.
   • Ensure the MDM user scope in Intune/Entra is set to include the users (for example, “Some” or “All” users) that are expected to auto-enroll.
3. How this relates to SAMAccountName vs UPN logon
   • Windows can still be logged into using DOMAIN\samaccountname while the underlying AD user object has a valid UPN (for example, ******@contoso.com).
   • The enrollment and Entra registration logic uses the UPN attribute from AD / Entra, not the exact string typed at the Windows logon screen.
   • Therefore, as long as the user object’s UPN is a verified, routable domain and MDM scope is correct, devices can register and be managed even if users continue to log on with SAMAccountName.
4. When manual UPN sign-in to an app “fixes” it
   • The behavior where registration only occurs after a user signs into an MS app with UPN suggests that the background auto-enrollment path is failing (often due to UPN domain or MDM scope issues), and the interactive sign-in is providing the correct cloud identity and token.
   • Fixing the UPN suffix and MDM scope removes the dependency on that manual app sign-in.

In practice, a rollout can keep SAMAccountName for Windows logon while:

• Updating users’ UPN suffixes in AD to a verified, routable domain used in Entra ID, and
• Ensuring MDM user scope is configured to include those users.

This allows silent/automatic registration and co-management without forcing a change in how users log on to Windows.

References:

• Troubleshooting Windows device enrollment errors in Intune
• Microsoft Entra Connect user sign-in options
• Troubleshoot user name issues that occur for federated users when they sign in to Office 365, Azure, or Intune
• Troubleshoot co-management: Auto-enroll existing Configuration Manager-managed devices into Intune