Single sign-on to Microsoft 365 with SmartLogin

3 steps 6 min Updated 4 November 2026

Single sign-on (SSO) lets your users sign in to Microsoft 365 with the same Realsmart / SmartLogin credentials they already use — no separate Microsoft password to set, forget, or reset. You turn it on by federating each of your Microsoft 365 domains to SmartLogin, which acts as the identity provider.

This is an advanced setup and it is done with Realsmart. SmartLogin is Realsmart's identity provider, so we configure the SmartLogin side for your school and give you the exact values to enter in Microsoft 365. The steps below are what happens in your own Microsoft 365 tenant — useful whether you run them yourself alongside us, or just want to understand the moving parts.

Sync first, sign-in second. Federation is the last step, after your Microsoft Entra settings are connected and your users have synced. Federation controls how people sign in; it does not create accounts. The accounts must already exist (from the sync) for anyone to sign in.

How it works

When someone signs in to Microsoft 365 with firstname.lastname@yourdomain:

Microsoft 365 sees that yourdomain is federated and hands the sign-in over to SmartLogin instead of asking for a Microsoft password.
SmartLogin authenticates the user (their normal Realsmart login) and returns a signed SAML assertion to Microsoft 365.
The assertion's identifier is the user's immutable ID. Microsoft 365 matches that to the same immutable ID on the synced account and signs the user in.

The important consequence of step 3: sign-in only works when the immutable ID SmartLogin sends matches the immutable ID on the account the sync created. The provisioning service sets this for you, but it is the single most common thing to get wrong — see The immutable-ID match below.

Before you start

Your Entra sync is connected and users have synced. Set this up first in Microsoft Entra settings. Federation replaces the password prompt for accounts that already exist. SmartLogin also builds each sign-in for the Tenant ID saved for the person's school under Entra sync → Settings → Connection, so that must be right (and, in a trust, filled in for every school that signs in this way).
Each domain is verified in your tenant. Every domain (and, for a trust, every school subdomain) that people will sign in with must be an added, verified custom domain in Microsoft 365. See Microsoft Entra settings → User principal domain.
You can run PowerShell against your tenant as a Global Administrator. The Microsoft 365 admin center cannot federate a domain — federation is a PowerShell-only operation.
Realsmart has the values you'll enter. The issuer URI, the passive sign-in URL, the sign-out URL, and the signing certificate all come from SmartLogin. We provide them; you don't invent them.

The subdomain catch

Federation is set per domain. A subdomain does not inherit its parent's federation — school-a.realsmart.co.uk and school-b.realsmart.co.uk are each federated separately, even though they share a parent and a tenant.

For a multi-academy trust on one Microsoft 365 tenant where each school signs in on its own subdomain, that means one federation command per school subdomain. Plan for it: adding a school to the trust later is a "verify the subdomain, then federate the subdomain" job, not something that happens automatically.

Steps

Step 1: Get the federation values from Realsmart

We give you four things for each domain, all originating from SmartLogin:

Issuer URI — the identifier SmartLogin stamps on every assertion. It is per tenant (it ends in your Microsoft 365 tenant ID), so it is unique to you.
Passive sign-in URL — where Microsoft 365 sends users to log in, e.g. https://smartlogin.realsmart.co.uk/smartlogin/login?school=<your school id>.
Sign-out URL — where Microsoft 365 sends users when they sign out.
Signing certificate — the public certificate SmartLogin signs Microsoft 365 sign-ins with, so Microsoft 365 can trust them. SmartLogin uses a certificate of its own for Microsoft sign-ins, so use the certificate string Realsmart hands you rather than one copied from anywhere else.

You don't derive these — copy them from us exactly. A single wrong character (a trailing slash on the issuer, the wrong tenant ID) makes every sign-in fail.

Step 2: Federate each domain

Run this once per domain (once per school subdomain, for a trust) as a Global Administrator, substituting the values from Step 1. Using the Microsoft Graph PowerShell module:

Connect-MgGraph -Scopes "Domain.ReadWrite.All"

$domain = "school-a.realsmart.co.uk"   # the domain being federated

$params = @{
    DisplayName             = "SmartLogin"
    IssuerUri               = "<issuer URI from Realsmart>"
    PassiveSignInUri        = "https://smartlogin.realsmart.co.uk/smartlogin/login?school=<school id>"
    SignOutUri              = "<sign-out URL from Realsmart>"
    SigningCertificate      = "<base64 signing certificate from Realsmart>"
    PreferredAuthenticationProtocol = "saml"
}

# Flip the domain from managed to federated
New-MgDomainFederationConfiguration -DomainId $domain -BodyParameter $params

If your tenant still uses the older MSOnline module, the equivalent is Set-MsolDomainAuthentication -Authentication Federated … with the same values. Either way, the domain moves from managed (Microsoft handles passwords) to federated (SmartLogin handles sign-in).

Repeat for every domain/subdomain. To change values later, update the existing configuration rather than adding a second one — a domain should have exactly one federation configuration.

Step 3: Confirm the immutable-ID match

This is the step that quietly breaks sign-in if it's wrong, so confirm it explicitly.

SmartLogin identifies each user by an immutable ID (a stable identifier that never changes for the life of the account). For sign-in to succeed, that value must equal the onPremisesImmutableId on the matching Microsoft 365 account. The Realsmart provisioning service sets this when it creates the account, so for synced users it already lines up — but be aware:

Never hand-edit or clear a synced user's immutable ID in Microsoft 365. If it drifts from what SmartLogin sends, that user can no longer sign in.
A user created directly in Microsoft 365 (not through the sync) has no matching immutable ID and cannot sign in via SmartLogin. Let the sync own the accounts.
If one user gets "account not found" while others are fine, a mismatched or missing immutable ID on that account is the first thing to check.

Testing sign-in

Check the domain is federated. Before touching a real login, confirm Microsoft 365 will route the domain to SmartLogin. Get-MgDomainFederationConfiguration -DomainId "school-a.realsmart.co.uk" should return your SmartLogin configuration; the realm-discovery endpoint for [email protected] should report the domain as federated and point at the SmartLogin sign-in URL. If it still says managed, Step 2 didn't take.
Sign in as a test user. Go to a Microsoft 365 sign-in page, enter a synced test user's username@domain, and confirm you are redirected to SmartLogin, not asked for a Microsoft password. Complete the SmartLogin login; you should land in Microsoft 365 signed in.
Roll out. Once one user on a domain works, the rest of that domain works the same way. Repeat the sign-in check once per federated domain.

Troubleshooting

"AADSTS… account does not exist" / "account not found" on sign-in. The account isn't synced, or its immutable ID doesn't match what SmartLogin sends. Confirm the user came from the sync and see The immutable-ID match.
Still shows a Microsoft password prompt (no redirect to SmartLogin). The domain is still managed — the federation in Step 2 didn't apply, or the user typed a different domain. Re-check with Get-MgDomainFederationConfiguration and confirm the exact domain.
"Token/assertion is invalid" or a trust/signature error. The issuer URI or the signing certificate doesn't match what SmartLogin actually sends. Re-copy both from Realsmart (Step 1) and update the configuration — don't retype them by hand.
One subdomain works, another doesn't. Federation is per domain — the second subdomain hasn't been federated yet. See The subdomain catch.
Everyone at one school fails, other schools are fine. Check that school's Tenant ID under Entra sync → Settings → Connection matches the tenant the domain is federated in.

Did this work for you?

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