Skip to content
Resorcerer Docs

Connect Microsoft Entra ID

Resorcerer can read your organization’s directory straight out of Microsoft Entra ID (formerly Azure AD) and keep your people directory current automatically — see Integrations for how connecting a provider and People Sync work in general. This guide covers the Entra-specific setup: the app registration Entra needs, what gets synced, and how to scope who counts as a person in your tenant.

Resorcerer never writes to your tenant — the connection is read-only, and only ever calls Microsoft Graph’s /users (and, if you scope to a group, /groups) endpoints, plus each user’s profile photo if you turn on People Photo Sync, and each limit group’s /groups/{id}/members if you turn on group sync.

Register an app in Entra

Section titled “Register an app in Entra”

People Sync authenticates as an application, not a user, using the OAuth2 client credentials flow. You’ll need Application Administrator (or Global Administrator) rights in the tenant to complete this.

  1. In the Entra admin center, go to App registrations → New registration. Any name works — e.g. “Resorcerer People Sync”. Leave the redirect URI blank; this app never signs a user in.
  2. Under Certificates & secrets, create a new client secret. Copy its value immediately — Entra shows it exactly once, and Resorcerer’s connection form asks for it during setup.
  3. Under API permissions, add Microsoft Graph → Application permissions → User.Read.All, then select Grant admin consent for the tenant. Without this step every sync fails with a permissions error, even with a correct secret — application permissions always require an admin’s explicit consent, unlike permissions a signed-in user can consent to for themselves. If you plan to turn on group sync, also add Group.Read.All and GroupMember.Read.All here and grant admin consent for both at the same time — otherwise a group-sync run fails outright, without syncing any of the people it would otherwise have reached.
  4. From the registration’s Overview page, note the Application (client) ID and Directory (tenant) ID — both go into Resorcerer’s connection form.

Connecting

Section titled “Connecting”
  1. Go to Integrations under Configuration, choose Add integration, and pick Microsoft Entra ID.
  2. Enter the Tenant ID, Application (client) ID, and the client secret from the app registration above.
  3. Leave Graph base URL and Authority blank unless your tenant is in a sovereign cloud (Microsoft 365 GCC High/DoD, Azure Government, or Azure China) — see your cloud’s Graph and login endpoints if so.
  4. Test the connection before saving. A failed test names the problem directly:
    • An invalid or expired client secret — regenerate one under Certificates & secrets and update the connection.
    • Missing admin consent — go back to the app registration’s API permissions and grant admin consent for User.Read.All.
    • The wrong tenant — double-check the Tenant ID, which is easy to transpose with the client ID.

Scope filters

Section titled “Scope filters”

A tenant is full of accounts that aren’t people — guests, disabled accounts, shared mailboxes, meeting rooms, service accounts. From the People Sync section on the integration’s detail page, you can:

  • Exclude guest accounts (on by default).
  • Exclude disabled accounts (on by default).
  • Require an employee ID or job title — filters out most shared mailboxes and resource accounts, which typically have neither.
  • Limit to groups — sync only people who are members of at least one of the Entra groups you pick, directly or through a nested group, instead of the whole tenant. These are also the groups group sync walks. Open the picker to choose groups: when the app registration has the group permissions (Group.Read.All and GroupMember.Read.All), it searches your tenant’s groups by name and lists each with its object ID; without those permissions it takes a group’s object ID instead — copy it from the group’s Overview page in the Entra admin center. Typing an object ID that the search doesn’t find also adds it. Chosen groups appear as removable chips above the picker. Test connection tells you whether the group permissions are granted; a connection without them still passes, since they are only needed for choosing groups by name and for group sync. To sync everyone in the tenant but mirror only certain groups, pick those groups and untick Only sync people who are members of these groups: the groups then only decide what group sync walks.

Groups

Section titled “Groups”

Turning on Sync groups from Microsoft Entra ID, also on the People Sync section of the integration’s detail page, syncs your tenant’s group structure — not just its people — into Resorcerer’s own Groups, nesting and membership included:

  • The groups it walks are the ones under Limit to groups in the scope filters above — there is no separate picker. Every group reachable by walking one of those groups’ nested subgroups (via Microsoft Graph’s /members endpoint) is synced, along with its direct user members. Nothing is synced while Limit to groups is empty, even with the toggle on.
  • Name pattern (optional) — a prefix or glob (e.g. Team-*) a discovered subgroup’s name must match to be synced. A subgroup that doesn’t match, along with its entire subtree, is skipped — useful for excluding security or distribution groups you don’t want mirrored as Resorcerer groups.
  • Max depth (optional) — how many levels below each of those groups to walk. Leave blank to walk the full tree.

Group sync needs the Group.Read.All and GroupMember.Read.All permissions on the app registration; Test connection reports whether they are granted. A group reachable through more than one parent (a group nested under two different limit groups, for instance) is synced under each parent honestly, rather than picked arbitrarily.

A connection set up before the two pickers were merged, with root groups and no limit group, shows those root groups under Limit to groups with Only sync people who are members of these groups unticked — the same behaviour as before. One that had both a limit group and different root groups keeps walking its root groups, and the section lists them with a Use Limit to groups instead button to switch over.

Like people, a group that disappears from the walk on a later run (deleted in Entra, renamed out of the name pattern, or unlinked from every limit group) is deactivated, not deleted, and its memberships are updated to match what the walk found.

What gets synced

Section titled “What gets synced”

People Sync reads each person field from a standard Entra user attribute by default:

Resorcerer field Entra attribute (default)
Name displayName
Email mail, falling back to userPrincipalName
Title jobTitle
Department department
Location (free text) officeLocation
Company (free text) companyName
Start date employeeHireDate
End date employeeLeaveDateTime
Manager the user’s manager relationship

Field sources

Section titled “Field sources”

Every one of those can be pointed at a different attribute from the Field sources part of the People Sync section — click its header to expand it. Each field has a picker listing the common user attributes — city, country, usageLocation, employeeOrgData › division, extensionAttribute1 through 15, and so on — plus Custom… for anything else: a directory extension attribute (extension_<appId>_<name>) or a dotted path into a nested attribute (employeeOrgData.costCenter). A tenant that keeps the real site in city rather than officeLocation, for instance, points Location at city.

Manager can also come from an attribute rather than the directory’s manager relationship — useful when the reporting line lives in an HR-fed extension attribute that Entra’s own manager field doesn’t reflect. Pick the attribute, then say what it holds: the manager’s object ID, user principal name, email or employee ID. Anything but the object ID is looked up across every synced user, so the manager is found wherever they sit in the listing. A value that matches nobody leaves that person without a manager, and the run’s notes say how many that happened to.

See Managed fields for how a synced field becomes read-only on that person’s profile. An account that disappears from the scoped result set on a later sync (removed, disabled, or moved out of scope) is deactivated, not deleted, exactly like any other integration.

Profile photos

Section titled “Profile photos”

People Photo Sync is a second capability on the same integration, switched on and off independently of People Sync from the integration’s detail page. It shows each person’s Microsoft 365 profile photo on the People page and everywhere else a person’s avatar appears.

It works for anyone whose external id is their Entra object id — which is what People Sync records, and also what Entra’s own SCIM provisioning sends — so an organization that provisions people over SCIM can use an Entra connection for photos alone, with People Sync left off.

How it behaves:

  • A run needs no Graph calls. It writes each active person a photo link that Resorcerer serves itself, fetching the photo from Microsoft Graph the first time it’s shown and caching it afterwards. A photo that hasn’t changed is never downloaded twice; a person with no photo shows their initials as before.
  • A hand-entered photo URL is never replaced. Clear it if you want the Entra photo instead.
  • A person marked inactive has their synced photo removed on the next run.
  • Turning the capability off asks whether to keep the linked photos (they keep showing while the integration exists) or clear them now. Disconnecting the integration always clears them.

The User.Read.All permission granted above already covers profile photos, so no change to the app registration is needed. If you’d rather grant something narrower for a photos-only connection, Graph’s ProfilePhoto.Read.All application permission is enough for this capability (but not for People Sync).

Role, level, location and company

Section titled “Role, level, location and company”

Nothing in Entra is read as a role or a level. A synced person’s Role, Level, Location and Company attributes are worked out from the fields above — title, department, company, location and the rest — by the match expressions on the Roles, Levels, Locations and Companies pages, exactly as for people added any other way. A rule such as title:~engineer or company:~contoso is how an Entra tenant’s job titles and company names become the attributes your models use. See Match people to attributes.

The attributes are never managed by the integration, so you can still pin an override on a synced person when a rule gets someone wrong.

Large tenants and throttling

Section titled “Large tenants and throttling”

People Sync pages through /users automatically — there’s nothing to configure. If Microsoft Graph throttles a request (429 Too Many Requests), People Sync honors the Retry-After it returns and retries within the same run rather than failing it.

Future work

Section titled “Future work”

Every connection currently uses its own single-tenant app registration. A multi-tenant app (so connecting a new tenant is an admin-consent click instead of an app registration) is a planned improvement, not yet available.

Section titled “Related”