Keep Microsoft 365, replace Entra ID sign-in with Keycloak

Keep Microsoft 365 and move sign-in to Keycloak: what the constraint requires

Keycloak can take over sign-in for Microsoft 365 users through SAML 2.0 federation, but only under conditions that Microsoft sets, and only for some clients. Microsoft supports federating Microsoft 365 sign-in to a third-party SAML 2.0 identity provider, which is the route that lets your own Keycloak realm authenticate people who still hold Microsoft 365 licenses. The team should confirm early which of its daily tools fall inside that supported set, because the federated route works for web clients such as Outlook on the web and SharePoint Online and for email clients that use supported Exchange access methods. Desktop Office applications and other clients outside that list may still need Entra ID credentials, so the sign-in experience will differ by application.

Federation does not remove Entra ID from the picture. The Microsoft 365 tenant, the license assignments, the mail and collaboration data and the user objects all stay in Entra ID, and the users must already exist there through Entra Connect or PowerShell before federation can apply. The NameID in the SAML assertion must match each user's ImmutableID, so the mapping between your Keycloak accounts and the Entra objects has to be designed and tested before any cutover. The default onmicrosoft.com domain cannot be federated, which means the organization's own verified domain is the one that moves. Keycloak therefore becomes the authority for the password and MFA step, while Entra ID remains the directory and licensing system that Microsoft 365 reads.

Before committing, the team should run a pilot with a small group of accounts and document every client it depends on, then confirm the current requirements with Microsoft's SAML 2.0 identity provider guidance, since the supported client list and the federation settings can change. Plan for the reverse path as well. Converting a federated domain back to managed takes up to two hours and requires new random passwords for cloud sign-in for each user, so a rollback is an operational event, not a setting change. Ask your Microsoft account team and your licensing advisor which Entra ID tiers your Microsoft 365 plans already include, because the sign-in feature set you retain on Keycloak depends on those entitlements.

What the SAML federation route requires from your identity estate

Federating a Microsoft 365 domain to Keycloak over SAML 2.0 places constraints on how users, domains and the on-premises directory are set up before any sign-in is tested. The cards below cover the parallel requirements that must hold together, from the identifier Entra expects to the directory source that Keycloak can keep on your own network.

NameID must match ImmutableID

With a SAML 2.0 identity provider, the NameID in each assertion has to equal the Entra user's ImmutableID, not the sign-in name people type. Keycloak must therefore send a value that maps one-to-one to the ImmutableID stored for each user. Check this with a pilot user before changing any domain, because a mismatch causes sign-in failures that look like password problems to end users.

Users provisioned in Entra ID first

Federation does not create cloud accounts. Every user must already exist in Entra ID, provisioned through Microsoft Entra Connect or PowerShell, with their ImmutableID set. Confirm which accounts are synced from on-premises Active Directory, which are cloud-only, and who owns the sync process, since changes made in Keycloak do not flow back into Entra on their own.

Default onmicrosoft.com domain excluded

The default onmicrosoft.com domain that every tenant receives cannot be federated. Only a custom domain you have verified in Entra can move to the SAML identity provider. Inventory every domain in the tenant, including those used for mail, SharePoint and legacy accounts, and decide which ones move, because each federated domain is governed by the same Keycloak realm trust.

Keycloak as a supported SAML 2.0 IdP

On the Keycloak side, the realm must act as a SAML 2.0 identity provider that Microsoft trusts, with signing certificates, endpoints and attribute mappings that match what Entra expects. Keycloak supports SAML 2.0 and OpenID Connect, so the configuration is standard, but it must be set up and tested against Microsoft's requirements. Ask your implementation partner to document the certificate renewal process before go-live.

On-premises directory stays as source

Keycloak has built-in user federation with existing LDAP and Active Directory servers, so the authoritative directory can remain on your own network. Entra Connect still synchronizes identities into the cloud, and Keycloak can authenticate against the same directory. Decide early whether Keycloak reads from Active Directory directly or whether accounts are maintained in Keycloak, because that choice determines where password checks and account disablement happen.

Which Microsoft clients still work when sign-in moves to Keycloak

The first decision is which Microsoft clients your users depend on, because the SAML 2.0 route does not cover all of them. Microsoft supports federating Microsoft 365 sign-in to a third-party SAML 2.0 identity provider, but only for a limited set of clients. The documented examples are web clients such as Outlook on the web and SharePoint Online, and email clients that use supported Exchange access methods. Treat that list as the boundary of what you can promise, not as a guarantee that everything else breaks. Build an inventory of every client in use, including mobile mail apps, the Office desktop applications, OneDrive and Teams, and record which sign-in path each one takes today.

Desktop and mobile clients outside the supported set may not behave the same way after cutover. Authentication prompts, token refresh, modern authentication behavior and sign-out handling can differ from what users see with cloud-managed sign-in, and some clients may require re-sign-in more often or fail silently on a stale session. Do not assume parity for any client. For each one, run a pilot with a small group of accounts on a federated test domain, record the sign-in flow, token behavior and any error messages, and compare the results against Microsoft's current documentation on the SAML 2.0 identity provider scenario. Confirm the current client list with Microsoft before cutover, because the supported set can change.

Plan the rollback path before you switch any production domain. Keep a tested method to convert the domain back to managed sign-in, and remember that converting a federated domain back to managed takes up to two hours and requires new random passwords for cloud sign-in for each user. Ask your Microsoft account team or partner to confirm the current support statement for every client in your inventory, and document the outcome per client in your cutover plan. Where a client is unsupported or behaves inconsistently, decide in advance whether to keep that group on managed sign-in, accept the change with user communication, or replace the client.

Which open-source identity options fit this route

Keycloak is the option this route is built around. It is licensed under the Apache License 2.0, is a Cloud Native Computing Foundation incubating project, and supports SAML 2.0, OpenID Connect and OAuth 2.0. Microsoft's SAML 2.0 identity provider guidance works with any compliant IdP, so Keycloak can act as the SAML identity provider that Entra ID trusts for the federated domain. It also federates with an existing LDAP or Active Directory server, which fits organizations that keep their directory on premises. The current release is 26.8.1, and the project plans four minor releases a year.

License: Apache 2.0, with no per-user license fee for the software itself.
Directory sources: built-in user federation with LDAP and Active Directory, so users can stay in the source directory.
Operations: you own the upgrade cadence, backups and high availability design, and the Operator supports Kubernetes deployments.
Support: community support is free, while Red Hat build of Keycloak is Red Hat's supported distribution.
Backup note: realm export and import is documented as limited for backup and restore, so plan database backups separately.

Confirm with the Keycloak project or your support provider which SAML features your deployed version uses for Entra federation.

How to deploy Keycloak as the federated identity provider

This sequence moves Microsoft 365 sign-in to a Keycloak identity provider through a verified Entra domain, with a tested rollback path if the federation has to be reversed.

Confirm ImmutableID mapping and Entra Connect sync
Your identity team confirms that every user who will sign in through Keycloak already exists in Entra ID through Entra Connect or PowerShell, and that the ImmutableID for each account can be derived from the on-premises attribute that Keycloak will send as the SAML NameID. Review the sync errors in the Entra admin center and check that the default onmicrosoft.com domain is not the domain you plan to federate, because Microsoft does not allow it. Output: a written mapping table of user, source attribute, ImmutableID and NameID format, signed off by the directory owner. Confirm the exact requirements in Microsoft's SAML 2.0 identity provider guidance before you proceed.
Deploy Keycloak on a supported production database
The platform team deploys Keycloak in your own cloud account, data center or air-gapped network, using a supported production database such as PostgreSQL 14 to 18. The development file database is for testing only and must not hold federated identities. Apply the production configuration guidance, set the hostname and TLS, and confirm that the instance starts and serves its admin console. Install the Keycloak Operator through Operator Lifecycle Manager if you run Kubernetes, and set operator updates to manual approval so that upgrades happen only after your review. Output: a reachable production instance with a documented version, database and backup target.
Configure the SAML client and Entra domain federation
Create a SAML client in Keycloak for Microsoft 365, mapping the NameID to the ImmutableID format from step one, and export the Keycloak SAML metadata. Then follow Microsoft's steps to federate the chosen domain with the SAML 2.0 identity provider in Entra, supplying the sign-in and sign-out endpoints and the signing certificate. Keep a copy of the pre-change domain settings and the Keycloak client configuration in version control. Output: the domain shows as federated in Entra, and a test account can reach the Keycloak login page from a Microsoft client that supports this route.
Test each supported client in a pilot group
Select a small pilot group and test every client you intend to support, one at a time. Microsoft's SAML route supports only a limited set of clients, such as Outlook on the web, SharePoint Online and email clients that use supported Exchange access methods. Record which clients sign in through Keycloak, which fall back to other behavior, and which need a different approach. Include multi-factor prompts, password resets and sign-out in each test. Output: a dated test matrix with pass or fail results, signed off by the service owner before any wider rollout.
Plan high availability and synchronous replication
Design the production topology using one of Keycloak's documented high availability architectures, and confirm that the database is synchronously replicated, which both supported designs require. Decide whether to run a single cluster across availability zones or a multi-cluster deployment, and avoid the deprecated multi-cluster v1 design for new work. Test failover of a node and of the database in a non-production environment before go-live. Output: an architecture diagram and failover test results that the infrastructure owner has reviewed.
Set the schema migration and upgrade method
Choose how database schema changes will be applied. Keycloak migrates the schema automatically at startup by default, which is simple for small deployments. For large deployments, the upgrading guidance suggests manual migration, where your database team applies the SQL and reviews it before the new version starts. Write the upgrade runbook covering the chosen method, the backup taken before each change and who approves the Operator update. Output: a runbook the database and platform teams have both reviewed, with the migration method recorded in your change system.
Document the rollback path before cutover
Before you switch production sign-in, document how to return to managed authentication. Converting a federated domain back to managed takes up to two hours, according to Microsoft, and requires new random passwords for cloud sign-in for each user. Plan a communication step and a help desk procedure for that reset, and confirm who is authorized to start the conversion. Rehearse the rollback in a test tenant if one is available. Output: a signed rollback procedure with named owners, a user communication draft and a rehearsal record, approved before the cutover window is scheduled.

What Entra licensing still applies after federation

Federating a domain to Keycloak changes where users authenticate, but it does not remove the Microsoft 365 tenant, its subscription licenses or the Entra ID directory that holds the accounts. The user objects, groups and license assignments stay in Entra ID, and Entra Connect or PowerShell still provisions them there. Your Microsoft 365 subscription keeps paying for Exchange Online, SharePoint Online, Teams and the other workloads whether sign-in runs through Keycloak or through Entra. Plan the Keycloak project as an addition to that tenant, not as a replacement for it.

Entra ID P1 or P2 features apply only if your organization holds those licenses, and federation does not change that. Conditional Access, risk-based policies and similar controls are enforced by Entra at sign-in, so if Keycloak handles authentication for a federated domain, those Entra policies no longer sit in the sign-in path for those users. Check which P1 or P2 controls you rely on today, decide whether Keycloak flows or privacyIDEA policies will cover them, and confirm which license tier your users hold. The price comparison belongs on the sibling cost page, Microsoft Entra ID P1 and P2 cost vs self-hosted Keycloak.

Confirm current license entitlements with Microsoft or your reseller rather than assuming them. Bundles change, and some Entra features are included in Microsoft 365 plans while others are sold separately. Ask for the entitlement list for each user group, including any add-ons for governance or privileged access, and record which of them your Keycloak design still depends on. This check gives you a written baseline before the domain is converted, and it prevents a license gap from appearing after sign-in has moved.

Evidence auditors and security reviewers ask for

Moving Microsoft 365 sign-in onto Keycloak creates four sets of records that an auditor or security reviewer will ask to see. Each one shows a different part of the trust chain: how users are matched, how they got into Entra ID, which clients were tested, and how the Keycloak platform is changed over time. DeployOpen prepares this evidence, while independent auditors and certification bodies decide any assessment outcome.

Federation and NameID mapping record

Document the SAML 2.0 trust between Entra ID and Keycloak, including the federated domain, the signing certificate and its expiry, and the claim rule that sets the NameID. Microsoft requires the NameID to match each user's ImmutableID, so the record should show exactly how the Keycloak attribute maps to that value for a sample of users. Ask the reviewer to confirm that the default onmicrosoft.com domain is not the domain being federated. Keep a dated export of the configuration for every change.

Provisioning and sync logs

Users must already exist in Entra ID before federated sign-in works, so the provisioning path is part of the evidence. Keep the Entra Connect sync history or the PowerShell run output that created or updated each account, along with the list of users and their ImmutableID values at the time of the review. Compare that list with the Entra user export to show that no account signs in without a matching provisioned identity.

Tested client matrix with results

Microsoft limits federated sign-in to a defined set of clients, such as Outlook on the web, SharePoint Online and email clients that use supported Exchange access methods. Build a matrix that lists each client your users rely on, the test account used, the date tested, and the observed result. Mark clients that do not work under the federated model so that no one assumes they do. Ask the business owner to sign off on any client that is excluded.

Keycloak change and upgrade records

Keep a change log for every Keycloak release, configuration edit and realm import or export, because the export process has limits as a backup and needs all nodes stopped while it runs. Record the approval step for each operator update, and confirm that manual approval mode is set so upgrades do not roll out unreviewed. Note whether database schema migration ran automatically at startup or was applied by hand. Link each entry to a rollback plan and a tested restore.

Questions buyers ask before federating Microsoft 365 to Keycloak

Can our team federate Microsoft 365 to Keycloak without outside help?

Yes, if your team already runs Keycloak in production and has people who own Entra ID and Active Directory, but the work crosses three areas: the SAML trust, the identity attributes Microsoft expects, and the Microsoft clients you use. The main risk is not the configuration itself but getting the NameID and ImmutableID mapping right the first time, because Microsoft requires the NameID to match the Entra user's ImmutableID. Teams without an in-house Keycloak operator, or without a tested backup and upgrade routine, usually bring in a partner for the build and hardening, then run it internally. Any outside help is defined in a written, fixed scope before work starts.

What makes a Keycloak and Microsoft 365 federation project larger or smaller?

The effort rises with the number of Microsoft clients you need to support, because Microsoft says only a limited set of clients works with a SAML 2.0 identity provider, such as Outlook on the web, SharePoint Online and email clients that use supported Exchange access methods. Other drivers are:

The number of users and how cleanly they are already provisioned in Entra ID through Entra Connect or PowerShell
The size and structure of the Active Directory source behind Keycloak
The high availability design, which needs a synchronously replicated database under every supported Keycloak architecture
The number of domains to federate and any custom sign-in rules

Illustrative: a tenant with one domain and only web clients is a much smaller job than one with several domains and desktop mail clients that must keep working.

How long does a Keycloak federation for Microsoft 365 take?

The timeline depends on the agreed written scope, not on a fixed figure. Scope, deliverables and timelines are agreed in writing before work starts for most engagements, and the schedule follows the client count, the directory work, the high availability design and the testing that each Microsoft client needs. Ask for the schedule to show separate phases for the lab build, the pilot with a small user group, the production cutover and the rollback test. Also ask what the plan assumes about your change windows and approval steps, since these often set the pace more than the technical work.

What does the internal team need to provide during the project?

Three roles are needed, and they can be the same people in a small organization:

Entra administrators who can add the domain, set the federation settings, and confirm the ImmutableID values on users
Active Directory owners who manage the source directory, Entra Connect sync and the attributes Keycloak receives through user federation
A Keycloak operator who will own realms, clients, certificates, database backups and upgrades after handover

Keycloak releases four minor versions a year, and its operator documentation strongly recommends manual approval mode for operator updates, so the operator role is ongoing, not a one-off task.

Will users lose Microsoft 365 access during the switch to Keycloak sign-in?

Users should not lose Microsoft 365 access if the cutover is planned against the supported clients and tested before the switch. The risk sits with clients outside Microsoft's supported list for SAML federation, which may stop working or prompt for credentials after the change. Ask for a test matrix covering every client in use, including mobile mail apps and desktop Office applications, and a documented rollback path. Microsoft also states that converting a federated domain back to managed takes up to two hours and requires new random passwords for cloud sign-in for each user, so the rollback plan should assume that cost.

Do we still need Entra ID licenses if Keycloak handles sign-in?

Yes, Microsoft 365 and Entra ID remain in place because Keycloak only changes where sign-in is decided, not where the Microsoft tenant, mailboxes and directory objects live. Licensing depends on the Microsoft 365 plans and any Entra ID P1 or P2 features you use, such as Conditional Access, which stay with Microsoft if you keep them. Confirm with Microsoft or your reseller which licenses your tenant needs after the change, and ask for a quote that separates what Microsoft charges from what the Keycloak build, hosting, high availability and support cost. Those Keycloak costs are one-time build work plus recurring operation, and they should be listed by component in the written scope.

What should a quote for this work include?

A quote should follow from a written scope that names the systems, clients, domains and users involved, and it should list each deliverable separately. Ask the provider to itemize the lab build, the Keycloak deployment and database, the high availability design, the Entra and Active Directory configuration, client testing, cutover support, documentation and handover, and any ongoing support or upgrade retainer. Ask which items are one-time and which recur, and what changes the price if the client count or Microsoft client list grows. DeployOpen does not publish a price list, and a quote follows from the written scope.

Where this route stops and what Microsoft still controls

Keycloak cannot remove the Microsoft 365 dependency. Federating the Entra domain to Keycloak only changes where a user's password and MFA are checked when they sign in to a supported Microsoft 365 client. The Microsoft 365 tenant, its licenses, its admin center, its mailboxes and its directory objects remain Microsoft's, and every Entra-side feature you keep (Conditional Access, Exchange Online policies, Intune enrollment, and sign-in for clients outside the supported set) still runs in Microsoft's cloud. Microsoft's SAML 2.0 identity provider documentation limits this route to a specific list of clients, so the first decision is to inventory which clients your users actually run, including mobile mail apps, Teams clients and desktop Office, and mark each one as supported or not before anyone plans a cutover.

Several boundary points are easy to miss. Users still need to exist in Entra ID through Entra Connect or PowerShell, the NameID must match the ImmutableID, and the default onmicrosoft.com domain cannot be federated. If a client falls outside the supported set, it may continue to authenticate against Entra ID, may fail, or may need a different access method, so test each client against the federated domain rather than assuming behavior. Also plan for the rollback path: converting a federated domain back to managed takes up to two hours and requires new random cloud passwords for each user, which is a recovery step you should rehearse in a test tenant.

Before you commit, confirm the scope in writing with Microsoft, using the current SAML 2.0 identity provider guidance and your tenant's licensing terms, and check the Keycloak documentation for the protocol and version you intend to run. Ask Microsoft which Entra features depend on the Microsoft identity platform rather than your identity provider, and ask your Microsoft account team how any change to sign-in affects your Microsoft 365 support position. Record the answers in the design document so that the team, auditors and any future migration planner see the same boundary.

How DeployOpen approaches Entra federation to Keycloak

DeployOpen plans, implements and hands over self-hosted Keycloak inside your own infrastructure, including the federation work that keeps Microsoft 365 sign-in working. The engagement starts with a written scope that names the Microsoft clients, domains and user groups in play before any change is made to the tenant.

How we scope

We confirm which Microsoft 365 clients must keep working under a third-party SAML identity provider before any domain change is planned.
We check that users are already provisioned in Entra ID and that the ImmutableID mapping is documented for each account.
We agree a fixed scope in writing that lists domains, Keycloak realms, deliverables and the rollback path back to managed sign-in.

How we build

We deploy Keycloak in your own cloud account, data center or air-gapped network, with the database and high availability design agreed in scope.
We configure the SAML 2.0 identity provider connection, claim mapping and user federation against your existing Active Directory or LDAP source.
We test sign-in across each in-scope Microsoft client and document the results, including clients that the SAML route does not support.

How we hand over

We deliver runbooks for user provisioning, certificate rotation, domain conversion and the steps to return a federated domain to managed sign-in.
We document backup and restore procedures, noting that realm export and import have limits as a backup method and require stopped nodes.
We walk your identity, security and Microsoft 365 administrators through operations so the handover is tested by your own team.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the fixed-scope work ends.
Keycloak upgrades can be planned around the project's release cadence, with the operator update approval mode set to manual where that applies.
Ask for a written quote from the agreed scope, and confirm with your Microsoft licensing contact which Entra features still apply to your tenant.