Microsoft Entra settings

5 steps 11 min Updated 17 September 2026

Microsoft Entra (formerly Azure AD) is what backs Microsoft 365. These settings connect a school to its Microsoft tenant and control what Realsmart provisions there — accounts, groups and administrative units.

Turning Entra sync on or off is done separately under School settings → Sync services (see Enable or disable sync services); this page controls how it behaves once on.

If you administer more than one school, you can apply these settings across many schools at once instead of repeating them per school — see Rolling out across a trust.

Before you start

You must be a school admin with sync settings permission, with the school selected in the switcher.
Turning Entra sync on is self-service in this app: toggle it under School settings → Sync services (Enable or disable sync services). There is no separate "we'll switch it on for you" step to unlock it — the toggle you control is the exact flag the provisioning service reads.
Connecting Entra requires an app registration in your Microsoft tenant, created by whoever administers your Microsoft 365. The app registration is where the tenant ID, client ID and client secret come from, and where the Microsoft Graph permissions the sync needs are granted. Set it up before entering the connection details below.

Set up the app registration in Microsoft Entra

Your Microsoft 365 administrator does this once, in the Microsoft Entra / Azure admin center:

In the admin center's top search bar, search for App registrations and open it, then select New registration.
Under Name, enter Realsmart Entra Sync. For the supported account types, choose either single tenant or multitenant (the first two options) — single tenant is the usual choice for one school's own directory.
Register the app. On its Overview page you'll find the Application (client) ID and the Directory (tenant) ID — these are the Client ID and Tenant ID you enter in Step 2.
Go to Manage → Certificates & secrets, select New client secret, and create one. Copy the secret's Value immediately — Microsoft shows it only once — and treat it like a password. That value is the Client secret.

Microsoft Graph permissions to grant

Still in the app registration, open API permissions → Add a permission → Microsoft Graph → Application permissions. These are application permissions — the sync signs in as the app itself, not as a person, so the Delegated permissions tab is not used. Grant the following:

Permission	What it lets the sync do	Needed when
User.ReadWrite.All	Create, update, enable/disable and delete user accounts	Always
Group.ReadWrite.All	Create and delete groups and manage their membership	When Sync groups is on
AdministrativeUnit.ReadWrite.All	Create and delete administrative units and manage who belongs to them	When Sync administrative units is on

Grant the ones that match what you've switched on in Step 3 — granting all three is fine and future-proofs the setup.

Prefer one permission instead of three? Granting Directory.ReadWrite.All on its own covers users, groups and administrative units together. It's broader than the least-privilege set above, so use it only if your Microsoft 365 administrator is comfortable with a single wide-scoped permission.

Then select Grant admin consent for Default Directory so these permissions apply across the whole tenant, not just to the admin who added them.

Steps

Step 1: Open Microsoft Entra settings

Open Microsoft Entra settings for the school. The Connection section is shown first, with Provisioning, Prepends and Group email addresses sections alongside it. The page reopens on the section you used last, and the section is in the page address (?section=), so a link you copy opens on it.

Step 2: Enter the connection details

In the Connection section:

Tenant ID — your Microsoft tenant's directory (tenant) ID, a GUID like 00000000-0000-0000-0000-000000000000.
Client ID — the application (client) ID of the app registration you created for Realsmart.
Client secret — the secret generated for that app registration. This is a masked field: once saved it shows as dots, and leaving it blank when you next edit keeps the stored secret unchanged. Only type into it to replace the secret (for example when the old one expires).
User principal domain — the domain that every account's Microsoft sign-in name and email address (its UPN) ends in: each person is provisioned as username@thisdomain. It must be a domain that is verified in your Microsoft tenant — either the built-in yourtenant.onmicrosoft.com, or a custom domain (e.g. yourschool.co.uk) you've verified in Entra.

Running a trust on one shared tenant? Give each school its own subdomain — e.g. school-a.yourtrust.co.uk, school-b.yourtrust.co.uk — and set the matching one here per school. Then each school's people get sensible, non-clashing addresses even though they share one tenant. Verify each subdomain in Entra first. If you also want each school's group email addresses on that subdomain, there's one extra one-off setup — see Group email addresses on your domain below.

Step 3: Choose what to provision

In the Provisioning section, turn on the parts you want the sync to manage:

Update password for existing users — push password changes to accounts that already exist, not just new ones.
Sync groups — provision Entra groups and membership.
Sync administrative units — provision Entra administrative units (a way of scoping admin over subsets of users).

Choose which group types sync

With Sync groups on, Group types to sync lets you narrow which kinds of group go to Entra, instead of all of them. Tick any combination of:

Teachers of — the "teachers of" groups.
Houses — house groups.
Registration groups — registration / form groups.
Role groups — the fixed role groups (learners, mentors, teaching staff, non-teaching staff, governors, observers, Ofsted).
Year groups — year-group cohorts.
Subjects — subject groups from Provision Subjects.
Groups — the catch-all: classes and anything else, including groups you create by hand and any group that hasn't been classified into a type yet.

Ticking Groups (or leaving every type unticked) also picks up any group that has no type set yet — a backstop so an unclassified group never silently drops out of sync. The other types match only their own kind.

Leave every type unticked to sync them all — that's the default and matches how Entra behaved before this option existed. This filter only takes effect while Sync groups is on; with it off, no groups sync at all regardless of what's ticked. A per-group opt-out (Sync this group to Entra on the group itself) still applies underneath — a group syncs only if its type is selected here and it's opted in.

Subjects is always listed. If Provision Subjects is off for this school, you'll see a note beside it — the option is harmless to tick, there simply aren't any subject groups to sync yet.

Preview which groups will sync

Below the type checkboxes, Groups that will sync previews exactly which groups match your current selection for this school — grouped by type, with a count you can expand to see the group names. It updates live as you tick and untick types, before you save, so you can confirm the scope is what you expect. It's hidden while Sync groups is off.

Step 4: Set prepends

New Microsoft 365 accounts get the person's own Realsmart password, or the school's default from School settings → Password — see Password settings. There's no separate Entra password on this screen.

If you use them, the Prepends section holds short single-line text values that the sync adds to the start of names when this school provisions to Entra — one each for mentors and learners, for both usernames and group names:

Mentor user prepend / Learner user prepend — added to the start of each mentor's / learner's username.
Mentor group prepend / Learner group prepend — added to the start of each mentor / learner group's name.

Use these to give a school its own prefix (for example to keep a trust's schools distinct in one tenant). Leave any of them blank for no prefix.

Step 5: Save, then test the connection

Select Save settings. Then run Sync → Test connection to confirm the tenant, client and secret authenticate and the sync has the access it needs — it's read-only and changes nothing. If the permissions check flags something missing, that's an app-registration permission to sort out — revisit the Microsoft Graph permissions to grant section above (and remember to Grant admin consent after adding any), or ask your IT admin or the provisioning team. See Test connection / Test permissions.

After the first nightly sync, check Entra sync → Issues. It lists anything the sync couldn't do — people it couldn't create, groups it couldn't update, a client secret that has expired — with what it means and what to do. See Entra sync issues.

Rolling out across a trust (MAT)

Running a multi-academy trust? You don't have to repeat this on every school. Any admin authorised for more than one school sees an Apply across MAT button at the top of this page. It opens Microsoft Entra — MAT settings, where you set the values once, tick which ones to push, choose the target schools, and apply them together.

That screen mirrors the sections here — Connection, Provisioning and Prepends. Only the settings you tick are written to the selected schools; anything left unticked keeps each school's own value, so you can push a single setting or a whole configuration without disturbing the rest.

Because a trust often runs a single Microsoft 365 tenant across all its schools, the Connection details (tenant ID, client ID, client secret, user principal domain) can be pushed here too. If your schools each have their own tenant, leave the connection fields unticked and set them per school above. A blank client secret is never written, so you can't overwrite a school's stored secret by accident.

The MAT screen pushes configuration — each school still needs Entra sync switched on under its own Sync services (Enable or disable sync services).

For the full walkthrough — selecting schools, applying, and reviewing per school — see Apply sync settings across the trust.

Group email addresses on your domain

By default, a synced group's email address ends in …@yourtenant.onmicrosoft.com. To give your groups addresses on your own domain instead — e.g. [email protected] — there's a one-off setup:

Set the User principal domain to your own domain (Step 2). Groups get addresses on the same domain as people's sign-in names; while it ends .onmicrosoft.com, the Group email addresses section warns you and nothing happens.
Add the domain as an accepted domain in Exchange Online. Verifying it in Entra (Step 2) isn't enough on its own for group email — Exchange needs it as an accepted domain. For a trust using per-school subdomains, add each subdomain.
Register an Exchange Online app in your Microsoft 365 tenant, with a certificate — your Microsoft 365 administrator does this once.
Add it here: in the Group email addresses section, switch on Set group email addresses on our domain, enter the app's ID and your …onmicrosoft.com tenant domain, save, then upload the certificate's .pfx file with its password. The section shows the certificate's thumbprint and expiry date, whether the sync has picked it up yet, and how many groups have their address.

Exchange Online app registration walks through all of it, including creating the certificate and renewing it before it expires. The .pfx file and its password only ever go into that upload — never email them to anyone, including Realsmart.

Once that's in place, the nightly Entra sync gives each group its friendly address on your domain as the primary address, with the original …onmicrosoft.com one kept as an alias. It can take a few nights for every group, because Microsoft copies new groups to Exchange Online in the background. Anything that goes wrong shows on Entra sync → Issues (Entra sync issues). (User accounts already use your domain via the User principal domain setting; this extends the same to groups.)

Good to know: the group's email works on your domain immediately — mail flow, Outlook, and reply-to all use it. For a group that also has a Teams or SharePoint site, the Microsoft admin portal may still display the onmicrosoft.com address as "primary" even though mail uses your domain. That's a known Microsoft display quirk between Exchange and Azure AD, not a misconfiguration.

What the nightly Entra sync does and doesn't touch

Two things are worth knowing about how the overnight push behaves, because both affect what you'll see in Entra the next morning.

Only what changed is sent. The sync compares each account against what it last successfully pushed and sends only real differences, rather than rewriting every account every night. The practical consequence: if someone edits an account directly in the Microsoft portal — a display name, an account disabled, a sign-in name — Realsmart no longer quietly overwrites that the following night. Realsmart still owns those fields, so the next change made on the Realsmart side will push over the top of the manual edit. If you want a school pushed back into line immediately, use Trigger a manual sync rather than waiting for the overnight run.

A frozen school is genuinely frozen. While a school's provisioning window is paused, the nightly Entra push skips that school completely — the same way the Google push does — and records the skip in the logs. That also means its "last synced" time stops advancing until the window reopens: expected, not a fault. See Cloud sync paused for what still works during the pause and how to send an individual user through early.

Signing in with Realsmart credentials

Everything above creates and maintains the Microsoft 365 accounts. To let people sign in to Microsoft 365 with their existing Realsmart / SmartLogin login — instead of a separate Microsoft password — you federate your domain to SmartLogin. That's a separate, advanced step done with Realsmart, and it comes after your sync is connected and users exist. See Single sign-on to Microsoft 365 with SmartLogin.

Did this work for you?

If a step looked different on your site, tell us and we'll update the screenshots.