Federation · 3 min read
Microsoft 365 and SAML 2.0: Federating Entra ID With Your IdP
Short answer
Microsoft 365 (formerly Office 365) authenticates users through Microsoft Entra ID (formerly Azure AD); you can federate a verified domain with AD FS or a third-party SAML 2.0 identity provider so users sign in there, though Microsoft now generally recommends cloud authentication with password hash sync or pass-through authentication unless you need federation.
Key takeaways
- Office 365 was renamed Microsoft 365 in 2020, and Azure Active Directory became Microsoft Entra ID in 2023.
- Domain federation sends sign-ins for a whole domain to your IdP; the immutable ID mapping must match the Entra ID user's ImmutableID.
- Configure federation with Microsoft Graph PowerShell; the older MSOnline module has been retired.
Office 365 adding SAML 2.0 federation was news in 2012, because it meant organizations not running Microsoft's own federation server could still give users single sign-on to Exchange Online and SharePoint. The names have changed since. Office 365 is Microsoft 365, Azure Active Directory is Microsoft Entra ID. The mechanics are much the same.
How does Microsoft 365 sign-in work?
Every Microsoft 365 sign-in goes through Microsoft Entra ID, which either authenticates the user itself or hands off to a federated identity provider for the user's domain.
Entra ID supports three main models for organizations with on-premises directories:
| Model | Where the password is checked | Infrastructure |
|---|---|---|
| Password hash synchronization | Entra ID (hash of the hash) | Sync agent only |
| Pass-through authentication | On-premises AD via agents | Lightweight agents |
| Federation | Your IdP (AD FS or third-party SAML 2.0 / WS-Fed) | Federation servers, certificates |
Microsoft's current guidance favors the first two for most organizations. Federation remains supported and is the right choice when another identity platform is your primary one or you need its specific capabilities.
What do I need to federate a domain with a SAML 2.0 IdP?
A verified domain in Entra ID, users synchronized or created with an ImmutableID, and an IdP that issues assertions in the format Entra ID expects.
Key requirements from Microsoft's documentation for third-party SAML 2.0 identity providers:
- The NameID in the assertion must be persistent and equal to the user's ImmutableID in Entra ID (often the base64 form of the on-premises objectGUID, or another stable value you chose).
- An IDPEmail attribute with the user's UPN.
- The assertion must be signed, with the certificate configured on the domain federation settings.
- The audience must be
urn:federation:MicrosoftOnline. - Recipient and destination set to Microsoft's SAML endpoint for the tenant's sign-in.
Use the SAML Decoder on a test assertion to check the NameID format, audience and attributes before switching the domain.
How is the federation configured?
With Microsoft Graph PowerShell, using New-MgDomainFederationConfiguration to set the issuer URI, sign-in and sign-out URLs, signing certificate and protocol.
The older MSOnline and AzureAD PowerShell modules, which many tutorials still show with Set-MsolDomainAuthentication, have been retired. Practical tips:
- Test with a separate verified domain or a small pilot before converting your main domain.
- Keep at least one cloud-only global administrator on the
onmicrosoft.comdomain so a broken federation cannot lock you out. - Plan certificate rollover. When the IdP's signing certificate changes, update the federation configuration before the old one expires.
Which clients work with federated sign-in?
Modern authentication clients (current Office apps, Outlook, Teams, browsers and mobile apps) all use the Entra ID web sign-in, so they follow the redirect to your IdP.
Legacy protocols that rely on basic authentication were a problem with third-party IdPs for years. Microsoft has disabled basic authentication for most Exchange Online protocols, so in practice any client in use today must speak modern authentication anyway.
What about partners and guests?
For people from other organizations, use B2B collaboration with SAML/WS-Fed identity provider federation instead of federating your own domain.
This lets a partner's users sign in with their home IdP to access resources in your tenant as guests. It is configured per partner domain in Entra External ID. Our federation guide explains the general trust model, and the AD FS articles cover claim rules if you federate through AD FS.
Questions
Do I need AD FS to use SAML with Microsoft 365?
No. Entra ID can federate a domain with AD FS or with a compatible third-party SAML 2.0 identity provider. Microsoft documents the requirements for third-party SAML IdPs, including the NameID format and the IDPEmail attribute.
Can guests from a partner's SAML IdP sign in to my tenant?
Yes, through Entra External ID's SAML/WS-Fed identity provider federation for B2B collaboration. That is a different feature from federating your own domain.
Should I move away from federation?
Many organizations do, to reduce on-premises infrastructure. Microsoft provides guidance for migrating from federation to cloud authentication. Keep federation when you need an IdP feature Entra ID cannot provide, or when another IdP is your primary platform.
Sources
Tagged: Office 365 / Microsoft 365, Microsoft, SAML, SAML 2.0, Federation, Single sign-on, AD FS