OMA-DM · SyncML over HTTPS · Entra Conditional Access

Intune, the CSP gateway,
and the access decision

Three views of one chain. Session: how a sync runs. SyncML envelope: what a single command actually looks like on the wire. Conditional Access: how a compliance Get ends up granting or blocking access — in Entra, not on the device.

Trigger
Show
Tap any element
Device is
Cloud service
Microsoft Intune
OMA-DM server. Queues each setting as an OMA-URI node operation.
Wake signal
WNS push
Unsolicited “check in now” → fires the device’s PushLaunch task. Optional.
downstream = configuration / commands
Session channel · TLS · enrollment cert
config ▸ ◂ status / data
On the endpoint
MDM client (OMA-DM agent)
Authenticates with the enrollment cert, parses SyncML, dispatches each verb by OMA-URI.
The gateway · both directions
Configuration Service Providers
Each CSP owns a branch of the tree and translates node ops into real OS work.
PolicyDMClientBitLocker DevDetailDeviceStatus
Effect
OS action + Status code
Registry / API / enforcement happens, then a Status (200 / error) returns upstream.
IDLE

Press “Run a sync session.” Watch one OMA-DM session move config down and status back up.

The SyncML envelope

A CSP setting doesn’t travel as “a setting” — it travels as this. Tap any highlighted element to see its job.

Pick an element
The same nesting wraps every command: a header that routes the session, then a body of verbs, each pointing at a node by its LocURI.
device · Intune
01
State collected
A compliance Get + reported inventory reach Intune.
Get → ./DeviceStatus/…
Intune
02
Policy evaluated
Intune judges the device against the assigned compliance policy.
verdict = …
Intune → Entra
03
Written to directory
The verdict is stamped onto the Entra device object. This is the hand-off.
device.isCompliant = …
Entra · sign-in
04
User signs in
A token request for a protected app hits Entra. The PRT identifies the device.
token request + PRT
Entra · CA engine
05
CA evaluates
Grant control reads the device’s directory state.
Require compliant device
Awaiting
Set a device state and run the decision.
Toggle Compliant / Noncompliant to see both branches. CA evaluates at token issuance, inside Entra.
The seam: Intune is the compliance authority, but the gate lives in Entra. Intune writes isCompliant onto the Entra device object; Conditional Access reads that property at sign-in. So a freshly-fixed device stays blocked until Intune re-evaluates and the directory state syncs. (Hybrid-join CA uses device join state instead of Intune compliance.)

OMA-DM verbs in the envelope

What the server can ask the client to do. Color shows which way data moves.

Select a verb
Each SyncML command targets a node by its <LocURI> and is handled by that node’s CSP.

The carve-out

not OMA-DM
  • IME / SideCarIntune Management Extension — its own HTTPS pull agent.
  • Win32 apps.intunewin packages install through IME, not a CSP.
  • ScriptsPowerShell + proactive remediations run here too.

Rule of thumb: profiles, compliance, most settings → CSP / OMA-DM. Apps + scripts → IME.

On-prem crosswalk

OMA-DM session (poll cadence)Group Policy background refresh interval
CSPClient-side extension (CSE) that applies a policy
OMA-URI (LocURI)The registry / policy path a GPO writes
MDM enrollment certDomain membership — trust that authorizes the channel
Entra device object (isCompliant)The AD DS computer object + its health attributes
Conditional Access (require compliant)NPS / NAC posture check gating network access