Is an open-source alternative to Entra Domain Services the right move for legacy apps?
If your legacy applications need domain join, LDAP, Kerberos or NTLM and currently depend on a managed domain in Azure, a self-hosted directory on servers you own can take over that role. Samba AD or FreeIPA can serve as the domain, the LDAP directory and the Kerberos key distribution center when the managed domain gets in the way, most often because you need writes to objects that originate in Entra ID, control over where the domain controllers run, or direct administration of the domain. The main trade-off is operational. Entra Domain Services removes the work of patching, replicating and backing up domain controllers, because Microsoft deploys and manages two domain controllers per replica set in the chosen Azure region. Moving to Samba AD or FreeIPA gives you control over placement, writes and configuration, but you then own replication, Kerberos key management, DNS, backups and patching. Microsoft describes Entra Domain Services as a transitional capability for Azure-hosted workloads, not a general replacement for on-premises Active Directory, so plan the exit as a deliberate project rather than a quick swap.
Whether this is the right move depends on the applications and the environment. Inventory each legacy app and record which protocol it uses, whether it writes to the directory, whether it needs Group Policy and whether it is tied to a specific Windows Server functional level. Confirm with each vendor which directories they support, because some applications only accept Active Directory. If your workloads are small, Azure-only and stable, the managed service may remain the lower-effort choice. If you run hybrid networks, need on-premises placement or must keep identities under your own control, Samba AD suits Windows-centric environments and FreeIPA suits Linux-centric ones. Confirm the decision with a pilot that tests domain join, Kerberos ticket issuance and LDAP writes before any production cutover.
Which open-source option covers each managed domain capability
This table maps each capability that an Entra Domain Services managed domain provides to the open-source directory that can take it over: Samba AD, FreeIPA, or Keycloak federated to an AD source. Read each row as a question to test in your own environment, because a yes in a cell means the platform is designed for that job, not that your applications have been verified against it.
| Capability | Samba AD on your servers | FreeIPA on your servers | Keycloak with AD federation |
|---|---|---|---|
| Domain join for Windows clients and servers | Windows-compatible AD DC, so domain join follows the Active Directory model that Windows expects | Designed for Linux clients through SSSD, so Windows domain join is not its primary path and needs testing | Not a domain controller, so Windows machines cannot join a domain through Keycloak |
| Group Policy | Confirm in your test lab which GPO features and client-side extensions your Windows fleet needs before cutover | No Windows Group Policy engine; Linux policy is handled through IdM host-based access and sudo rules | Not provided; Keycloak governs web and application sign-in only |
| LDAP directory access for legacy apps | Serves LDAP as part of the AD DC, so existing bind paths can often be kept after DNS and certificate changes | 389 Directory Server exposes LDAPv3 for users, groups, hosts and policies, but schema differences need review | Keycloak federates LDAP and AD as a source, but does not serve a directory for legacy clients |
| Kerberos authentication | Heimdal KDC by default, with experimental MIT Kerberos support when built against the system library | MIT Kerberos KDC provides single sign-on for Linux and UNIX services | Not applicable as a Kerberos KDC; Keycloak issues OIDC and SAML tokens |
| NTLM authentication | Confirm NTLM behavior for each legacy app in your own test environment before relying on it | Not a primary target; confirm with a test before assuming any NTLM-dependent app will work | Not applicable; NTLM-dependent apps need a different path |
| One-way sync from Entra ID | Not provided; identities are managed in the directory you run, so you must plan a source of truth | Not provided; plan a source of truth and provisioning before migration | Can federate the AD source that Entra ID syncs to, but Entra ID remains the cloud source |
| DNS for domain members | Built-in DNS with SAMBA_INTERNAL or BIND9_DLZ backends; avoid the NONE backend | Optional ISC BIND DNS, with at least two DNS servers in each client's resolv.conf | Not applicable; DNS remains in your existing network design |
| Writes to synchronized objects | You create and manage objects directly, so the one-way limit of the managed domain does not apply | Objects are managed in IdM and replicated across multi-master servers | Writes go to the upstream directory or Keycloak, depending on the federation mode you configure |
When Samba AD or FreeIPA fits better than a managed domain
A managed domain is a fit only while its limits match your workloads. When legacy apps need writable directory objects, Group Policy on Windows clients, or Linux and UNIX identity management, a self-hosted directory on your own servers may be the better home. Samba AD and FreeIPA cover different estates, and Keycloak sits beside either one rather than replacing it.
Samba AD for Windows-heavy domains
Samba can run as an Active Directory domain controller, using the Heimdal Kerberos key distribution center and either the SAMBA_INTERNAL or BIND9_DLZ DNS backend. It is a fit when Windows clients need domain join and Group Policy that behave like a Microsoft domain. Confirm which Group Policy features your clients use, because the stated functional levels reach 2016 and you should check that your domain level matches. Administration is done with samba-tool, so plan for staff who are comfortable with the command line. The wiki advises against running the DC as a file server when there are several DCs, so file serving should move to a separate member server.
Samba licensing and release cadence
Samba is licensed under GPL-3.0, so the software itself carries no license fee, but support is your responsibility unless you contract it. Each release series gets six months of full support, six months of maintenance mode and six months of security fixes only. Your upgrade plan must therefore track series end dates, not just the latest release. Ask any partner to state which series they will support and for how long. Plan a test domain for each upgrade before touching production.
FreeIPA for Linux and UNIX estates
FreeIPA combines 389 Directory Server, MIT Kerberos, the Dogtag certificate system and SSSD on clients. It fits Linux and UNIX estates where host policy, sudo and HBAC rules, and certificate issuance matter as much as user login. FreeIPA can also create a cross-forest trust with an Active Directory forest, but the IPA DNS domain must not overlap with any AD forest domain. Check that your Windows estate needs only trust-based access before choosing it over Samba AD for Windows domain join.
FreeIPA support and release risk
FreeIPA is a community project with no paid edition of its own, so support comes from your internal team, a contracted partner or community channels. The 4.13.4 stabilization release, dated July 9, 2026, fixed two CVEs, including LDAP access control flaws, which shows why patch tracking matters. Replicas should follow the deployment guidance on replica count and dedicated servers. Restoring an outdated backup into a live replica topology can break replication, so rehearse ipa-restore before you need it.
Keycloak is not a domain controller
Keycloak handles web and application SSO over OpenID Connect and SAML 2.0, and it can federate existing LDAP and Active Directory servers. It does not provide domain join, Group Policy, Kerberos for Windows clients or NTLM. If a legacy app needs those services, you still need Samba AD or FreeIPA behind it as the directory. Map each app's authentication method before deciding, since a web app may need only Keycloak while a file server or Windows workstation needs a real domain.
How to move domain-joined workloads off a managed domain
This sequence moves legacy domain-joined apps from Entra Domain Services to a directory you run yourself, with a tested inventory, rebuilt identities and a verified cutover before the managed domain is retired. The output is a target domain that serves LDAP, Kerberos and domain join without the managed service in the path.
Inventory every dependency on the managed domain
The application owner and the platform team list each workload that joins the managed domain or authenticates against it through LDAP, Kerberos or NTLM. For each one, record the service account, the protocol, the hostnames it uses, any Group Policy it receives and any hardcoded domain controller or DNS settings. Include print servers, file shares, scheduled jobs and service accounts that run under domain credentials, since these are easy to miss. The step is done when every entry has an owner and a named test, and the team agrees that no workload is left unlisted.
Build the target domain with replicas
The platform team deploys the target directory on servers they control, either Samba AD or FreeIPA, depending on which protocols and Windows features the inventory requires. For FreeIPA, the deployment recommendations advise at least two to three replicas in each datacenter, with no more than four replication agreements per replica and dedicated servers that run no other applications. Confirm DNS design early, because clients need at least two DNS servers in their resolver configuration. The step is done when replication is healthy across sites and a test client resolves the domain and obtains a Kerberos ticket.
Recreate users, groups and sources
If the users live in an LDAP source you can reach, FreeIPA's ipa migrate-ds command can import users and groups, though it excludes Kerberos attributes that FreeIPA regenerates, so every user must set or reset credentials in the new realm. Sudo and HBAC rules do not migrate this way and must be exported and imported manually through LDIF. Samba AD requires the equivalent objects to be created with samba-tool. Accounts that the managed domain synchronized from Entra ID need a decision: each one is either recreated locally with a new password or kept in Entra ID for cloud sign-in. The step is done when a sample of users and groups matches the source, with memberships checked and manual rules documented.
Recreate Group Policy and validate the result
Group Policy objects from the managed domain do not move automatically in a form you can assume works. The team rebuilds each policy in the target domain, or replaces it with the equivalent configuration management, and then tests it on a representative machine in each organizational unit. Record which settings are reproduced and which are dropped, and get sign-off from the owners of affected workloads. The step is done when test machines apply the expected settings and the exceptions list is approved.
Re-join machines and test authentication
Each machine leaves the managed domain and joins the target domain, usually in small waves so that a failed join affects a limited group. Test interactive logon, service logons, LDAP binds, Kerberos access to file shares and any NTLM-only applications, because some legacy clients still fall back to NTLM. Keep a documented rollback for each wave. The step is done when every workload in the inventory passes its named test from a rejoined machine and the test results are stored with the change record.
Cut over DNS and time
Once the test waves pass, the team changes the DNS records, conditional forwarders and time sources that workloads use so they point to the target domain. Clients that still cache the managed domain's controllers need a refresh or restart. Confirm that time synchronization is consistent across domain members, since Kerberos depends on it. The step is done when name resolution and time checks succeed from every site and no workload still points to the managed domain.
Back up and retire the managed domain
Before retiring the managed domain, the team takes a final backup of the target directory and confirms restore procedures. FreeIPA's ipa-backup and ipa-restore support full or online data-only backups, and its documentation warns that restoring an outdated backup into an active replica topology can break replication, so restore tests should run in an isolated environment. Once no workload depends on the managed domain and the target has a verified backup, the Azure resources are removed according to the owner's decision. The step is done when the backup restore has been tested, the retirement is recorded and the managed domain has no remaining dependencies in the inventory.
What running your own domain controllers costs
The main cost of moving off Entra Domain Services is not a licence line. It is the people and infrastructure needed to run domain controllers yourself. Entra Domain Services hides the domain controller VMs, patching and replication behind a managed service. With Samba AD or FreeIPA, you pay for servers or VMs in at least two sites, the operating system under them, and the staff time to administer the directory, design DNS and time, test backups, patch and upgrade, and monitor replication. Ask each vendor or partner to split the quote along those lines so you can see what recurs each year and what is one-time project work.
Several design choices move cost up or down. The number of sites and replicas sets the server count, and FreeIPA's deployment recommendations of two to three replicas per datacenter are a starting point to check against your own topology. The number of applications bound to the directory drives the migration effort and the testing load, especially for legacy LDAP and Kerberos consumers. In-house skills matter most: a team that already runs Linux, Kerberos and DNS will spend far less on learning than one starting from Windows-only administration. Backup and restore testing is a recurring task that is easy to underbudget, since FreeIPA's backup documentation warns that restoring an outdated backup into an active topology can break replication. Confirm the restore procedure and who runs it.
When you request a written quote, ask for the scope of each component, named roles and hours by role, the assumed number of sites and replicas, the patching and upgrade schedule, and what is excluded, such as application changes or 24-hour support. Ask whether monitoring and backup tooling are included or supplied by you, and whether a retainer covers upgrades and incident response after go-live. Compare these items against the Entra Domain Services bill you have today, including the Azure resources it consumes. Where a figure is not in the quote, treat it as unknown and confirm it before you commit. DeployOpen provides fixed-scope quotes that follow from a written scope, so the same checklist applies to any partner you evaluate.
Questions buyers ask before replacing Entra Domain Services
Can our own team replace Entra Domain Services without an outside partner?
Yes, if your team already runs Active Directory or Linux identity services and has the time to learn the new stack. Samba AD and FreeIPA both need careful design: domain controller placement, DNS, Kerberos realms, time sync, backups and replication topology. The FreeIPA deployment recommendations, for example, call for dedicated servers, several replicas per datacenter and at least two DNS servers in each client's resolver configuration. Teams without this experience usually find that the hard parts are the migration of each legacy application and the testing of its authentication path, not the installation itself. Decide early which of these you will carry out internally and which you will buy as a fixed-scope engagement with written deliverables.
What drives the cost of moving off Entra Domain Services?
The main drivers are the number of workloads that depend on the managed domain, how many of them use LDAP writes, NTLM or Kerberos in ways that need retesting, and how much custom Group Policy or scripting must be rebuilt. Entra Domain Services creates objects in its managed domain only, and resources synchronized from Entra ID remain read-only there, so every application that writes to the directory needs a new home. Hardware or virtual machines, operating system licenses, the directory's database and backup tooling, and staff time are the recurring and one-time components. Ask any provider for a quote that separates server and hosting costs, the migration of each application, testing, and ongoing support, and that states which items are one-time and which recur.
What do we need to provide before the work starts?
The team needs an accurate inventory of every application, service account, scheduled task and device that joins the managed domain or binds to its LDAP endpoint. For each item, record the protocol it uses, whether it reads or writes the directory, which Group Policy settings apply, and who owns it. You will also need network access for the new domain controllers from the subnets that host workloads, firewall rules for DNS, Kerberos, LDAP and time traffic, and a named contact in each application team. Plan change windows for cutovers and for rollback, because some legacy applications only retry authentication for a limited period. An illustrative example: a line-of-business application with a hard-coded LDAP bind account will need that account recreated and its connection string changed during the same window.
How long does a migration from Entra Domain Services take?
The duration depends on scope, not on the software alone. The number of applications, how many are tied to NTLM or LDAP writes, how much Group Policy must be rebuilt, the state of the existing inventory, and the availability of change windows all change the schedule. Installing a Samba AD or FreeIPA pair is usually the shortest step, while testing each application and cutting it over is the longest. Ask for a written plan with milestones, a list of assumptions and a testing approach for each application group before accepting any timeline. Under a fixed-scope engagement, the agreed scope, deliverables and dates are written down before work starts, which makes changes to the plan visible.
Can Samba AD or FreeIPA run alongside Entra ID during the transition?
Yes, they can run side by side, and most transitions depend on it. Samba AD can be set up as an Active Directory domain controller on your own servers, and FreeIPA can create a cross-forest trust with Active Directory through Samba components. A trust requires that the IPA domain use a DNS name that does not overlap with any domain in the Active Directory forest, which is a planning decision to make before installation. Entra ID synchronization and Entra Domain Services are separate services, so confirm with Microsoft how any existing synchronization will behave while both directories are live. Plan which directory is authoritative for each user and group during the overlap to avoid two sources of truth.
What security checks should we run on the new directory?
Treat the new directory as critical infrastructure from the first day. Keep directory servers dedicated, restrict administrative access, and apply the vendor's security updates promptly. FreeIPA 4.13.4, dated July 9, 2026, fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, so the patch process must be part of operations. Test the LDAP access controls, Kerberos ticket policies, certificate issuance and multi-factor settings against your own requirements. Penetration testing of the directory and its integrations is a common scope item for a security testing provider, and the results should feed back into the design.
Will a self-hosted directory satisfy our compliance requirements?
A self-hosted directory can support evidence for compliance, but it does not provide compliance by itself. Your auditor will look at the controls you operate, such as access reviews, logging, backup and restore testing, change management and key management. Ask your assessor which control references apply to your environment and map each one to a configuration, a procedure or a record. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, which independent auditors and certification bodies provide. Confirm the scope of these responsibilities in the written agreement before work begins.
Keeping Entra ID and an on-premises domain running side by side
Entra ID can stay in place for Microsoft 365 and cloud sign-in while Samba AD or FreeIPA serves the legacy applications that need domain join, LDAP, Kerberos or NTLM. The split is usually by workload, not by user: Microsoft 365 and cloud apps keep authenticating against Entra ID, and the on-premises domain holds the computers, service accounts and directory bindings that legacy apps depend on. Decide early which system is the source of truth for each user attribute, because two directories that both claim to own a password or group membership will drift apart.
The most common design error is a DNS namespace clash. The IPA domain in FreeIPA, and the AD-compatible realm in a Samba AD DC, must not overlap with any DNS domain used by an Active Directory forest you trust or synchronize with. Check the zones that Entra Connect or any other sync tool, Microsoft 365 and existing AD forests already use, including split-DNS names, before you pick a domain name. Changing the name later means rebuilding the directory, so treat this as a one-time design review with the network and identity teams.
Confirm two things in writing before you build. First, ask Microsoft which sync and federation tooling is supported for your tenant and which licenses apply to the Entra ID side, since Entra Domain Services and Entra ID licensing are separate decisions. Second, ask the chosen vendor or implementation partner which trust type, sync direction and password policy they support for your Samba or FreeIPA version, and what runs on each side of the boundary. Document those answers so the coexistence design can be audited later.
What to validate before cutover
This sequence confirms that the Samba AD or FreeIPA domain can carry the legacy workloads that used to rely on Entra Domain Services, and it leaves a dated record of the checks that passed. Each step closes with an output the team can file before any application is pointed at the new domain.
Confirm the domain functional level
The directory engineer lists the current forest and domain functional levels on the Samba AD DC with samba-tool and compares them with the Windows Server levels your applications and clients need. Samba supports the 2008 R2 level since Samba 4.0, the 2012 and 2012 R2 levels since Samba 4.19, and the 2016 level since Samba 4.20, so check which of these your target release supports before planning any raise. Done means a written record of the current levels, the target level, and a sign-off from the application owners that no workload requires a level that is unavailable.
Inventory NTLM dependencies and plan retirement
Security engineers and application owners list every system that authenticates with NTLM, including older file shares, line-of-business clients, service accounts and scanners, and record whether each one can use Kerberos instead. Entra Domain Services supported NTLM for these workloads, so this inventory is where most surprises appear during a move. Done means a dependency list with an owner, a remediation path or documented exception for each entry, and a retirement plan that the security lead has reviewed.
Set and test Kerberos encryption settings
The directory team reviews which Kerberos encryption types the KDC accepts and which the clients and services request, then tests sign-in from a representative sample of domain-joined Windows, Linux and service accounts. Samba uses the Heimdal KDC by default, and MIT Kerberos support is experimental, so confirm the chosen build and the policy with the vendor or the Samba documentation before standardizing. Done means a test matrix showing successful ticket issuance per client type, and a documented list of encryption types that are disabled on purpose.
Run backup and restore drills
The operations team takes a full backup of the directory, restores it into an isolated test environment, and checks that users can authenticate and that DNS resolves the domain controllers. Repeat the drill for each backup method you plan to use in production. Done means a restore runbook with the time it actually took, a list of the steps that needed manual correction, and a named owner who has completed the drill at least once.
Validate replica topology and DNS redundancy
The platform engineer checks that each site has at least two domain controllers or replicas and that replication agreements follow the limits in your chosen product's deployment guidance. For FreeIPA, the deployment recommendations also call for at least two DNS servers in each client's resolver configuration. Simulate the loss of one server per site and confirm that logon, DNS and replication keep working. Done means a replication status report with no errors and a failover test record for each site.
Confirm the Samba release series support window
The platform owner records which Samba release series is in use and where it sits in the support cycle, using the Samba release planning page. Each series receives six months of full support, six months of maintenance mode, and six months of security fixes only, and Samba 4.25 begins in September 2026. Done means a documented upgrade date ahead of the end of full support for the chosen series and a named owner for tracking Samba releases.
Verify patch levels before go-live
The security team confirms that the FreeIPA or Samba packages match the current stable release, and that every domain controller has the same build. FreeIPA 4.13.4 fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, so any FreeIPA build older than that release should be treated as a go-live blocker. Done means a patch inventory per server, a signed approval from the security lead, and a dated note of the versions tested.
Approve cutover with a rollback plan
The project lead presents the evidence from the previous steps to the application owners and the security lead, and agrees a rollback path that keeps the Entra Domain Services domain available until the new domain has run in production for a period the team sets. Confirm the rollback path with the vendor support terms of your chosen platform before you rely on it. Done means a signed go or no-go record that lists any accepted exceptions, linked to the evidence from each step.
What Entra Domain Services does not replace
Entra Domain Services covers domain join, Group Policy, LDAP and Kerberos/NTLM for Azure-hosted workloads, but it does not take over Entra ID's cloud sign-in or its policy engine. Conditional Access, sign-in risk evaluation, device compliance checks and the sign-in logs that come with them stay in Entra ID, and a managed domain does not enforce them for LDAP or Kerberos binds. Microsoft also positions the service as a transitional option for legacy authentication in Azure, not as a general replacement for on-premises Active Directory. Before you plan a move, list every control that currently protects these legacy apps and mark which ones are enforced in Entra ID and which, if any, are enforced in the managed domain itself. The controls that exist only in Entra ID need an owner in the target design, whether that is a reverse proxy, an application-level MFA check or a documented risk acceptance.
Samba AD and FreeIPA do not replace Microsoft 365 licensing, Entra ID or the Microsoft 365 sign-in path. If your users still sign in to Exchange Online, SharePoint or Teams with Entra ID accounts, that dependency remains even after the legacy apps move. FreeIPA can establish a cross-forest trust with Active Directory, and Samba can act as an AD domain controller, but neither product becomes the cloud identity provider for Microsoft services. Confirm with Microsoft which licenses and sign-in methods your tenant needs, and confirm with your Microsoft account team which features depend on Entra ID features that you would still pay for. Treat these as open questions to answer in your own environment rather than assumptions carried over from this page.
How DeployOpen scopes and delivers a domain replacement
Moving domain join, LDAP and Kerberos off a managed domain is an infrastructure project, not a configuration change. The cards below cover what DeployOpen takes on, how engagements are scoped in writing, and what stays with your team after go-live.
Planning the target domain
DeployOpen maps each workload that depends on Entra Domain Services, including domain join, LDAP binds, Kerberos service accounts and NTLM fallbacks, before choosing between Samba AD and FreeIPA. The plan records which apps need Windows Group Policy, which need Linux identity, and which need a trust with an existing Active Directory forest. Ask for this inventory as a named deliverable in the written scope.
Building the domain on your servers
Implementation covers hosts sized for dedicated domain controllers, DNS design, replication topology, and the functional level chosen for each application. Work runs inside your cloud accounts, data centers or isolated networks, so you keep control of the servers and the administrator credentials. Confirm who holds the initial domain administrator secrets before work starts.
Hardening and access controls
DeployOpen applies hardening to the directory, DNS, time sources and administrative access paths, and sets review steps for password policy, service account handling and LDAP access rules. Patch cadence and vendor advisories are reviewed against your change process. Ask which hardening baseline is applied and how exceptions are recorded.
Backup and restore testing
Directory backups protect against both data loss and replication damage, so DeployOpen designs backup schedules and tests restores into a non-production copy before go-live. A restore that is not rehearsed is not a recovery plan. Confirm with the vendor how the chosen platform's backup tool behaves in a multi-server topology and document who approves a restore.
Documentation and compliance evidence
Deliverables include runbooks, architecture records, configuration baselines and evidence of controls for your compliance team. This is preparation for an assessment only: DeployOpen does not issue audit reports, attestations or certifications, and independent auditors or certification bodies decide whether controls meet a standard. Agree the evidence list with your assessor early.
Fixed scope, retainers and support
Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. After handover, upgrades, monitoring and incident support can continue under a retainer. Ask for the cost components in your quote, including what is one-time, what recurs and which items depend on your own staff.
