Skip to content

Connect Microsoft Intune

Ledger reads Intune-managed-device and Entra-directory-device records through Microsoft Graph, for one reason only: reconciling device inventory across your tools. It is a read-only endpoint auditor — it never reads mailboxes, files, or directory roles, and it never creates, changes or deletes any configuration or data in your tenant. Auth is a certificate credential (never a client secret), and each customer tenant gets its own admin-consented grant.

What you're consenting to

Ledger's Graph app registration requests exactly two application permissions, both admin-consent-only:

Permission GUID
DeviceManagementManagedDevices.Read.All 2f51be20-0bb4-4fed-bf7b-db946066c75e
Device.Read.All 7438b122-aefc-4978-80ed-43db9fcc7715

DeviceManagementManagedDevices.Read.All is broader than the calls Ledger actually makes (Microsoft does not publish a narrower Intune-device-read permission) — Ledger only ever calls managedDevices, devices, organization, and the managed-device export-job endpoints. No detected-apps, malware-state, analytics, troubleshooting, or log-collection endpoint is ever touched, and Ledger never creates, changes or deletes any tenant configuration or data. The only request to Graph that is not a plain read is the one that asks Microsoft to prepare a managed-device export (a read-only report of your devices).

1. Enter your tenant ID in Ledger

From Connections → Add connection → Microsoft Intune, enter your Tenant ID — the GUID for your Azure AD / Entra tenant, never the literal value common. Microsoft's own guidance is that a client using common there cannot be safely tied to one tenant; Ledger rejects anything that doesn't parse as a GUID.

Saving the connection returns an admin-consent URL of this shape:

https://login.microsoftonline.com/{your-tenant-id}/v2.0/adminconsent
  ?client_id={ledger-app-id}
  &scope=https://graph.microsoft.com/.default
  &redirect_uri={ledger-redirect-uri}
  &state={one-time-token}

Open it as your tenant's Global Administrator (or another role that can grant admin consent for application permissions) — a non-admin account cannot approve this request.

Microsoft shows the two permissions listed above. Approve them, and Microsoft redirects back to Ledger.

Ledger does not trust the tenant value on that redirect on its own — Microsoft's own documentation warns that parameter can be forged. Instead, Ledger acquires a token for the tenant ID you entered in step 1 and reads the tenant claim back out of that token, so the confirmation can never be spoofed by a malicious redirect.

4. Confirm the connection is healthy

Back in Ledger, the connection should show healthy. If it shows failed, the error message (with any secret scrubbed) explains why — common causes are consent not yet propagated (retry after a minute or two) or a tenant ID that doesn't match the account that approved consent.

If Ledger later needs an additional permission, or your organization revokes consent, the connection moves to a revoked/needs re-consent state. Use the connection's Reconsent action to generate a fresh, single-use consent URL — the same walkthrough above, without contacting support or exchanging emails by hand.