Why an AD FS replacement must still work when Entra ID is off the table
If your AD FS farm cannot move to Entra ID because federation must stay in-country, under your own control or inside an isolated network, a self-hosted federation server can take over the role, provided it meets that constraint in full. Keycloak, authentik and WSO2 Identity Server are the open-source candidates this page compares, and each can run inside your own data center, cloud account or air-gapped segment. The decision does not turn on whether a product can federate at all. It turns on two things: which relying party protocols you must keep serving without change, especially WS-Federation for older Microsoft applications, and who will operate the platform after cutover, including patching, certificates, database backups and upgrades.
Start by writing down the constraint in terms an auditor or data protection officer would accept. For a residency or sovereignty requirement, list where authentication logs, user attributes, tokens and the database will physically sit, and who holds administrative access to those systems. Any hosting arrangement that places identity data under a foreign provider's control needs its own transfer and access assessment before you select a product, because the choice of platform does not settle that question by itself. For an isolated network, confirm which components must reach the internet (for example, a time source or certificate revocation endpoints) and which must not. These answers narrow the field before any protocol testing starts.
DeployOpen plans, implements, integrates, hardens and documents self-hosted identity platforms inside the client's own infrastructure, and can support the evidence collection for a compliance assessment. DeployOpen does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work. Expect the scope to be agreed in writing before work starts, with the relying party inventory, protocol coverage and operating model fixed in that document.
What a self-hosted federation server must cover
Moving off AD FS without Entra ID means the replacement must carry the same federation duties inside your own network. The cards below cover the protocols relying parties expect, the directories users come from, the MFA and availability design, and the data location rules that decide where the server can run.
Protocol coverage for every relying party
Inventory each relying party by protocol before choosing a server. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, so SAML and OIDC applications have a direct path. WS-Federation is the gap to plan for: Keycloak does not serve it, while authentik lists a WS-Federation provider in its provider types, with its licensing and token limits to confirm before you depend on it. Apps that only speak WS-Federation, such as some SharePoint setups, need a named owner and a decision.
Existing Active Directory and LDAP sources
Most AD FS estates authenticate against Active Directory, so the replacement must read the same user objects without a forced password reset campaign. Keycloak has built-in user federation with existing LDAP and Active Directory servers. authentik offers LDAP and Active Directory sources. Confirm how group membership, attribute mapping and password validation work against your forest before cutover, and decide whether the directory stays the source of truth.
MFA and step-up policy
AD FS usually enforces MFA through Azure MFA, a third-party adapter or a custom provider, so that logic has to be rebuilt in the new server. Check which second factors your users hold today, how conditional access by application or network location will be expressed, and whether the MFA service is also kept on-premises. Treat MFA as a separate design item from federation, with its own test cases and fallback process.
High availability and database durability
AD FS farms are only as available as their load balancers, proxies and SQL configuration, so the replacement needs an equally explicit availability plan. Keycloak documents a clustered design that needs a synchronously replicated database, and its realm export is documented as a limited backup mechanism that requires all nodes stopped. Plan database backups, node failure tests and a documented restore path, and confirm the supported database versions for your platform.
Where personal data is stored and accessed
Under GDPR Article 44, any transfer of personal data to a third country, including remote access from one, must meet Chapter V conditions. EDPB Guidelines 05/2021 treat even on-screen display for support as a transfer, so vendor support staff, cloud hosting and log shipping all count. Confirm where logs, backups and admin consoles are reachable from, and document the answer before choosing a hosting location.
Third-country legal access exposure
Even when servers sit in your country, a provider subject to foreign law can receive orders that conflict with EU requirements. EDPB Recommendations 01/2020 say that where a destination's public authority powers go beyond what is necessary and proportionate, no effective technical supplementary measure can be envisioned. Ask every vendor and hosting provider which foreign laws reach their operations, and record the assessment before engaging them.
Where Entra ID meets the constraint and where it does not
An in-country or isolated requirement conflicts with a cloud identity service when identity data leaves the jurisdiction or can be reached from outside it. Under GDPR Article 44, every transfer of personal data to a third country must meet Chapter V, including onward transfers. The EDPB Guidelines 05/2021 treat remote access from a third country as a transfer, even when data is only displayed on a screen for support or administration, and treat storage in a cloud outside the EEA as a transfer too. A directory held in a foreign region, or administrators in another country viewing user records, can therefore trigger the rule even when the service is nominally hosted in Europe.
The harder question is access in the clear. EDPB Recommendations 01/2020 state that where a provider needs to read data unencrypted and the destination's public authority powers go beyond what is necessary and proportionate, the EDPB cannot envision an effective technical supplementary measure. Two further facts widen the exposure check. Under 18 U.S.C. 2713, US providers must preserve or disclose data in their possession, custody or control whether it sits inside or outside the United States. The EU-US Data Privacy Framework decision is under appeal as Case C-703/25 P, after the General Court upheld it in September 2025. GDPR Article 48 also limits recognition of third-country disclosure orders to those based on an international agreement. Whether any of this applies to your tenant, support model and subprocessors is a legal determination, so confirm your position with counsel before accepting or rejecting Entra ID.
Before deciding, build a map of identity data for each relying party: directory attributes, sign-in and audit logs, MFA records, and the regions where each is stored and administered. Ask Microsoft in writing which data regions apply to your tenant, which roles can access data from outside those regions, and how support access is granted, then check those answers against your contract. If counsel concludes that the constraint is a legal duty, the exit path is self-hosted federation. If the exposure is acceptable, Microsoft's recommended move to Entra ID remains the simpler option, and the rest of this topic can focus on relying party sequencing instead.
Which open-source servers fit an on-premises AD FS replacement
Keycloak is the broadest fit for a general on-premises AD FS replacement because it is licensed under the Apache License 2.0 and supports OpenID Connect, OAuth 2.0 and SAML 2.0 in one server. It also has built-in user federation with existing LDAP and Active Directory servers, so the directory can stay where it is while Keycloak issues the tokens. It is a Cloud Native Computing Foundation incubating project, which matters to teams that want a vendor-neutral governance model.
- Protocol coverage: SAML 2.0 and OIDC clients are supported natively. WS-Federation is not listed among Keycloak's supported protocols, so inventory any WS-Federation relying parties before committing.
- Active Directory federation: Existing LDAP and AD sources are configured as user federation, which keeps accounts in the current directory during the transition.
- High availability: Three designs are documented, including a single cluster across availability zones. Both supported designs need a synchronously replicated database.
- Kubernetes: The Keycloak Operator manages Keycloak and client custom resources. Use manual approval mode for operator updates.
- Database: PostgreSQL 14 to 18 is supported for production, along with several other engines.
Confirm with your Keycloak support provider or the project which distribution and support tier fits your data residency and patching needs, and whether Red Hat build of Keycloak is required for your compliance evidence.
authentik suits smaller estates that want one self-hosted product for SSO, LDAP, RADIUS and proxy access. Its core is MIT licensed, so the open-source edition can run entirely inside your network. Its architecture is simpler than a clustered Java deployment: a server container, a worker container and PostgreSQL, with Redis no longer used since the 2025.10 release.
- Open-source scope: The free edition supports OIDC, SAML, LDAP, SCIM, RADIUS, Kerberos and proxy authentication, with community support only.
- WS-Federation gap: Per the authentik pricing page, WS-Federation is an Enterprise feature, along with Microsoft Entra ID and Google Workspace integrations. Confirm the exact edition and terms for any relying party that depends on it.
- Redis removal: Version 2025.10 moved caching, tasks and sessions to PostgreSQL and warned of roughly 50% more PostgreSQL connections after upgrading, so size the database accordingly.
- Small production: The Docker Compose guide positions Compose for test setups and small-scale production, with at least 2 CPU cores and 2 GB of RAM as the stated baseline. Larger estates should plan for Kubernetes.
- Security support: Only the 2026.5.x and 2026.8.x lines receive security fixes, and releases are announced at least 24 hours in advance, so plan a patch window.
Ask the vendor which Enterprise edition, support tier and FIPS or multi-instance options apply to your environment before relying on the open-source edition for regulated workloads.
WSO2 Identity Server fits AD FS estates with many WS-Federation relying parties, since it supports WS-Federation alongside SAML, OIDC and SCIM. That protocol coverage is the main reason to evaluate it when relying parties such as legacy line-of-business or SharePoint-style applications cannot be moved to SAML or OIDC quickly. Active Directory can be used as a user store, so the directory remains in the existing location.
- Protocol breadth: WS-Federation, SAML, OIDC and SCIM are all in scope, which reduces the number of protocol translations during migration.
- User store: Active Directory can serve as the user store, keeping identities in place while WSO2 handles authentication.
- Build choice: The open source build and a WSO2 subscription are both options. Compare what support, patching and security advisories each includes before deciding.
- Operations: Expect a heavier platform than a container-based server. Plan for the Java runtime, database and clustering skills your team will need.
- Licensing: Do not assume terms for the open source build. Request the current license and support terms in writing from WSO2 before scoping.
Verify the exact WS-Federation features your relying parties need against WSO2's documentation, and test each application against a non-production instance before selecting this server.
How to sequence relying party moves without a big-bang cutover
The sequence moves relying parties in small, verified groups, so the AD FS farm keeps serving every application until its replacement has proven itself on each protocol. Each group leaves a working rollback path until it is confirmed in production.
Inventory every relying party trust and its real usage
The AD FS administrator lists every relying party trust, its protocol (SAML 2.0, WS-Federation or OpenID Connect where present), its claim issuance rules, its certificates and its signing and encryption settings. Use Microsoft's migration readiness tooling and the AD FS activity reports to separate trusts that carry sign-ins today from stale entries that nobody uses. The inventory is finished when every active trust has an owner, a business contact and a documented sign-in count over a period the owners agree is representative, such as a month-end close or a seasonal peak.
Group relying parties by protocol and risk
Sort the active trusts into groups by protocol, by data sensitivity and by how hard each application is to roll back. Typical groups are modern SAML and OIDC applications, WS-Federation applications, and applications that depend on Kerberos or integrated Windows authentication. Mark which applications have a vendor-supported way to change the identity provider and which need code or configuration work. Agree the group order with the application owners and the security team before any change is made, and record the order in the migration plan.
Stand up the replacement in the isolated environment
Deploy the chosen server (Keycloak, authentik or WSO2 Identity Server) inside the isolated network, in-country or in the data center that the residency requirement names, using the production database and high availability design your standards require. Keep the AD FS farm running on its existing servers in the same network. The new platform is ready when it passes a health and backup test, its administrators are trained, and its certificates, time sources and logging feed the monitoring stack. Confirm each product's supported database versions and high availability design against its current documentation before building.
Connect the new platform to Active Directory as a user source
Configure the new identity provider to read users and groups from the existing Active Directory domain through LDAP federation, using a read-only service account with the minimum rights needed. Map the attributes that claim rules currently use, such as the user principal name, email and group memberships, and confirm that both systems return the same values for a sample of test accounts. Password validation, account lockout and MFA behavior should be tested for at least one account in each relevant group. This step is complete when a test user can authenticate against the new platform with the same directory identity they use on AD FS.
Pilot one low-risk SAML or OIDC application
Choose one active, low-impact SAML or OIDC application with a responsive owner and a test tenant. Re-create its client on the new platform, copy the attribute and claim mappings from the AD FS trust, and run the sign-in path for a small set of pilot users while AD FS keeps issuing tokens to everyone else. Compare the issued claims and the application's access decisions between the two systems. The pilot passes when the application owner signs off, the claims match the inventory, and users can sign in and out without help desk tickets for an agreed observation period.
Move each group and keep its rollback path
Migrate the remaining SAML and OIDC applications group by group, changing the relying party's identity provider endpoint or metadata in one group at a time. Leave the AD FS trust for each application in place but disabled from the group's point of view only after the owner confirms success, and keep the previous metadata and configuration so the change can be reversed. Record each cutover, its owner, its verification result and the rollback steps in the change log. A group is verified when sign-in succeeds across the agreed user population and the monitoring shows no unexplained failures.
Move WS-Federation applications last
Leave WS-Federation relying parties, such as SharePoint or other applications that depend on the WS-Federation passive profile, until the SAML and OIDC groups are verified. Check that the chosen platform supports WS-Federation for each application, and confirm any licensing or feature limits with the vendor before committing, because support for this protocol varies between products and editions. For applications that cannot move, keep a small AD FS farm running on its own support schedule and document the retirement date as a risk. The step is complete when every WS-Federation application either has a verified replacement or a signed exception with a retirement plan.
Decommission AD FS only after the final verification
Retire the AD FS farm and its Web Application Proxy servers only after every relying party has either moved or has a signed exception, and after a defined period of quiet monitoring shows no sign-ins routed to AD FS. Export the final configuration and keep it under the retention rules your auditors expect, then remove the servers and certificates according to the change process. Ask the auditors and your compliance lead to confirm which evidence they need for the change. The step closes when the decommissioning record shows that every application's sign-in path was verified on the new platform.
Deploying the chosen server inside your own boundary
Start by fixing where the identity server runs before anyone installs it. Place it in your own data center or in a cloud account that sits in the country your data rules require, and confirm that the database, backups, logs and any metrics endpoints stay in that same boundary. Keycloak documents a set of production settings in its configuration guide, and authentik runs as a server container, a worker container and PostgreSQL, so every one of those components needs an explicit location in your network diagram. Ask your security team to review the hosting decision alongside the data transfer analysis in this topic, because a managed backup or log service run from another jurisdiction can quietly move federation data out of scope.
Choose the database from the supported list before you size anything else. Keycloak supports MariaDB, Microsoft SQL Server, MySQL, Oracle Database, PostgreSQL (14 to 18), EnterpriseDB Advanced, Amazon Aurora PostgreSQL and Azure SQL, and the development file database is not for production. For a high availability design, Keycloak's two supported multi-site and cluster architectures both need a synchronously replicated database, so confirm with your database team that the replication mode and failover behavior meet that requirement before you commit. Authentik stores all configuration and data in PostgreSQL and no longer uses Redis, which simplifies the stack but puts more load on that one database, so confirm connection capacity with your vendor or test environment first.
Pin operator and upgrade behavior before the first production rollout. The Keycloak Operator docs strongly recommend manual approval mode for operator updates so a cluster does not upgrade unexpectedly, and that choice belongs in your change process. Keycloak runs schema migration automatically at startup by default, but the upgrading guide suggests manual migration for large deployments, where administrators apply the SQL themselves after review. Plan a maintenance window for each upgrade, take a database backup first, and remember that the export and import commands are not a full backup mechanism and require all nodes to be stopped while they run.
Deployment steps under the constraint
This sequence moves a self-hosted federation service from design to a documented, tested runbook, with each step closing on a check that the next one depends on. It keeps identity data and administration inside the boundary your legal and transfer review approved.
Confirm data and transfer requirements
Before any build work, legal counsel and the data protection lead should record where identity data may be stored, who may administer it, and whether any support access from outside the approved territory counts as a transfer. Use the EDPB guidance on remote access and cloud storage as the reference for that discussion, and have counsel confirm the conclusions for your jurisdiction. The output is a signed requirements note that names the hosting location, admin locations and support access rules. Do not start provisioning until that note exists.
Build the isolated environment
The infrastructure team builds the hosting environment inside your own cloud accounts, data center or air-gapped network, with segmented networks, controlled administrative access, time synchronization and centralized logging. Decide early whether the identity server runs on virtual machines, containers or the Keycloak Operator on Kubernetes, since that choice drives the rest of the build. The check is a documented network diagram and an access review showing that no path leads out of the approved boundary.
Deploy the database and identity server
Deploy a production-supported database, such as PostgreSQL within the versions Keycloak documents, and then the identity server with TLS, a non-default administrator account and a documented choice between automatic and manual schema migration. For high availability, plan a synchronously replicated database, because both supported Keycloak multi-site designs require it. The check is a successful health check on every node, a tested login to the admin console, and the exact version pinned in your change record.
Configure Active Directory or LDAP federation
Connect the identity server to the existing directory as a read-only user federation provider, using a dedicated bind account with the least privileges needed to read users and groups. Map attributes that your applications expect, such as user principal name, mail, department and group membership, and test authentication for a pilot group. The check is a pilot user who signs in with the same password as in AD FS, plus a list of groups that resolve correctly in the new realm or organization.
Set up SAML and OIDC clients
Using the inventory of relying party trusts, create one client per application, starting with a low-risk pilot app. Recreate the claims that each AD FS claim rule issued as protocol mappers, and confirm the signing certificates, redirect URIs and assertion consumer endpoints match what each application expects. Keep configuration in version-controlled files where your tooling allows it. The check is a successful sign-in and a token or assertion review for every pilot app before any production user is moved.
Export a backup in a planned maintenance window
Schedule a maintenance window, then stop every node, because the Keycloak realm export requires all nodes to be down while it runs. Export the realm configuration with the export command, and store the JSON files encrypted in a location the transfer review approved. The export is not a full backup and restore mechanism, so also take a database backup with a documented restore procedure. The check is a restore test in an isolated copy that shows the realm, clients and mappers come back as expected.
Test failover and recovery
Simulate the failures your design is meant to survive, such as losing one identity server node, the database primary or an availability zone, and record how sign-in behaves during each event. Confirm that session behavior and token lifetimes match what each application expects, and that monitoring alerts fire. Verify that the restored environment can still reach the directory. The output is a dated test report with pass or fail results and the remediation owner for each failure.
Document the operating runbook
Write the runbook that operations staff will follow after go-live, covering upgrades (including the Operator approval mode if you use it), certificate renewal, directory outages, backup and restore, access reviews and the procedure for adding a relying party. Assign an owner to each task and store the runbook beside the requirements note and test reports. The check is a tabletop walk-through by the on-call team, with every open question either resolved or added to a tracked backlog.
Evidence assessors and regulators ask for
Keeping a self-hosted federation service in-country or inside an isolated network is only half the answer. Assessors and data protection authorities will ask you to prove where personal data flows, who can reach it, and how the service was configured, secured and recovered. The cards below list the records to build from the start, and DeployOpen prepares this evidence, while independent auditors and certification bodies issue any opinion.
Data flow maps with no third-country transfer
Draw every path that carries identity data: user directory sync from Active Directory, SAML and OIDC assertions to each relying party, logs, backups and support access. Mark where each hop sits and whether any administrator or support session can display data from outside the EEA, because remote viewing from a third country counts as a transfer under EDPB Guidelines 05/2021. Confirm that backups and log shipping stay in the same jurisdiction as the primary.
Processor and sub-processor records
List every vendor, hosting provider and support firm that can access the identity stack, along with the country where each processes data and the contract clauses that cover it. For open-source software, the processor is usually your own hosting or DeployOpen engagement, so record who operates the cluster and who holds privileged access. Note any third-country law that could compel a provider to disclose data, since assessing that exposure is part of the decision before engaging the provider.
Configuration exports and change logs
Keep versioned exports of realm, client and identity provider settings, and tie every change to a ticket with an approver. Keycloak realm export with kc.sh export is a useful snapshot, but the docs warn it has limits as a backup and that all nodes must be stopped while it runs, so do not treat it as the only record. Store exports and change history in a system the identity team cannot silently edit.
MFA enrollment and access review records
Show which accounts and administrator roles have multi-factor authentication enrolled, which methods they use, and how exceptions are approved and expire. Run periodic access reviews of relying party assignments and administrator groups, and keep the signed results. Assessors will test whether a leaver loses federated access in the same cycle as the directory account, so keep the deprovisioning logs that prove it.
Tested backup and restore records
A backup only counts as evidence once a restore has been performed. Record the database backup schedule, the restore test date, the target environment, the time taken and the outcome, including any step that failed. Because Keycloak and authentik keep their configuration in a supported production database, the backup target is that database plus any secrets and certificates held outside it. Ask the vendor or your DBA to confirm what a clean restore requires.
Version and patch records for the chosen release
Record the exact release deployed, the date it went live, and the upgrade path taken. For Keycloak, track the current release line, the database schema migration mode you chose, and the operator update approval setting. For authentik, track which versions receive security fixes and when your environment last moved to one of them. Keep the release notes you reviewed before each upgrade, since they show that breaking changes were assessed.
Questions buyers ask before replacing AD FS on-premises
What drives the cost of replacing AD FS on-premises?
The biggest cost drivers are the number of relying party trusts, how many use WS-Federation or Kerberos-based integrations, the number of users and external users, and how much of the current farm and Web Application Proxy setup must be rebuilt. Each open-source option carries its own costs: the software is free to download, but you pay for the servers, the database, certificates, monitoring, patching and the people who run them. Ask any implementation partner to price each relying party separately so you can see which applications drive the work.
What is one-time work and what recurs after go-live?
One-time work includes the inventory of trusts, claim rule translation, client re-creation, testing, cutover planning, documentation and staff training. Recurring costs include hosting, database operations, backups, certificate renewals, monitoring, security patching, and version upgrades. Keycloak ships four minor releases a year, according to its blog, so budget time for regular upgrades in the run phase. If you choose authentik Enterprise, the pricing page lists $5 per user per month billed annually plus $0.02 per external user per month, which is a recurring subscription on top of hosting and support.
How long does an AD FS replacement take?
Duration depends on scope: the number of relying parties, how many integrations need custom mappers or protocol work, the state of your directory, and how many approval and change windows your organization requires. No single timeline applies across estates. Ask for a phased plan with milestones for each relying party group, and confirm which dependencies (certificates, network changes, application owner availability) sit outside the implementation team's control.
What must our internal team provide during the project?
Your team must supply an accurate list of relying party owners, access to the existing AD FS configuration and claim rules, directory administrator access for LDAP or Kerberos federation, certificate and DNS control, test accounts for each application, and named approvers for cutover. Your security team should also define the MFA policy, logging destinations and key storage. Without these inputs, the schedule and the cost estimate both become unreliable.
Can our own team replace AD FS without an outside partner?
Yes, if your team already runs Linux, PostgreSQL, container platforms and SAML or OIDC integrations, and has time to learn the chosen server. The harder part is usually the relying party inventory and the claim rule translation, which need application knowledge and careful testing. Many organizations keep operations in house and bring in a partner for architecture, hardening, migration waves and documentation. Decide which of those tasks your team can staff for the full duration of the project.
Do WS-Federation applications force an authentik Enterprise or WSO2 decision?
Often, yes. Keycloak does not serve WS-Federation, so applications that depend on it need another path. authentik documents a WS-Federation provider, and its Enterprise licensing and SAML2-token limit should be checked against your application list before you commit. WSO2 Identity Server supports WS-Federation alongside SAML, OIDC and SCIM. Confirm each WS-Federation application's token format and vendor support statement before choosing, because the answer determines the platform and the licensing model.
What should a written scope include before work starts?
A written scope should name the in-scope relying parties and the ones excluded, the target platform and version, the directory integration method, the high availability design, the database engine, the MFA approach, the backup and restore method, the cutover sequence, and the acceptance tests. It should also state who signs off each phase and what evidence the client receives. Request fixed deliverables and a timeline agreed before work starts, and check how data moves between the old and new systems, since Data Act switching rules and GDPR transfer conditions may apply if any hosting or support sits outside your control.
What changes for your team after the cutover
After cutover, your team owns the identity server itself. With AD FS, Microsoft's Windows Server patch cycle and the farm and Web Application Proxy servers were already in your hands, but the federation role sat inside a Windows estate your team already administered. With Keycloak, authentik or WSO2 Identity Server, you also own the Linux or container host, the runtime, the PostgreSQL or other supported database, TLS certificates, backups and the high availability design. Before the cutover, confirm who is on call for the identity service, how a failed node is replaced, and whether your recovery procedure has been run end to end, not just documented. Note that the Keycloak backup guidance warns that realm export and import is limited as a backup and restore mechanism and requires all nodes to be stopped, so plan database-level backups as the primary recovery path.
Upgrade rhythm changes as well. Keycloak has moved to four minor releases a year, with breaking changes in minor releases made opt-in, so your team should schedule regular minor upgrades rather than waiting for a major release. For the Keycloak Operator, the project strongly recommends manual approval mode for operator updates, so decide who approves each change and how it is tested in a staging realm first. authentik uses year and month version names, publishes a security policy listing which release lines receive security fixes, and gives at least 24 hours' notice of security releases, so confirm which line your team will pin and how quickly you can follow it. Ask your vendor or the project for the current support window for the release you choose, and confirm that your change process can absorb it.
Support is the other shift. Keycloak and authentik Open Source are community-supported in the sense that you rely on public documentation, forums and project channels, while Red Hat build of Keycloak, authentik Enterprise and WSO2 subscriptions add contracted support, and those contracts carry their own terms for response times and entitlements. Ask each candidate what support is included, what is excluded, and who answers a production incident at 2 a.m. Ownership of users and applications also moves. Your directory stays the source of truth for accounts if you keep Active Directory as a user store, but application registrations, claim mappings and client secrets now belong to the identity team, with documented owners per relying party. Assign those owners during the inventory, not after cutover.
How DeployOpen plans AD FS replacements under data residency constraints
DeployOpen plans, builds and hands over self-hosted identity platforms inside your own cloud accounts, data centers or air-gapped networks, so federation stays where your residency rules require it. We start from a written scope that inventories every relying party, its protocol and its data flows before any platform is chosen.
How we scope
- We inventory every AD FS relying party trust, its protocol, claim rules and certificates before recommending a platform.
- We map where authentication data, logs and backups would sit, and which transfers or third-country access paths apply.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We deploy the chosen server, such as Keycloak, authentik or WSO2, inside your network with the database and high availability design you approve.
- We connect existing Active Directory as a user source and re-create SAML and OpenID Connect clients with claim mappers.
- We test each relying party sign-in, MFA path and failover case in a non-production environment before cutover.
How we hand over
- We document configuration, client inventories, runbooks and the backup and restore procedure for your operations team.
- We prepare the control evidence your assessors or auditors will request, without issuing any audit report or attestation ourselves.
- We sequence relying party moves with rollback steps, so each application can return to AD FS if a cutover fails.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- We plan platform upgrades under a change process your team approves, including manual approval for operator-driven updates where relevant.
- We can run security testing of the new identity platform and its integrations, scoped in writing with your team.
