Migrate from AD FS to Keycloak

Migrate from AD FS to Keycloak: what the move involves

Keycloak can take over SAML 2.0 and OpenID Connect relying parties and Active Directory user federation, but WS-Federation applications need a separate plan. If your AD FS farm is up for renewal, approaching a Windows Server lifecycle decision, or bound by a requirement to keep federation on premises, the move starts with knowing which relying parties use which protocol. The Keycloak Server Administration Guide documents OpenID Connect, SAML and Docker registry authentication as its client protocols, and WS-Federation is not among them, so any application that depends on WS-Federation (SharePoint is a common example) must be confirmed against a different replacement before cutover. Keycloak can federate users from your existing Active Directory through its built-in LDAP and Active Directory user federation, so the directory itself usually stays where it is while the federation layer changes.

In most estates the work is carried out by an internal identity team, often with an implementation partner for the parts that are new to them, such as realm design, mapper translation and cluster configuration. Your team keeps ownership of the applications, the trust decisions and the Active Directory service accounts that Keycloak will bind with. A partner typically adds the most value in re-creating claim rules as protocol mappers, testing each relying party against a staging realm and documenting the result. Effort and risk concentrate in the applications with unusual claim logic, in any application that still expects WS-Federation tokens, and in the cutover window for applications that cannot tolerate two identity providers at once. Ask any partner for a written scope that lists each relying party, its protocol and its test plan before agreeing to a timeline.

Which AD FS capabilities map cleanly to Keycloak

This table compares the main AD FS capabilities with their Keycloak equivalents and labels each as clean, needs rework or gap. Use it to decide which relying parties can move as-is, which need redesign, and which need a separate component. Confirm each WS-Federation application individually before planning, since Keycloak's documented client protocols are OpenID Connect and SAML.

AD FS capability	Keycloak equivalent	Status and notes
SAML relying party trusts	SAML clients in a realm	Clean. Re-create each trust as a SAML client and confirm entity IDs, signing certificates and assertion consumer URLs against the app's configuration.
OpenID Connect relying party applications	OpenID Connect clients	Clean. Redirect URIs, client secrets or PKCE settings and scopes must be re-entered and tested per application.
WS-Federation relying party trusts	No documented WS-Federation client protocol	Gap. WS-Federation is not among Keycloak's documented client protocols. Confirm each application, such as SharePoint, before planning.
Claim issuance and transformation rules	Protocol mappers and client scopes	Needs rework. Rules must be rebuilt as mappers. Claim names, formats and multi-value handling often change and need testing with each app.
Active Directory authentication	LDAP and Active Directory user federation	Clean for most estates. Keycloak can federate existing AD users. Confirm the bind account, attribute mappings and group handling in your environment.
Multi-factor authentication	Authentication flows with conditional OTP or WebAuthn	Needs rework. MFA policies must be rebuilt as authentication flows. Confirm which second factors your users already have enrolled.
Kerberos and Windows integrated sign-in	Kerberos authentication through the Keycloak Kerberos federation provider	Needs rework. Confirm keytab setup, SPN ownership and browser configuration. Test with the browsers and clients in use.
Web Application Proxy publishing of AD FS and internal apps	Not replaced by Keycloak	Gap. Keycloak is not a reverse proxy. Plan a separate reverse proxy in front of Keycloak and the applications it protects.

How Keycloak fits alongside the existing Active Directory

Keycloak can leave user accounts in Active Directory and still take over token issuance. Its built-in user federation connects to existing LDAP and Active Directory servers, so passwords, group memberships and account lifecycle remain under the directory your help desk already manages. When a relying party asks for a sign-in, Keycloak authenticates the user against the directory through the federation provider, then issues the OpenID Connect token or SAML assertion itself. Before you commit to this design, confirm with your directory team which attributes and groups the federation link must read, whether the bind account needs write access for any feature you plan to use, and how the federation mapping handles accounts that are disabled or locked in AD.

Kerberos needs separate planning. Keycloak's documented federation with Active Directory covers LDAP-based authentication, and Kerberos-based sign-in for Windows clients is a different configuration path that you should verify against the current Keycloak Server Administration Guide for your target version before promising integrated Windows sign-in to users. Map each AD FS application that currently relies on Integrated Windows Authentication to a specific test case, because those apps are the ones most likely to need a different approach.

The realm and client model replaces AD FS trust definitions. A realm is the isolation boundary that holds users, clients, roles and authentication settings, so you can separate a production workforce realm from test or partner realms. Each relying party trust becomes a client: an OpenID Connect client with redirect URIs and scopes, or a SAML client with its own endpoints and signing certificate. Claim rules become protocol mappers attached to those clients. Document each trust as a client definition in a spreadsheet during inventory, including its signing certificate, expected claims and the realm it belongs to, so the new clients can be checked against the old trusts one by one.

Migration sequence from inventory to AD FS decommission

This sequence moves AD FS relying parties to Keycloak one application at a time, so each app is proven on the new provider before AD FS is switched off. Every step ends with a artifact or check that gates the next one.

Inventory relying party trusts and actual usage
The identity team exports every AD FS relying party trust, its protocol, claim issuance rules, signing and encryption certificates, and endpoints, then pulls usage data from the AD FS admin logs to see which trusts still sign in users. Application owners confirm which trusts are live, which are retired and which use WS-Federation. The step is done when each trust has an owner, a protocol, a target Keycloak client type or a documented exception, and a sign-off date recorded in the migration register.
Build the Keycloak realm and Active Directory federation
The platform team installs Keycloak on the production database and sets up a dedicated realm for workforce sign-in. It then configures the LDAP or Active Directory user federation provider with a read-only service account, mapping the username, email and group attributes that the claim rules currently depend on. The step is done when a test account authenticates against the realm with the same password and MFA path it uses today, and group membership returns as expected in the admin console.
Re-create SAML and OpenID Connect clients
For each live trust, the engineers create a matching Keycloak SAML or OpenID Connect client, copying the entity ID, assertion consumer URLs or redirect URIs, and signing certificates from the AD FS export. Trusts that depend on WS-Federation are logged as exceptions, because the Keycloak SSO protocols do not document WS-Federation. The step is done when each client's metadata validates against the application's configuration and the export lists no missing endpoints.
Translate claim rules into protocol mappers
Working from the claim rules exported in the first step, the identity engineers rebuild each issuance rule as a Keycloak protocol mapper or client scope, such as attribute, group, role or user session mappers. They compare the token or assertion each application receives today with the output from Keycloak using a test user, paying close attention to name identifiers, group claims and any transformed values. The step is done when the claim sets match for every test scenario the application owners supplied, and differences are approved in writing.
Pilot with one low-risk application
The team moves one application with a small user group and a clear rollback path, such as an internal tool with no external partners. Users sign in through Keycloak while the application owner watches login success, token contents and session behavior for a set period agreed in advance. The step is done when the pilot produces no unresolved sign-in failures, the rollback procedure has been rehearsed, and the owner approves moving to the next wave.
Run a parallel period with both providers
For the remaining applications, AD FS and Keycloak stay live together, and each application is assigned to a wave with users or test groups who can switch back. The team monitors Keycloak metrics, authentication logs and help desk tickets, and reviews the migration register weekly. The step is done when every application in scope has either completed a successful pilot or has a confirmed cutover window, and no critical trust is still unowned.
Cut over each application and retire its trust
Each application is switched to Keycloak in its assigned window by changing its SSO endpoint or metadata, then its AD FS relying party trust is disabled rather than deleted so that rollback remains possible for a defined period. The team confirms sign-in, logout and certificate rollover behavior with the application owner before closing the change. The step is done when the AD FS usage report shows no sign-ins for the trust over the agreed period.
Decommission the AD FS farm and Web Application Proxy
Once no relying party depends on AD FS, the team removes Web Application Proxy publishing rules, retires the proxy and farm servers, and removes the AD FS service account and certificates from Active Directory. Records of the trust exports, claim mappings and test results are archived for audit reference. The step is done when the farm is shut down, DNS and load balancer entries for AD FS are removed, and the archive is stored under the organization's retention policy.

What data and integrations move, and what you rebuild

An AD FS to Keycloak move splits into three groups: what stays in Active Directory and is read through federation, what Keycloak can export and import as configuration, and what you rebuild by hand. Use this split to size the work before you commit to a cutover plan for each relying party.

User identities stay in Active Directory

Keycloak does not copy your AD FS estate's user accounts out of Active Directory. It connects to existing LDAP and Active Directory servers through user federation, so passwords, group membership and account status stay where your directory team already manages them. Confirm which attributes Keycloak must read for each application's claims, and confirm that the service account Keycloak uses has the read permissions your security team approves. Plan for how Keycloak will receive the same claim values that AD FS sent.

Realm configuration exports as JSON

Realm settings can be exported to JSON with kc.sh export and imported with kc.sh import. The Keycloak documentation warns that this process has limitations as a backup and restore mechanism, and that all nodes must be stopped while it runs. Treat the export as a configuration snapshot for staging and review, not as your disaster recovery plan, and confirm with your database backup process what else must be captured.

Clients rebuilt or managed as code

Each AD FS relying party trust becomes a Keycloak client, either a SAML client or an OpenID Connect client. Keycloak's Operator manages KeycloakSAMLClient and KeycloakOIDCClient custom resources, which lets you keep client definitions in version control and review changes like other infrastructure. Where an application uses WS-Federation, the Keycloak SSO documentation does not list that protocol, so confirm its status before you plan that relying party's cutover.

MFA policies rebuilt in Keycloak

AD FS multi-factor rules, often tied to Azure MFA, Duo or a third-party adapter, do not move to Keycloak. You must define which authentication flows, second factors and conditions apply to each client and recreate them in Keycloak. Check which factors your users already enroll, how enrollment will work for them during cutover, and whether your MFA vendor offers an integration path with Keycloak before you retire the old adapter.

Certificates and load balancer rules

AD FS token signing and service communications certificates, along with the Web Application Proxy and load balancer rules that publish the farm, are not carried over. You must issue or import certificates for the Keycloak hostname, install the signing keys each relying party will trust, and rebuild the reverse proxy and health check rules. Schedule certificate changes with each application owner, because a mismatched signing certificate fails sign-in without a clear error for the user.

What to do with WS-Federation apps Keycloak does not serve

Some WS-Federation relying parties cannot move on the same schedule as the rest of the estate. In that case, the AD FS farm stays in service for those applications while the rest of the portfolio moves to Keycloak. This keeps users working during the transition, but it also means the farm, its Web Application Proxy servers and their patching cycle remain in place. Keeping the farm is a bridge, not an end state, so each retained application needs a named owner and a target date agreed in writing.

Scope the retained set: List only the relying parties that truly need WS-Federation and cannot be reworked yet, and record the reason for each.
Keep the farm supported: Confirm the Windows Server version under AD FS still receives support, since the AD FS on Windows Server 2016 page covers that deadline.
Track the cost of running both: Account for the Windows Server licenses, certificates and staff time that continue while the farm remains.
Limit new onboarding: Do not add new WS-Federation relying parties to AD FS while the exit is in progress.
Set a retirement checkpoint: Schedule a review that decides, for each application, whether it moves or is decommissioned.

Confirm with each application owner whether the app can be decommissioned or whether it genuinely depends on AD FS.

What drives cost and duration in an AD FS to Keycloak move

This table lists the factors that make an AD FS to Keycloak move larger or smaller, with a way to keep each one under control. Use it to scope a fixed-scope engagement and to decide which inputs to gather before asking for a quote. The main takeaway is that relying party count, WS-Federation share and high availability design usually matter more than the Keycloak installation itself.

Driver	Why it changes cost or effort	How to keep it down
Number of relying party trusts	Each SAML or OIDC client needs its own metadata, redirect URIs, attribute mapping and test cases, so effort grows with the count of trusts in use.	Export the trust list first and retire unused relying parties before migration starts.
Share of WS-Federation relying parties	Keycloak does not document WS-Federation as a client protocol, so these apps need a separate path, such as a different federation server or a re-platformed app.	Identify WS-Federation apps early and confirm with each owner whether SAML or OIDC is possible.
Claim rule complexity	Issuance transform rules, custom claim logic and group-to-claim conversions must be re-expressed as Keycloak protocol mappers and, where needed, custom code.	Group rules by pattern, convert the common ones once, and document the few custom rules that need review.
Number of AD forests and domains	Each forest or domain adds an LDAP or Kerberos user federation design, service accounts and attribute mapping decisions.	Confirm the user federation topology in writing and limit the scope to the domains that issue logins.
Kerberos and integrated Windows authentication	Seamless sign-in for domain-joined clients requires keytab handling, SPN configuration and browser policy changes on endpoints.	List which apps rely on Windows integrated authentication and test them in a small pilot group.
MFA and conditional access requirements	Existing AD FS MFA policies, access rules by device or network and step-up logic may need replacement with Keycloak authentication flows or another MFA product.	Write down current MFA and access rules as requirements before choosing how to rebuild them.
High availability design	Keycloak supports a single cluster that can span availability zones, and multi-cluster designs need a synchronously replicated database, which adds infrastructure and testing work.	Ask for the target availability model in the scope, and size the database replication requirement before the build starts.
Testing effort and validation	Each relying party needs functional, sign-out, token lifetime and failover tests, and assessors may expect evidence of them.	Build a shared test script per protocol and reuse it across apps.
Change windows and cutover approach	Moving relying parties in waves depends on how many change windows the business can approve and how much parallel running is allowed.	Plan cutovers in groups by application owner and agree rollback steps for each group in writing.

Questions buyers ask before moving AD FS to Keycloak

What does it cost to move AD FS relying parties to Keycloak?

The cost depends on the number of relying parties, the protocols they use, and how much claim logic must be rebuilt. Keycloak itself is licensed under Apache 2.0, so there is no license fee for the software. The recurring costs are the Linux servers or cloud instances, a supported production database from Keycloak's list, staff time to operate and patch the platform, and any support subscription you choose, such as Red Hat build of Keycloak. The one-time costs are the inventory, client re-creation, claim rule translation, testing and cutover. Ask any implementation partner for a quote that splits these into one-time and recurring lines, and confirm whether Windows Server and SQL Server licenses you retire from AD FS are counted as savings. Ask for the quote to name each relying party in scope.

How long does an AD FS to Keycloak migration take?

Duration varies mainly with the number of relying party trusts, how many are custom applications versus packaged SaaS, how many claim rules need translation, and how many business owners must test each app. Estate size matters less than the count of apps with unusual claims, certificate handling or Kerberos needs. Applications that already support OpenID Connect or SAML usually take less effort than those that need custom mappers or protocol changes. Your inventory of trusts and actual sign-in activity sets the schedule, so ask any partner to base the timeline on that written inventory and to state the assumptions behind it, including change windows and approval steps in your environment.

What does our internal team need to provide?

An outside team cannot finish the move without access to the people and records that only your organization holds. You will need to provide the AD FS trust export and claim rule definitions, a list of application owners and their test contacts, the certificates and signing keys used by each relying party, and the Active Directory service account and LDAP read access Keycloak will use for federation. Your team also needs to approve change windows, own DNS and load balancer changes, and decide who operates Keycloak after go-live. Confirm these responsibilities in the written scope so that testing and cutover are not delayed by missing access.

Can we migrate from AD FS to Keycloak ourselves?

A capable identity or platform team can do it in-house if it has time, Keycloak operating experience and a clear test plan. The work is mostly methodical: inventory each trust, re-create each SAML or OpenID Connect client, translate claim rules to protocol mappers, and test sign-in and sign-out per application. The risks are in the edges: undocumented claim rules, apps that depend on specific token contents, Kerberos or Windows integrated sign-in, and high availability design. Keycloak's high availability documentation calls for a synchronously replicated database in its supported designs, and the Operator documentation recommends manual approval for updates. If your team lacks that experience, a fixed-scope engagement with written deliverables can cover those gaps while your staff keeps ownership.

Can Keycloak serve WS-Federation apps like SharePoint?

Keycloak's Server Administration Guide documents OpenID Connect, SAML and Docker registry authentication as its SSO client protocols, and WS-Federation is not among them. Applications that rely on WS-Federation, such as some SharePoint configurations, therefore need a different plan. Options include moving the application to SAML or OpenID Connect if the vendor supports it, placing a gateway or proxy in front of the app, or keeping a WS-Federation provider for that subset. Inventory these apps first, confirm each vendor's supported protocols in writing, and treat them as a separate workstream with their own test and approval steps.

How do we run AD FS and Keycloak in parallel during cutover?

Run both identity providers side by side and move relying parties one at a time. Create the Keycloak client for an application, test it in a non-production or pilot group, then change that application's configuration to point at Keycloak while AD FS stays available for the rest. Keep AD FS trust records in place until the application is confirmed working and the rollback path has been tested. Use the sign-in activity data from your inventory to pick low-risk pilots first and to confirm that no application is still in use before its trust is removed. Keep the user source the same by using Keycloak's user federation with Active Directory, so passwords and group memberships stay in one place during the transition.

What do Keycloak's license and release cadence mean for our plan?

Keycloak is licensed under Apache 2.0, which means you can run it without a per-user license fee, but you still need to plan for your own upgrades and support. Since Keycloak 26.0, the project plans four minor releases a year and a major release every two to three years, and says breaking changes in a minor release will be opt-in. Plan for a recurring upgrade cycle, test each release against your clients and mappers in a staging environment, and decide whether you will run the community build or a supported distribution such as Red Hat build of Keycloak. Confirm the upgrade and support model in the written scope before work begins.

What should we confirm before asking for a quote?

Gather the AD FS trust inventory, the number of relying parties by protocol, the list of WS-Federation and Kerberos-dependent apps, your target hosting location, and your database and high availability requirements. Ask the provider to name the deliverables, the testing approach, the rollback plan and who operates Keycloak after go-live. DeployOpen plans, implements and hardens self-hosted platforms in your own infrastructure and works from a fixed-scope written plan, so a quote follows from the scope you agree. Ask for it to separate one-time migration work from ongoing support or upgrade retainers.

What usually goes wrong and how to prevent it

Most AD FS to Keycloak problems come from gaps in what was inventoried, what was translated and what was assumed to be backed up. The cards below cover the failure points we see most often, each with a check to run before a relying party moves or a cutover date is set.

Relying parties found after decommission

AD FS trusts often include applications nobody remembers, such as scheduled reports, partner integrations or legacy line-of-business tools. If they are only discovered after the farm is switched off, users see sign-in failures with little context. Before any decommission, pull the trust list, enable AD FS audit and usage logging for a full business cycle, and compare the active sign-ins against the inventory. Ask each application owner to confirm in writing that their app is migrated or retired.

Claim rules that do not translate

AD FS issuance rules map Active Directory attributes and claims into tokens in ways that are easy to misread. A rule that transforms group membership or builds a name identifier from a specific attribute has no one-to-one equivalent in Keycloak. Export every claim rule set per trust, write down the expected token contents, and rebuild them as protocol mappers. Then compare decoded test tokens from the old and new paths before switching the application's endpoint.

WS-Federation apps discovered late

Keycloak's documented client protocols are OpenID Connect and SAML, and WS-Federation is not among them. Applications such as SharePoint or older portals that rely on WS-Federation tokens can be found late in a project, after the Keycloak design is approved. Flag every WS-Federation trust in the inventory as a separate track, and decide early whether those apps move to another identity provider, get a SAML or OIDC change from their vendor, or stay on AD FS until they are retired.

Kerberos and Windows Integrated Auth breakage

Browser-based Windows Integrated Authentication and Kerberos-protected internal apps depend on service principal names, keytabs and domain trust, not only on SAML or OIDC. Keycloak's LDAP and Active Directory user federation covers the directory side, but the Kerberos and SPNEGO path has to be tested per application. Map every app that uses Kerberos today, confirm the SPN and keytab setup for each, and test sign-in from domain-joined and non-domain clients before cutover.

Realm export used as a backup

Keycloak exports and imports realms as JSON, and the server guide warns that this is limited as a backup and restore method and that all nodes must be stopped while it runs. Teams that treat a realm export as their backup plan often discover that secrets, sessions or some configuration are not restored as expected. Use a database-level backup for recovery, use realm exports for configuration review and migration staging, and rehearse a restore in a non-production environment before go-live.

Unplanned automatic operator upgrades

When Keycloak runs on Kubernetes through the Operator, the Operator documentation strongly recommends manual approval mode for updates, so that an upgrade does not start unexpectedly during a federation dependency change. Combined with automatic database schema migration at startup, an uncontrolled upgrade can change behavior for live relying parties. Set the Operator subscription to manual approval, schedule upgrades in a change window, and test each Keycloak release against a copy of the migrated realm first.

How the migration changes by estate size and starting point

A small AD FS estate usually has a handful of relying party trusts, most of them SAML applications for SaaS tools or internal web apps, with a single federation server and few or no proxied applications. In this case the migration is mostly a matter of re-creating each client in Keycloak, testing the sign-in path and cutting over application by application. A single Keycloak instance on a supported database can be enough for a modest user base, and the work can often be finished by a small team without a formal program.

Clients: Re-create each SAML or OpenID Connect client in a test realm, then map the claims each application actually reads.
Directory: Connect Keycloak to the existing Active Directory as a user federation provider so passwords and group membership stay where they are.
Cutover: Move one application at a time, keeping AD FS available for rollback until each application signs in reliably.
Operations: Decide who patches Keycloak, takes backups and watches certificates, since no one may own those tasks today.
Retirement: Remove unused trusts only after confirming usage with sign-in logs.

Before starting, confirm with the application owners which claims and signing certificates each service expects, because small estates often hide undocumented dependencies in a few apps.

How DeployOpen scopes and runs the migration

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For an AD FS to Keycloak move, we start with a written, fixed-scope agreement that covers relying parties, Active Directory federation and the cutover plan before any build work begins.

How we scope

Agree in writing which AD FS relying party trusts move to Keycloak and which stay or retire.
Confirm the SAML and OpenID Connect clients, claim rule translations and mappers in scope.
Define how LDAP or Kerberos federation with your existing Active Directory will work, and which WS-Federation apps are excluded.

How we build

Deploy Keycloak in your cloud account, data center or air-gapped network on a supported production database.
Re-create each client, test claims and group mappings against the original AD FS behavior, one relying party at a time.
Configure high availability, backups, upgrade approval and metrics so operations can run the platform after handover.

How we hand over

Deliver documentation of each client, mapper, federation link, runbook and rollback step.
Provide a cutover record per relying party, showing which applications moved, when, and what was tested.
Give your team evidence for compliance assessments, while independent auditors remain responsible for any audit or certification.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work ends.
Plan Keycloak minor and major upgrades with your team, using the documented upgrade process and a staging environment.
Ask for a written scope and quote to confirm timelines, responsibilities and any retainer terms before work begins.

Migrate from AD FS to Keycloak