Entra Join (The Cloud-Only Path)

Cloud-Only Architecture

Entra Join (No Domain Controllers)

For modern physical devices, the gold standard is 100% Entra Join. This removes the dependency on line-of-sight to a Domain Controller, complex VPNs, and Hybrid sync latency. The device identity lives solely in the cloud.

Instant Intune Enrollment

Unlike Hybrid Join, which requires a GPO to trigger enrollment, Entra Joined devices enroll in Intune automatically the moment they join the directory, provided the MDM User Scope is correctly configured.

Entra Join Deployment Checklist

Because we have removed the sync and GPO layers, this deployment is significantly faster and less prone to retry loops. However, the tenant device settings, DNS, and Entra configuration prerequisites are strict. For where this checklist sits among the baseline, Autopilot, and the post-enrollment checks, see the new-device golden path.

Field note: enrollment failing with 0x80192efd in a GCC High tenant is almost always the Mobility blade still holding commercial .com MDM URLs, which is the sovereign default.

Stage 1: Tenant Device Settings

Before any join path runs, review Entra admin center > Entra ID > Devices > Device settings. These are tenant-wide switches: they gate who may join, who becomes a local administrator at join time, and how local admin passwords and BitLocker keys are recovered afterward. The tables below follow the blade top to bottom, matching its three groups (Manage device identities). Read the Applies to column carefully: several settings act only at interactive Entra join and are ignored by userless joins (Entra hybrid join, Entra-joined Azure VMs, Autopilot self-deploying mode), so the Hybrid path and the AVD runbook inherit only a subset of these rows.

Setting	Value	Applies to	Reason
Users may join devices to Microsoft Entra	All (default); a Selected provisioning group is the tighter end-state once every join path you use has been tested against it	Interactive Entra join only	Gates who can perform a user-context Entra join. Microsoft documents it as not gating userless joins: Entra hybrid join, Entra-joined Azure VMs, and Autopilot self-deploying mode. See the AVD warning below.
Users may register their devices with Microsoft Entra	All (locked)	Entra register (BYOD/personal registration)	Intune enrollment requires device registration, so once Intune is configured the portal locks this to All and disables None. Nothing to configure here; this row explains why the control is grayed out.
Require Multifactor Authentication to register or join devices with Microsoft Entra	No	Entra join and register; not hybrid join, Azure VMs, or self-deploying Autopilot	Enforce MFA with the Conditional Access user action Register or join devices instead: richer conditions, works with authentication strengths, and evaluates consistently where this toggle may not (third-party IdPs). Microsoft requires the toggle stay No when that CA policy exists, and the blade itself warns accordingly.
Maximum number of devices per user	20	Entra join and register; hybrid-joined devices do not count	Caps stale and duplicate device identities per user. The service default is 50; the portal dropdown marks 20 as recommended.

Local administrator settings

Setting	Value	Applies to	Reason
Global administrator role is added as local administrator on the device during Microsoft Entra join (Preview)	No	Entra join	Ships on (Graph azureADJoin.localAdmins.enableGlobalAdmins = true in the device registration policy), so it must be actively disabled. A tenant-level role must not carry local machine admin rights; local admin access goes through LAPS below.
Registering user is added as local administrator on the device during Microsoft Entra join (Preview)	None	Entra join	Controls local Administrators group membership granted at join time. Users operate as Standard Users per the foundational architecture; admin access flows through LAPS, not join-time grants.
Manage Additional local administrators on all Microsoft Entra joined devices	Keep empty; audit on a schedule	Every Entra-joined device, tenant-wide	This link assigns the Microsoft Entra Joined Device Local Administrator role: local admin on all Entra-joined devices at once. Any entry here is a fleet-wide standing privilege and belongs in your privileged-access inventory.
Enable Microsoft Entra Local Administrator Password Solution (LAPS)	Yes	Entra joined and Entra hybrid joined	Stores and rotates the built-in local administrator password in Entra with an audited retrieval path (MA.L2-3.7.5, IA.L2-3.5.3). The toggle only activates the feature; rotation schedule and complexity come from an Intune Account protection policy (Appendix B § Windows LAPS).

Other settings

Setting	Value	Applies to	Reason
Restrict users from recovering the BitLocker key(s) for their owned devices	Yes	Any device with keys escrowed to Entra; self-service recovery follows the registered owner, which a hybrid-joined device has only when an Intune primary user is set	The portal default (No) lets a device's owner self-serve full-disk-decryption keys. In a CUI enclave, key retrieval must be an admin function with an audit trail (supports MP.L2-3.8.x). Changing this setting requires at least Privileged Role Administrator.

"Users may join" and AVD: the documentation and this book's AVD chapters currently disagree

Microsoft's documentation exempts Entra-joined Azure VMs from the Users may join setting (the AADLoginForWindows extension joins as SYSTEM, a userless context). This book's AVD chapters treat All as required for session-host provisioning and compensate accordingly (Scenario: AVD § Entra Join Constraint). Until a lab test confirms the exemption holds in your tenant, keep All plus the compensating controls in an AVD tenant; if the test confirms Selected does not break the extension join, the tighter value becomes available and the compensating-controls narrative can be retired.

Stage 2: DNS Discovery Records

Devices act as clients that need to discover their management endpoints. Ensure your public and private DNS entries have these records for every UPN suffix in use.

GCC High

Host Name	enterpriseregistration.[yourdomain.com]
Record Type	CNAME
Value	enterpriseregistration.microsoftonline.us
Purpose	Tells the device where to register its identity in Entra ID.

Two DRS hostnames exist in US Government clouds

Microsoft's device registration guidance for US Government clouds requires devices to reach both https://enterpriseregistration.windows.net and https://enterpriseregistration.microsoftonline.us, while the commercial DNS guidance points this CNAME at windows.net, so you will meet tenants configured either way. The sovereign value above is field-verified working in a GCC High tenant. Whichever target the CNAME carries, allow both hostnames through egress filtering.

Commercial

Host Name	enterpriseregistration.[yourdomain.com]
Record Type	CNAME
Value	enterpriseregistration.windows.net
Purpose	Tells the device where to register its identity in Entra ID.

GCC High

Host Name	enterpriseenrollment.[yourdomain.com]
Record Type	CNAME
Value	enterpriseenrollment-s.manage.microsoft.us
Purpose	Tells the device where the GCC High Intune enrollment server is located.

Commercial

Host Name	enterpriseenrollment.[yourdomain.com]
Record Type	CNAME
Value	enterpriseenrollment-s.manage.microsoft.com
Purpose	Tells the device where the Commercial Intune enrollment server is located.

Stage 3: Entra Configuration (The Trigger)

In a cloud-only world, there is no GPO to push enrollment. The MDM User Scope is the only trigger.

• [ ] Configure MDM User Scope:

  • Navigate to Entra ID > Mobility (MDM and MAM) > Microsoft Intune.
  • MDM User Scope: Set to All (or target your device user group).
  • WIP User Scope: Set to None.
    • Warning: If set to "All," enrollment may default to MAM (app management only) rather than full device management.

• [ ] Verify the MDM enrollment URLs in the same Microsoft Intune Mobility blade, listed here in the order the blade shows them:

GCC High

The URLs must be the sovereign (.us) endpoints:

• MDM terms of use URL: https://portal.manage.microsoft.us/TermsofUse.aspx
• MDM discovery URL: https://enrollment.manage.microsoft.us/enrollmentserver/discovery.svc
• MDM compliance URL: https://portal.manage.microsoft.us/?portalAction=Compliance

Do not click Restore default MDM URLs: in GCC High that can reset them to the commercial .com endpoints and fail enrollment (0x80192efd). (US Government endpoints for Intune)

Commercial

The default MDM enrollment URLs (the .com endpoints) are correct; no change is required. (Set up automatic enrollment)

• [ ] Disable MDM enrollment when adding work or school account: leave Off (the default). This preview toggle, shown below the URLs, governs one flow only: a user in the MDM scope adding a work account for the first time through Edge or a native app such as Teams on a device that becomes Entra registered (workplace joined). Off prompts that user to enroll the device; On suppresses the prompt. It has no effect on Entra join, hybrid join, or the Settings > Accounts > Access work or school path, and even when On the user can still enroll from Settings or from a resource prompt that requires MDM. Because the enrollment restriction below blocks personal devices anyway, the toggle only decides whether a BYOD user sees an enrollment prompt that is going to fail. Set it to On if you run Windows MAM for personal devices (supported in GCC High), which is the case Microsoft recommends it for. (Set up automatic enrollment for Windows devices)

• [ ] Configure enrollment restrictions:

  • Go to the Microsoft Intune admin center.
  • Navigate to Devices > Enrollment > Device platform restriction.
  • Select the Windows restrictions tab and click Create restriction.
  • Set Name to Block Personally Owned Devices.
  • Set Description to Block enrollment of personally owned devices.
  • Click Next, set Personally owned devices to Block
  • Assign to All users.

Devices are "Personal" by default: designate Corporate devices first

When this restriction is active, Intune blocks enrollment of any device not already designated as Corporate. Devices have no corporate designation until you explicitly assign one. Enabling this restriction without a corporate designation mechanism in place will block all new enrollments.

For Entra Joined devices, there are two supported methods to designate a device as Corporate before enrollment:

• Autopilot registration (recommended): Devices pre-registered through Provisioning with Windows Autopilot are automatically marked Corporate by the Autopilot service at the start of OOBE.
• Corporate identifiers: Upload device serial numbers to Intune > Devices > Enrollment > Corporate device identifiers. Any device whose serial number matches is marked Corporate when it enrolls, no Autopilot infrastructure required.

Stage 4: Join the Device

Stages 1 to 3 are tenant-side. This stage is the one step performed on the device itself. Pick the path that matches how the device arrives; each ends with the device Entra joined and, because the user is in the MDM user scope, enrolled in Intune inside the same flow.

• [ ] Confirm the device-side preconditions:

  • Windows 11 Pro, Enterprise, or Education. Home editions cannot Entra join; they support only Entra registration (Microsoft Entra join a new Windows device during the out of box experience).
  • Not domain-joined and not joined to another tenant. A domain-joined machine belongs to the Hybrid path or the migration scenario; a machine arriving from another tenant must finish that tenant's release steps first (Moving a Device to Another Tenant).
  • A corporate designation already in place when the Stage 3 personal-device restriction is enforced: an Autopilot registration or the serial number in Corporate device identifiers. Without one, Intune refuses the enrollment as personal, and because a failed enrollment rolls the join back, the join fails too (enrollment failure rolls back the join; the restriction stops the OOBE join).
  • The joining user holds an Intune license, is in the MDM user scope, and can satisfy the Conditional Access policy on the Register or join devices user action from Stage 1: a registered MFA method or a Temporary Access Pass.
  • Line of sight to both device registration hostnames from Stage 2 and to the Intune enrollment endpoints for your cloud (US Government endpoints for Intune).

• [ ] Path A: new device, out-of-box experience (OOBE). At How would you like to set up this device?, choose Set up for work or school, sign in with the user's Entra credentials on Let's set things up for your work or school (password or passkey), and follow the remaining prompts. Windows registers the device in Entra, Entra checks whether MDM enrollment is required and starts it, and a managed user lands on the desktop already signed in (Join a new Windows 11 device to Microsoft Entra ID). An Autopilot-registered device takes over at this same screen with its assigned profile; that path is Provisioning with Windows Autopilot.

• [ ] Path B: existing device, Settings app. Sign in with a local administrator account, open Settings > Accounts > Access work or school, select Connect, and under Alternate actions choose Join this device to Microsoft Entra ID. Do not type the account into the email box above that link: the box performs an Entra registration (workplace join), the BYOD path, and leaves the device unjoined. Sign in with the user's UPN, confirm the organization shown is the intended tenant, select Join, restart, and sign in with the Entra account, which creates a new profile. Enrollment runs inside this flow for a user in the MDM scope (MDM enrollment of Windows devices: Use the Settings app).

• [ ] Path C: many devices, provisioning package. A Windows Configuration Designer package carrying a bulk enrollment token joins and enrolls devices at OOBE or from the desktop without reimaging; the token expires after 180 days and users are standard users on these devices (Bulk enrollment for Windows devices). Prefer Autopilot where it is available and keep this path for hardware that cannot be Autopilot-registered; confirm availability for your cloud in the Intune GCC High and DoD service description.

• What the join leaves behind. With the Stage 1 value None for the registering-user local-administrator setting, the joining user is a standard user from the first sign-in; local administrator access flows through LAPS, not the join. A join that fails with an enrollment error rather than a sign-in error failed at the Intune step: in GCC High suspect the Stage 3 commercial-URL trap (0x80192efd) first; otherwise the corporate designation or the MDM user scope. Windows Hello for Business provisioning is offered at a later sign-in once the Intune policy lands (Phishing-Resistant Windows Logon, below). Then move to Stage 5.

Stage 5: Verification & Success Indicators

Once the device is joined, verify state before declaring success.

• [ ] Run Verification Command:

  • Open Command Prompt and type: dsregcmd /status

• [ ] Verify Identity State:

  • AzureAdJoined : YES: The device is natively cloud joined.
  • DomainJoined : NO: This is correct for cloud-only. If this says YES, the device was accidentally Hybrid Joined.
  • AzureAdPrt : YES: The user has a valid cloud token.

• Verify Discovery: Scroll down to the Tenant Details section.

GCC High

• MdmUrl: Must point to https://enrollment.manage.microsoft.us/enrollmentserver/discovery.svc
• MdmTouUrl: Must point to https://portal.manage.microsoft.us/TermsofUse.aspx

Critical Sovereign Check

If MdmUrl points to a .com address, the machine is attempting to enroll in Commercial.

Commercial

• MdmUrl: Must point to https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc
• MdmTouUrl: Must point to https://portal.manage.microsoft.com/TermsofUse.aspx

Critical Cloud Check

If MdmUrl points to a .us address instead of .com, the machine is enrolling in the wrong cloud.

• [ ] Visual Verification (Settings):

  • Open Settings > Accounts > Access work or school.
  • You should see the connection to your Entra ID tenant.
  • Click the connection. You should see an Info button.
    • If the Info button is missing: The device is joined but not enrolled. Check the MDM User Scope in Stage 3.

• [ ] Security onboarding landed (15 to 30 minutes after enrollment): the Layer 1 EDR policy onboards the device to Defender for Endpoint and, by the same act, to Purview Endpoint DLP, with no further action on the device. Confirm in Intune > Endpoint security > Endpoint detection and response > EDR Onboarding Status (the device is listed as onboarded with a healthy sensor; the per-device page does not show this) and with the Sense service running (Defender for Endpoint Step 3); the Purview device list check is in Endpoint DLP Uses the Same Onboarding. The remaining post-enrollment checks (BitLocker escrow, compliance, Windows Hello for Business) are step 8 of the new-device golden path.

Phishing-Resistant Windows Logon (optional for Entra Join)

For Entra Join, Intune enrollment is interactive and can satisfy standard MFA CA policies without WHfB in place. However, until phishing-resistant Windows logon auth is configured users will receive per-app MFA prompts after each login because the Windows-logon PRT carries no MFA claim.

Configure Windows Hello for Business after enrollment

See Windows Hello for Business Setup & Troubleshooting for Intune policy configuration and diagnostic steps. For the full set of options including PIV cards and FIDO2 NFC keys for constrained environments, see Phishing-Resistant Authentication.

Migrating Existing Machines

Transitioning from Domain or Hybrid Join?

For environments where existing user profiles must be preserved during the transition, see Scenario: Migrating to Entra Join. This checklist covers greenfield deployments only.