How to connect Microsoft 365 Education and Entra ID to Kastr

SCIM user provisioning is beta and the last four rows are why. The totalResults behaviour in particular will confuse an identity provider that paginates properly, so keep provisioning scopes small until it is fixed. Publishing the defect list is the point: a CTO who reads a stated limitation and finds it accurate can stop auditing the rest of the claims.

Staff by SCIM, students by School Data Sync

The division of labour that works for a Microsoft-centred district:

Staff from Entra ID over SCIM. Configure Kastr as a provisioning target, map the attributes in the table above, and scope the assignment to the groups that should have Kastr access. New hires appear, leavers are disabled, and the effective dating is derived from when each change arrives. Given the beta limitations, keep the assigned population modest to start and confirm the counts by hand for the first fortnight.

Students and sections from School Data Sync. SDS already normalises your SIS into a OneRoster-shaped set for Teams and other Microsoft education services. Reuse it: point it at storage the district controls, then POST the files. Which files are read and which are ignored is set out on the OneRoster page.

Guardians from the SIS. Neither Entra nor SDS is a guardian contact source. Entra holds staff. SDS carries students and sections and only the guardian data your SIS chose to publish into it, which is usually little. Plan on a small direct SIS extract for guardians, phone numbers, language and rights flags — that is the same recommendation this cluster makes for every broker route, and it is the difference between a roster and a reachable roster.

Deprovisioning: three different events, three different results

Districts conflate these and then get surprised, so worth separating:

• Entra account disabled mid-year. SCIM sets active to false. Kastr end-dates the staff role. The person record remains, because the audit log needs to be able to name who sent what in March, and deleting the person would leave the history pointing at nothing.
• Entra account deleted. Kastr's SCIM implementation does not support DELETE, so a deletion in Entra typically surfaces as a soft-disable rather than a removal. Treat disable as the operative control and do not rely on deletion propagating.
• Staff member moves between buildings. If the move is expressed as a group change, the provisioning expression updates the role and the previous role is end-dated. Two clean role rows, not an overwritten field — which is what lets you answer "who was at Lincoln in March" correctly in June.

None of these is the same as a roster withdrawal. A withdrawal comes from the roster file and concerns a student's enrolment; deprovisioning comes from your identity provider and concerns a staff member's access. And a note on that access: since Kastr has no SSO, disabling an Entra account does not by itself terminate a Kastr session. Ending the role is what stops the next sign-in.

The SSO answer, without hedging

Kastr does not support Entra SSO. No SAML, no OIDC, no Microsoft account sign-in, no conditional access integration, and no MFA of any kind. Magic link is the only authentication in the product, for staff and guardians alike.

The reasoning is population arithmetic. A 12,000-student district has roughly 20,000 guardians and 900 staff, and guardians hold no district identity. Building SSO for staff would mean running two authentication systems where the weaker one still covers 96% of users. We built one and made it as strong as a single-factor mechanism can be: 32-byte tokens, fifteen-minute lifetime, single-use with atomic consumption that defeats mail-scanner prefetch, same-device binding compared in constant time, no account enumeration on the request endpoint, and session IPs stored hashed rather than raw.

What we would rather be judged on: tenant isolation enforced in Postgres by row-level security under a non-owner, DML-only role, hierarchy-aware, failing closed with no organisation context, and covered by a cross-tenant leakage suite running in CI against real Postgres 16 including an owner-bypass regression test. Plus an append-only, SHA-256 hash-chained audit log that is append-only at two independent layers.

Should staff come from SCIM or from the nightly roster file?

Pick one. Running both produces two sources arguing about the same person, and the argument is settled last-writer-wins, which is not a design.

Choose SCIM if Entra is genuinely your source of truth for staff, your joiners and leavers process runs through it reliably, and you would rather access changes propagate within minutes than overnight. Accept the beta limitations, keep the assigned scope tight, and check counts weekly for the first month.

Choose the roster file if your SIS holds staff assignments with real start and end dates, or your Entra groups are less well maintained than your HR data — which is more common than districts like to admit. This route has no beta caveats attached to it.

Either way, students and guardians come from the roster file. There is no configuration in which Entra provides them.

One operational note for whichever you choose: Kastr's outbound webhooks can notify your systems when a sync completes or aborts. The signature is an HMAC over the timestamp and raw body, retries follow a fixed schedule of 1, 2, 5, 15, 60 and 360 minutes, and an endpoint failing ten times consecutively is disabled automatically. The destination is checked at DNS-resolution time and private or loopback addresses are refused, so an internal-only endpoint cannot be configured — terminate publicly and forward inward. Full detail on the API page.

Questions people actually ask

Related