Migrate from AD FS to authentik

Migrating from AD FS to authentik: the short answer on effort and risk

authentik fits a smaller AD FS estate with SAML and OIDC relying parties, but only if you accept that WS-Federation needs the Enterprise tier. Modern SAML and OIDC applications can be moved to authentik's free open-source edition, which covers OIDC, SAML, LDAP and proxy authentication. Any application that depends on WS-Federation, such as SharePoint, requires authentik Enterprise, because the WS-Federation provider is labeled an Enterprise feature and supports only the SAML2 token type. Confirm that requirement with authentik's current WS-Federation provider documentation and its pricing page before you count those applications as covered by the free edition. In most organizations, an internal platform or identity team does the work, often with an implementation partner for the design, the cutover plan and the hardening. The main effort drivers are the number of relying party trusts, how many of them rely on custom claim rules that must become authentik property mappers, how many use Active Directory as the user source, and how much testing each application needs before cutover. Inventory those trusts first, using the output to size the work. Expect the Web Application Proxy to need its own track: authentik's proxy provider or an alternative such as Pomerium must reproduce pre-authentication, header-based and Kerberos access patterns, along with the certificate and load balancer behavior AD FS imposed. The risks are concentrated in the WS-Federation applications, the Web Application Proxy cutover and the day-two operating model. Plan a parallel run for each application, a rollback path that keeps AD FS available until users have been verified, and a named owner for authentik's security releases. Ask your implementation partner to confirm the authentik edition, the Active Directory integration pattern and the proxy design in writing before any production work begins.

Which AD FS capabilities map to authentik and which need rework

This table maps each AD FS capability to its authentik equivalent and marks it as clean, needs rework or gap. Read the status column first, then the notes on the WS-Federation provider, which is the main place where an estate with SharePoint or other WS-Federation applications will hit a licensing or token-type limit.

AD FS capability	authentik equivalent	Status and notes
SAML relying party trusts	SAML providers and applications in authentik, with bindings, signing certificates and attribute mappings set per application	Clean. Re-create each trust, then confirm the entity ID, ACS URL and signing certificate with the application owner before cutover.
OIDC relying party trusts	OAuth2/OIDC providers and applications, with scopes and claims set through property mappings	Clean for modern apps. Check redirect URIs and token lifetimes against each app's own configuration.
WS-Federation relying party trusts (SharePoint and similar)	WS-Federation provider, an Enterprise feature that supports only the SAML2 token type	Gap on the open-source core. Requires authentik Enterprise, and apps that need a SAML 1.0 token will not work. Confirm each app's token requirement first.
WS-Federation with Microsoft Entra ID	Not supported. authentik documents that Entra ID requires a SAML 1.0 token	Gap. Keep Entra ID trusts on AD FS or move them to a SAML or OIDC configuration the target supports. Confirm with Microsoft's current guidance.
Claim rules (issuance and transformation)	Property mappings and policy bindings, rewritten as expressions per provider	Needs rework. Claim rules are not imported as-is, so each rule must be translated and tested against a sample sign-in.
Active Directory authentication	LDAP sources that read users and groups from Active Directory, used for password and group lookups	Needs rework. Confirm how Kerberos sign-in, group nesting and password changes behave in your domain before users move.
MFA and conditional access	Authentication flows and policies, with MFA stages configured in the open-source core	Needs rework. Rebuild each access rule as a policy and test enrollment, recovery and step-up behavior per application.
Web Application Proxy publishing	Proxy provider with an outpost deployed next to the protected applications	Needs rework. Outposts replace WAP publishing rules, but header and Kerberos-based apps need individual testing.
Certificate and token signing management	Certificates imported or generated in authentik, bound to each provider	Needs rework. Plan renewal dates and notify relying parties before each signing certificate changes.

Which parts of the migration need the Enterprise license

The free authentik edition covers the core of an AD FS replacement, but not every feature you may rely on. The open-source core is MIT licensed, while the directory under authentik/enterprise/ falls under a separate enterprise license. The free edition supports OIDC, SAML, LDAP, SCIM, RADIUS, Kerberos and proxy authentication, but support is community only, through the Discord server. Before you commit, list which of your relying parties depend on features in the enterprise directory, and confirm the license terms in the authentik LICENSE file against your legal team's reading.

The WS-Federation provider is the decision point for most AD FS estates. authentik labels it an Enterprise feature, supports only the SAML2 token type, and documents it as unsupported with Microsoft Entra ID because Entra ID requires a SAML 1.0 token. If SharePoint or another WS-Federation application expects a SAML 1.0 token, the free edition cannot serve it, and the Enterprise license alone may not solve it. Test each such application against the SAML2 token type in a non-production tenant, and plan a separate path, such as a different relying party configuration or keeping that application on AD FS until it is retired, for any app that fails.

Budget from the current authentik pricing page, which lists Enterprise at $5 per user per month billed annually plus $0.02 per external user per month, and Enterprise Plus starting at $20k annually. Enterprise Plus adds dedicated support with SLAs, multi-instance support and FIPS compliance. Ask the vendor how the per-user count is measured for your directory, whether service accounts count, and whether prices change at renewal, because these terms drive the recurring cost.

What data and integrations move, and what you rebuild by hand

An AD FS exit moves identities, groups and trust material in different ways. Users and groups can be sourced from Active Directory, while relying party trusts, claim rules and Web Application Proxy publishing rules are re-created in authentik and tested one by one.

User identities through an Active Directory source

authentik can read users from your existing Active Directory domain through an LDAP source, so accounts stay where they are managed today. Confirm which attributes authentik maps (such as userPrincipalName, mail and sAMAccountName), how account disablement is reflected at login, and whether password changes still happen in Active Directory. Test sign-in for disabled, locked and expired accounts before any relying party is switched over.

Group membership and authorization

AD FS claim rules often emit group claims that applications use for role decisions. In authentik, groups synced from Active Directory can be mapped to property mappings that populate the claims each application expects. Nested groups, group names that changed, and groups used only in AD FS claim rules need an explicit inventory so no application loses a role on cutover.

Relying party trusts re-created as providers

AD FS relying party trusts do not import directly into authentik, so each one becomes a SAML, OAuth2/OIDC or WS-Federation provider with its own application entry. Record the entity ID or client ID, redirect and assertion consumer URLs, signing requirements and attribute names from the trust export, then re-create and test it. WS-Federation providers are an Enterprise feature and support the SAML2 token type only.

Signing certificates and token settings

Relying parties validate the signatures on tokens, so each replacement provider needs a signing certificate that the application already trusts or that you deliberately re-register. Plan a planned metadata or certificate exchange per application, and check token lifetime, encryption and algorithm settings against what each partner expects. Expiry dates on current AD FS token-signing certificates should be recorded before cutover.

Web Application Proxy rules rebuilt as outposts

Each Web Application Proxy publishing rule, including pre-authentication settings, backend URLs and header behavior, must be re-created as an authentik proxy provider served by an outpost. Outposts run next to the applications they protect, so their network placement, certificates and load balancer rules need design work. Test header and Kerberos-dependent apps separately, since they behave differently from standard browser sign-in.

Deployment components to stand up

A self-hosted authentik estate needs a server container, a worker container and PostgreSQL, which stores all configuration and data except uploaded files. Plan backups of the database, a tested restore, and the supported release line before you move production sign-in. Confirm the sizing for your user count and high availability requirements with the vendor documentation and your own load tests.

Migration sequence from inventory to decommission

This sequence moves AD FS relying parties to authentik one application at a time, keeping AD FS running until each replacement is proven. It ends with AD FS and Web Application Proxy switched off, with a record of every trust that was moved or retired.

Inventory relying parties and actual usage
Export every AD FS relying party trust and claim rule set, record the protocol each one uses, and pull the sign-in activity for each trust over a period long enough to include month-end and seasonal jobs. Owners of each application confirm whether it is still needed, who depends on it, and which ones use WS-Federation. The output is a register with one row per application, its protocol, its owner, its last-used date and a decision to migrate, retire or keep on AD FS for now.
Deploy authentik on Docker Compose or Kubernetes
Stand up authentik with PostgreSQL in a non-production environment using the Docker Compose guide or the Kubernetes installation guide, depending on the platform your team already operates. Compose is positioned for test setups and small-scale production, and its documented baseline of at least 2 CPU cores and 2 GB of RAM is a starting point for a test environment only, so size production from your own load tests. Confirm the server, worker and PostgreSQL containers come up and that the admin console is reachable only through your internal network. The output is a working test instance with backups configured for the database.
Connect Active Directory as a user source
Configure the Active Directory source in authentik using a dedicated, read-only bind account, and map the attributes your applications need, such as the user principal name, mail and group membership. Run a sync on a test OU first and check that disabled accounts and group changes are reflected as expected. Agree with the directory team who owns the bind account and its password rotation. The output is a verified sync report showing the user and group counts that match the directory, with any mismatches explained.
Pilot one low-risk SAML or OIDC application
Choose a single application with a small user group, a SAML or OIDC protocol and a clear rollback path, then recreate its provider and application in authentik and rebuild the claim mappings from the AD FS rules you recorded. Test sign-in with a pilot group, including logout, session timeout and the claims the application reads. Keep the AD FS trust unchanged so users can switch back. The output is a signed-off test record for that application with its claims compared side by side against AD FS.
Run both identity providers in parallel
Keep AD FS and authentik serving production sign-ins side by side, moving applications in small waves and monitoring authentication logs in both systems. Watch for failed sign-ins, claim mismatches and certificate or redirect URI errors, and confirm that the authentik logs and alerts reach your monitoring. Confirm that PostgreSQL connection counts stay within limits, since the authentik 2025.10 release notes warn of higher connection counts after upgrading. The output is a log review record per wave showing no unexplained failures before the next wave starts.
Cut over each application in stages
For each application in the register, schedule a change window with its owner, update the relying party's endpoints or metadata to point to authentik, and retain the AD FS trust disabled but present for a rollback period that the owner and security team agree. For WS-Federation applications such as SharePoint, confirm before cutover that the authentik WS-Federation provider is covered by your licensing, because it is an Enterprise feature that issues only SAML2 tokens. Record the cutover date, the owner's sign-off and the rollback test result. The output is an updated register where each application shows its new provider and its sign-off.
Replace Web Application Proxy and decommission AD FS
Move each application previously published through Web Application Proxy onto an authentik outpost or a proxy provider, retest pre-authentication and any header or Kerberos-based access, and confirm that the load balancer and firewall rules previously built for AD FS are either removed or documented. Once no active trusts remain, disable the AD FS and proxy servers, export the final configuration and logs for your records, and retain them according to your retention policy before removing the servers. The output is a decommission record that lists every retired server, the retained evidence and the owner who approved removal.

How to run both identity providers in parallel and cut over safely

The safest way to leave AD FS is to move one relying party at a time. Keep AD FS running as the fallback, point a single application at authentik, and treat that application as proven only after real users have signed in through it across normal and failure paths. Each relying party should have its own cutover record that names the authentik provider and application, the AD FS trust it replaces, the claims the application expects, and the rollback step. Do not retire a trust until the application has run on authentik for a full business cycle without a support ticket about login.

AD FS usually imposed rules that never appear in an application's own settings. Check the DNS records for the federation service name, any split-brain DNS entries, and the load balancer rules that sent traffic to AD FS or Web Application Proxy, including session affinity and the paths and headers those rules forwarded. Before changing a record, lower its TTL in advance so a rollback takes effect quickly. Certificates need the same care: list the token-signing and service certificates, the expiry dates of each, and the certificate each relying party trusts, because a renewal on either side can break sign-in silently. Confirm with each application owner how it validates signatures and which metadata URL or certificate it has pinned.

Before choosing an authentik version for production, check the authentik security policy, which lists 2026.5.x and 2026.8.x as the supported versions receiving security fixes, and the project's commitment to announce security releases at least 24 hours in advance. Then compare that against the authentik releases page on GitHub to confirm the version you plan to run is current and supported on the date you plan to go live, and plan a maintenance window for upgrades. Write the rollback sequence down: restore the DNS or load balancer record, re-enable the AD FS trust, and confirm the application signs in. Test that sequence in a non-production environment before the first live cutover.

What drives the cost and duration of an AD FS to authentik move

This table lists the drivers that change the cost and effort of moving from AD FS to authentik, why each one matters, and how to keep it down. Use it to check that a quote itemizes each driver against your own estate rather than a single lump sum. The main takeaway is that the Enterprise license decision and the count of WS-Federation apps often matter more than raw user numbers.

Driver	Why it changes cost or effort	How to keep it down
Relying party count and protocol mix	Each SAML, OIDC or WS-Federation relying party needs its own provider, application, mappings and test cycle. Most of the effort scales with the number of trusts, not the number of users.	Inventory every trust first and retire unused ones. Group similar SAML or OIDC apps so they share a test script.
WS-Federation applications such as SharePoint	The WS-Federation provider is an Enterprise feature and issues only SAML2 tokens. Apps that need SAML 1.0 tokens, including Entra ID-linked flows, need a different design or a different server.	Count WS-Federation apps separately during the inventory. Confirm each app accepts SAML2 tokens with the vendor or the app's own documentation before scoping.
Enterprise license decision	Enterprise adds features such as the Microsoft Entra ID integration, privileged access management, password history and ticket-based support. These are licensed on the pricing page, so the quote must show which features the design needs.	List required features against the open-source edition before requesting a quote. Ask the vendor for current pricing in writing, since the pricing page is the source.
Active Directory topology	Multiple forests, domains or sites change how the LDAP source is configured, how groups map to authentik and how service accounts are secured. Trusts between forests add test cases.	Document forests, domains and the groups AD FS claim rules use today. Confirm the directory source configuration with a lab copy before production.
Web Application Proxy publishing count	Each published application that WAP served needs a replacement path through an outpost or proxy provider, including pre-authentication and any header or Kerberos behavior.	Export the list of published apps and sort them into modern SAML or OIDC, header-based and Kerberos groups. Retire apps that no longer need external access.
Certificates and load balancer rules	Signing certificates, metadata endpoints, TLS termination and the rules AD FS imposed on the load balancer each need re-issuing, re-pointing and re-testing with every relying party.	Inventory certificates and their expiry dates. Plan the cutover so each relying party changes its trust once, with the old AD FS endpoint kept for rollback.
Testing and user acceptance effort	Each application needs login, logout, MFA, group-based access and session tests, often across browsers and client types. Failed tests return work to design.	Write a test script per protocol pattern and reuse it. Ask for the test scope to be listed as a separate line in the quote.
Staff skills in authentik	Teams that already run Linux, PostgreSQL and containers will operate authentik with less onboarding. Teams new to these tools need training and more vendor or partner support during the first months.	Assess current skills against the Docker Compose or Kubernetes install guides. Ask for knowledge transfer and runbooks in the quote, so operations do not depend on one person.

What usually goes wrong and how to prevent it

Most failed AD FS exits on authentik come from a few predictable gaps: edition limits, rules that never got translated, and relying parties nobody remembered. The cards below pair each risk with a check to run before cutover, so the migration plan covers what AD FS quietly did for you.

Assuming WS-Federation apps work on free

The WS-Federation provider is labeled an Enterprise feature, so SharePoint and other WS-Federation relying parties cannot be served on the Open Source edition. It also supports only the SAML2 token type, and it is documented as unsupported with Microsoft Entra ID, which requires a SAML 1.0 token. Confirm the edition and token type for every WS-Federation app before you commit to a design. Check this against the provider documentation and the pricing page, and ask the vendor to confirm current terms in writing.

Missing claim rule logic in re-creation

AD FS claim rules often hold conditional logic, transformations and group-based issuance that teams copy as simple attribute mappings. In authentik, the equivalent work is property mappings and policy bindings, and a missing condition can silently send extra or wrong claims to an application. Export each relying party's rules and write down every condition before rebuilding it. Test each application with a user from every group that receives different claims.

Forgotten low-usage relying parties

Some AD FS trusts serve a quarterly report, a legacy finance tool or a supplier portal and see little traffic. These are often missed when the migration plan is built from the most used apps, and they break when AD FS is switched off. Pull the full trust list and a usage history before deciding the scope. Treat any trust with no recent sign-ins as a question for its owner, not as something to drop.

PostgreSQL connection growth after upgrades

authentik 2025.10 removed Redis and moved caching, tasks, sessions and WebSocket functions to PostgreSQL, and its release notes warn of roughly 50% more PostgreSQL connections after upgrading. A database sized for the old footprint can run out of connections under normal login load. Size the connection limit and pooling before upgrading across that release, and watch connection counts during the first week of production.

Untested proxy and header-based apps

Web Application Proxy handled pre-authentication, header passing and some Kerberos-based apps for AD FS users, and those behaviors do not carry over automatically to the authentik proxy provider. Apps that trust a header or expect a specific load balancer rule can fail in ways that look like login problems. Build a test matrix for each proxied app covering the headers it reads, its timeouts and its certificate chain, and run it through the outpost before cutover.

Unplanned version upgrades

authentik names releases by year and month, and only some lines receive security fixes at a given time, so a farm left on an unsupported version can fall out of patching without warning. Upgrades that happen under pressure, rather than on a schedule, tend to skip the release notes that matter. Record the supported versions from the security policy, subscribe to the release feed, and schedule upgrades in a test environment first.

How the migration changes by estate size and starting point

A small AD FS estate with a handful of SAML and OIDC relying parties is the simplest case for authentik. These applications map directly to authentik's SAML and OIDC providers, and a single authentik deployment can usually hold the whole set. The work is mostly inventory, re-creating each provider, and testing sign-in with each application owner. Compose is positioned by the project for test setups and small-scale production, so a single-node design can fit a small estate if your availability needs allow it.

Inventory first: List each relying party trust, its protocol, the claims it expects and whether anyone still signs in through it.
Re-create providers in a test instance: Build each SAML or OIDC provider and application in authentik, then verify attribute and group mappings against the original claim rules.
Connect the Active Directory source: Point authentik at your directory so users and groups resolve without duplicating accounts.
Run parallel sign-in: Ask owners to test in both systems, then switch DNS or application settings one application at a time.
Decommission in stages: Keep AD FS available for a rollback window before removing relying parties.

Before starting, confirm with your platform team which authentik release line you will follow, since the project publishes security fixes only for named supported versions.

Questions buyers ask before moving from AD FS to authentik

What does it cost to run authentik compared with AD FS?

Running authentik costs more than the software line item suggests, because the cost sits in servers, PostgreSQL, operations and, if you need them, Enterprise features. The open-source edition is free to download under the MIT license for the core code, but it comes with community support only. The authentik pricing page lists Enterprise at $5 per user per month billed annually, plus $0.02 per external user per month, and Enterprise Plus starting at $20k annually. Enterprise is the edition that adds the WS-Federation provider and Microsoft Entra ID integration, so check which features you need before comparing totals. Ask any quote to separate one-time work (design, migration, testing) from recurring items (subscription, hosting, patching, on-call support). Compare that against your current AD FS costs, which include Windows Server licenses, Web Application Proxy servers and certificate work.

How long does an AD FS to authentik migration take?

The duration depends mainly on how many relying party trusts you have, how many of them use WS-Federation, and how much the claim rules rely on custom logic. Each application needs its provider configured, tested with real users, and cut over, so the count of applications usually matters more than the size of the directory. Other drivers include the number of Active Directory forests and domains that authentik must read, how many publishing paths currently run through Web Application Proxy, and whether change windows or certificate renewals constrain the schedule. The timeline should be agreed in writing as part of a fixed-scope plan, with milestones for inventory, pilot, wave cutovers and decommissioning. Ask the provider to base the estimate on your inventory export rather than on a generic figure.

Can our internal team migrate to authentik without outside help?

A capable internal team can do the work, provided it has people who understand the identity protocols, Active Directory, and the applications being moved. The core skills are SAML and OpenID Connect configuration, LDAP source setup, PostgreSQL operations, reverse proxy and certificate management, and testing of each relying party. Teams that have not run an identity platform before often find the application testing and the cutover coordination take longer than the configuration itself. Many organizations split the work: internal staff own the applications and the business decisions, while an implementation partner handles the authentik deployment, hardening and runbooks. DeployOpen implements, hardens and documents self-hosted platforms inside your own infrastructure under a written scope, so you can choose how much of the work to hand over.

What does our team need to provide for the migration?

The migration needs access and information that only your organization holds. Expect to provide an export of the AD FS relying party trusts with their protocols, claim rules and certificates, plus usage data showing which applications are still active. You will need an owner for each application who can confirm expected sign-in behavior and sign off on testing. The team must also supply hosting capacity inside your environment, such as virtual machines or Kubernetes, a PostgreSQL service, DNS names, TLS certificates, and a service account with read access to Active Directory. Change management, maintenance windows and a rollback plan should come from your side too. Ask the provider to list these inputs in the written scope so gaps appear before work starts.

Can SharePoint move from AD FS to authentik?

SharePoint can move only if the authentik edition and token type match what SharePoint expects. authentik has a WS-Federation provider aimed at applications such as SharePoint, but it is an Enterprise feature and supports only the SAML2 token type. The authentik documentation also states that it is not supported with Microsoft Entra ID, which requires a SAML 1.0 token. Before committing, confirm with the SharePoint farm owner which token type and claims the farm uses, test a non-production site, and verify the result with authentik's current documentation. If the farm cannot accept SAML2 tokens, the application may need a different path, and that decision should be recorded in the plan.

How do we keep AD FS running during the transition?

Run both identity providers in parallel and move applications in waves, so AD FS stays authoritative for everything not yet cut over. Each relying party gets a test path in authentik first, then a controlled switch of its DNS or metadata, with the old AD FS trust left in place until the new one has proven stable. Keep Web Application Proxy publishing the applications that have not moved, and plan the authentik outpost for those that have. Retain the AD FS configuration export and certificates so that rollback is a metadata change rather than a rebuild. Decommission AD FS only after logs show no active sign-ins through the old trusts for an agreed period. Confirm the exact rollback steps with your security and operations teams before the first wave.

What should we check first to see if authentik fits our estate?

Start with the protocol and application inventory, because that decides whether authentik covers your estate without gaps. List every relying party, noting whether it uses SAML, OpenID Connect or WS-Federation, and whether it needs Kerberos, header-based access or Entra ID integration. authentik's free edition covers OIDC, SAML, LDAP, SCIM, RADIUS, Kerberos and proxy authentication, while WS-Federation and Entra ID integration require Enterprise. Next, check the operating model: authentik runs as a server container, a worker container and PostgreSQL, and its 2025.10 release notes say it no longer uses Redis. Confirm that your team can run PostgreSQL, patch the containers on the supported releases, and monitor the connection count, which the release notes warn rises after upgrading. Use the authentik security policy to confirm the versions that currently receive security fixes.

How DeployOpen scopes, runs and supports the migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted authentik inside your own infrastructure. Each AD FS to authentik migration starts from a written scope that lists the relying parties, the Active Directory sources and the outposts that will be moved.

How we scope

Inventory every AD FS relying party trust, its protocol, claim rules and certificates before any design work starts
Separate SAML and OIDC applications from WS-Federation applications, since WS-Federation requires authentik Enterprise and the SAML2 token type
Agree in writing which Active Directory sources, MFA methods and Web Application Proxy replacements are in scope

How we build

Deploy authentik on Docker Compose or Kubernetes with PostgreSQL in your environment, sized to the scope agreed in writing
Map each relying party to an authentik provider and application, then test sign-in, claims and logout in a staging instance
Configure outposts to replace Web Application Proxy publishing for internal apps and document the load balancer and certificate rules

How we hand over

Deliver the architecture, configuration and runbooks for upgrades, backups and PostgreSQL maintenance
Document each migrated application with its cutover steps, rollback path and owner sign-off
Provide evidence of controls and configuration to support your own compliance assessments, which independent auditors perform

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins
Ongoing support, version upgrades and continuous testing are available as a retainer after handover
Ask for a quote that itemizes implementation, Active Directory integration, testing, documentation and any authentik Enterprise licensing you need