Azure managed devices (WIP)
Pulls device objects from Entra ID via Microsoft Graph — everything registered or joined to the directory, with its compliance and management state.
| Type name | azure_managed_devices |
| Creates | Endpoints |
| Runs on | A sensor with outbound reach to graph.microsoft.com |
| Presence flag | azure_md_exits |
| Field prefix | azure_md_ |
What it contributes
This is the directory's view of a device rather than an agent's view, so it is strong on enrolment and compliance and weak on live host detail.
- Identity — object ID, device ID, display name, domain name
- Enrolment — enrollment type, enrollment profile name, registration date, device ownership, trust type, source type, external source name
- Management — is managed, is compliant, is rooted, management type, MDM app ID, compliance expiration
- Platform — operating system, operating system version, manufacturer, model, device version
- Sync state — on-premises sync enabled, on-premises last sync, approximate last sign-in, created and deleted timestamps
- Extras — device category, system labels, physical IDs, extension attributes, alternative security IDs
It writes the shared fields names, os, os_vendor, type, private_ip and
updated_at.
azure_md_deleted_date_time is populated for objects in the soft-delete window.
A device with that field set is not a live asset — filter on it before treating
this source as a list of active machines.
Requirements
The integration is outbound-only: it is a scheduled Graph client, so nothing is installed in the tenant, nothing runs on the devices themselves, and nothing has to reach into the deployment.
Network access
| From | To | Protocol | Port |
|---|---|---|---|
| The sensor running the integration | login.microsoftonline.com — the token endpoint | HTTPS over TCP | 443 |
| The sensor running the integration | graph.microsoft.com — the device objects | HTTPS over TCP | 443 |
Two hosts, because authentication and data live in different services: the run
takes a client-credentials token from the first, then pages /v1.0/devices from
the second. If the sensor reaches the internet through a proxy, point Proxy
settings at it rather than opening direct egress.
Access in Entra ID
| Need | Why |
|---|---|
| An account that can register applications | The credential is an app registration with a client secret |
| An account that can grant tenant-wide admin consent | Device.Read.All is an application permission, which is inert until consented — see Permissions in Entra ID |
In this deployment
| Need | Why |
|---|---|
| A registered, healthy sensor | The integration runs on a sensor, on the platform's schedule — see Sensors |
There are no special host requirements beyond a sensor that is checking in. The work is a paged HTTPS read per run, so it adds no meaningful load and needs no local storage.
Configuration
| Field | Required | Notes |
|---|---|---|
| Name | Yes | Label for this instance |
| Application (client) ID | Yes | App registration client ID |
| Directory (tenant) ID | Yes | Entra tenant ID |
| Client secret | No | Required in practice for client-credentials auth |
| Proxy settings | No | http://host:port |
| Sensor | Yes | Sensor that will run the integration |
| Ignore SSL | No | Skips certificate validation |
Permissions in Entra ID
Register an application, add an application permission on Microsoft Graph, and grant admin consent:
| API | Permission | Type |
|---|---|---|
| Microsoft Graph | Device.Read.All | Application |
The integration authenticates with client credentials against
login.microsoftonline.com for the https://graph.microsoft.com/.default scope,
then pages /v1.0/devices.
Azure users, Azure VMs and Windows Defender all use app-registration credentials. Reusing one registration with the union of the required permissions is fine and often simpler to rotate — just keep it distinct from registrations used by anything other than Lumen Edge.
See also
- Windows Defender — the agent's view of the same machines
- Azure VMs — infrastructure rather than directory objects
- Integrations overview — the shared configuration model