Microsoft Entra settings

Microsoft Entra settings

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:

1. In the admin center's top search bar, search for App registrations and open it, then select New registration.
2. 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.
3. 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.
4. 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:

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 {#step-1}

Open Microsoft Entra settings for the school. The Connection section is shown first, with Provisioning and Prepends sections alongside it.

Step 2 — Enter the connection details {#step-2}

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 {#step-3}

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 {#group-types}

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 {#group-preview}

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 default passwords and prepends {#step-4}

Still in Provisioning:

• Default learner password and Default mentor password — the starting password given to newly-created accounts. Both are masked — leave blank to keep the stored value.

Then, 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 {#step-5}

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.

Rolling out across a trust (MAT) {#mat-rollout}

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 {#group-email-addresses}

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, done once per tenant by your Microsoft 365 administrator:

1. 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.
2. Register the Exchange app that lets Realsmart set group addresses — see Exchange Online app registration.

Once that's in place, each group Realsmart provisions gets its friendly address on your domain as the primary address, with the original …onmicrosoft.com one kept as an alias. (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 {#what-syncs}

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 {#signing-in}

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.

Related

• Enable or disable sync services
• Test connection / Test permissions
• How syncing works
• Apply sync settings across the trust
• Single sign-on to Microsoft 365 with SmartLogin
• Cloud sync paused