Microsoft 365 Federation and Provisioning

Microsoft 365 / Entra ID domains authenticate in one of two modes: managed (cloud-only: password hash sync, pass-through auth, or cloud-native accounts) or federated (sign-in redirected to an external identity provider — ADFS, Okta, Google Workspace — via SAML/WS-Fed). Switching a domain between modes, or re-pointing federation at a new IdP, is done in PowerShell with the legacy MSOnline module (Set-MsolDomainAuthentication, Set-MsolDomainFederationSettings). MSOnline is deprecated in favor of Microsoft Graph PowerShell, but remains the documented path for some federation operations; it requires Windows PowerShell 5.1.

Converting federated → managed

Install-Module -Scope CurrentUser MSOnline
Import-Module MSOnline
Connect-MsolService -Credential (Get-Credential)      # Global Admin required
 
Get-MsolDomainFederationSettings -DomainName "$DOMAIN"   # inspect current state
Set-MsolDomainAuthentication -DomainName "$DOMAIN" -Authentication Managed

The conversion is near-instant for sign-in routing (users stop being redirected to the IdP), and with password-hash sync already in place, no password resets are needed — the classic Convert-MsolDomainToStandard password-conversion dance is unnecessary when PHS is enabled. The reverse path is Convert-MsolDomainToFederated -DomainName "$DOMAIN" (run on the ADFS server).

Setting up federation with a new IdP

Set-MsolDomainAuthentication -Authentication Federated requires the relying-party parameters — IssuerUri, PassiveLogOnUri, ActiveLogOnUri, LogOffUri, SigningCertificate (base64, single line, no PEM headers), FederationBrandName, and PreferredAuthenticationProtocol (SAMLP for SAML IdPs). These come from the IdP-side app configuration, so the IdP trust must be built first; the values can be staged in a CLIXML file (Import-Clixml) and splatted into the cmdlet. Set-MsolDomainFederationSettings updates an existing federated domain in place (certificate rollover, URI changes).

Deprovisioning / re-provisioning synced users

Directory synchronization locks cloud objects to their on-prem source: you cannot edit or delete synced users in the cloud portals, and the OnPremisesImmutableId — the anchor binding a cloud user to its source identity — is not editable through normal admin surfaces. To switch provisioning sources, disable sync, wait for objects to convert to “in cloud,” then delete and re-provision:

Set-MsolDirSyncEnabled -EnableDirSync $false

Microsoft warns the conversion can take up to 72 hours (small tenants often complete in minutes). Users show “In cloud” sync type in the admin center when ready for deletion/re-creation.

Caution: some IdPs generate an immutable external ID from the anchor when provisioning. If a provisioned user is deleted in Entra ID, that binding may be unrecoverable — the account can never be reconnected. Verify the IdP’s anchor semantics before deleting anything. Objects mastered on-prem must be managed on-prem; Microsoft documents this constraint for dirsynced objects (KB 2619062).¹

Provisioning attribute gotchas

• mailNickname — required by Exchange-adjacent flows even without Exchange; must be unique and non-empty.
• onPremisesImmutableId — must be unique per object and stable; derive it from an IdP attribute that never changes (username is risky if renames happen).

Sources

• Manage single sign-on in Azure AD — Microsoft Learn
• Set-MsolDomainFederationSettings — MSOnline Module Reference
• Converting “Federated user accounts” to “Managed user accounts” — Microsoft Q&A
• KB2619062: Can’t manage or remove objects synchronized through Azure AD Sync tool

Related: active-directory-enumeration (the on-prem side of hybrid identity), kerberos (contrast: federated SAML/WS-Fed vs. domain Kerberos), active-directory-trusts (federation as a cross-organization trust analogue).

Footnotes

1. KB2619062: Can’t manage or remove objects synchronized through Azure AD Sync tool ↩