Azure users (WIP)
Pulls user identities from Entra ID via Microsoft Graph, then enriches each one with its directory roles, group and team memberships, licences and sign-in activity.
| Type name | azure_users |
| Creates | Users |
| Runs on | A sensor with outbound reach to graph.microsoft.com |
| Presence flag | azure_ad_exits |
| Field prefix | azure_ad_ |
What it contributes
- Identity — object ID, display name, given name, UPN, mail, user type
- Contact — mobile phone, business phones, office location, preferred language
- Organisation — job title, department, company name
- Account state — account enabled, created datetime
- Memberships — role IDs, display names and descriptions; team IDs, display names and descriptions
- Licences — licence IDs, SKU IDs and SKU part numbers
- Hybrid sync — on-premises SAM account name, sync enabled, last sync datetime
- Sign-in activity — last sign-in, last non-interactive sign-in, last successful sign-in
It writes the shared user fields user_full_name, user_email, user_title,
user_organization, user_department and updated_at.
An account with a licence assigned and no successful sign-in for months is either a cost to reclaim or a dormant credential to disable. Both readings argue for the same action, and this is the only source that gives you the pair.
Requirements
The integration is outbound-only: it is a scheduled Graph client, so nothing is installed in the tenant, nothing runs on the users' machines, 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 directory itself | 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 the directory 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 | All three permissions are application permissions, which are inert until consented — see Permissions in Entra ID |
| Entra ID P1 or above, for sign-in activity only | signInActivity is a licensed field; without it the run still succeeds and those fields stay empty |
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. Note that the per-user calls make this a long-running integration on a large tenant, so prefer a sensor that is reliably up over the smallest one available.
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 and grant admin consent for these application permissions on Microsoft Graph:
| Permission | Needed for |
|---|---|
User.Read.All | The user list and per-user detail |
Directory.Read.All | memberOf — roles, groups and teams |
AuditLog.Read.All | signInActivity on the user detail selection |
The run authenticates with client credentials, pages /v1.0/users, and then per
user reads memberOf, licenseDetails, appRoleAssignments and a $select
projection that includes signInActivity.
AuditLog.Read.All and a P1 licenceGraph only returns signInActivity for tenants with Entra ID P1 or above, and
only when the audit-log permission is consented. Without either, the sign-in
fields come back empty while the rest of the run succeeds — a silent partial
result rather than a failure.
Roles, licences and app-role assignments are fetched one user at a time. On a large tenant the first run takes a while and is sensitive to Graph throttling.
See also
- Active Directory users — the on-premises
counterpart;
azure_ad_onpremises_sam_account_nameis what ties the two together - Atlassian users — SaaS identities
- Integrations overview — the shared configuration model