Which Linux distribution to use for FreeIPA servers
The operating system you choose for your FreeIPA servers will hold your identity, Kerberos and certificate authority roles for years, so treat it as a design decision rather than a late install detail. The choice sets your upgrade cadence, your vendor support path and the lifecycle you must plan around. FreeIPA itself is a community project with no paid edition of its own, so the support you get depends on the distribution underneath it and on whatever commercial agreement, if any, you hold with that distribution's vendor or a partner.
Choose the server OS and the client OS separately. The IdM servers run 389 Directory Server, MIT Kerberos, the Dogtag certificate system and optionally DNS and NTP, which makes them the components that need the longest support window and the most careful change control. Enrolled Linux clients run SSSD and can differ from the servers, but each client distribution still has its own supported-platform boundary, which belongs to the client enrollment design. Write both decisions down in the design phase, with the owner of each upgrade named.
Before you commit, confirm with the distribution vendor and the FreeIPA release notes which FreeIPA version ships for each candidate OS, how long that OS receives security fixes, and whether the vendor supports IdM server roles in your deployment model. Fedora moves quickly and suits teams that can absorb frequent upgrades, while enterprise distributions trade newer packages for longer, predictable support windows. Ask each candidate for its published lifecycle dates in writing, and map them against your own upgrade calendar and the FreeIPA security releases you expect to apply.
How Fedora, RHEL and other distributions compare for IdM servers
This table compares Fedora, Red Hat Enterprise Linux with Identity Management, and other distributions across release cadence, vendor support, lifecycle, upgrade effort and regulated-environment fit. Read each row as a question to put to the vendor or your own team, because lifecycle and support terms come from each distributor. The main takeaway is that FreeIPA itself is free under GPL-3.0-or-later with no paid edition, so the support and lifecycle you buy or accept come from the operating system vendor.
| Criterion | Fedora | RHEL with Identity Management |
|---|---|---|
| Release cadence | Fast; new releases arrive on a short cycle that the project publishes | Slower; major releases on a vendor-published schedule, with minor releases in between |
| Vendor support for IdM servers | Community support through the Fedora project; no paid vendor support contract | Commercial support from Red Hat for the IdM server role, subject to the subscription you hold |
| Lifecycle length | Short; each release is supported for a limited period, so plan frequent upgrades | Long; confirm the exact end-of-life dates for your major version with Red Hat |
| Upgrade effort | Frequent in-place or reinstall cycles to stay within support | Less frequent major upgrades; confirm the supported in-place upgrade path with Red Hat |
| FreeIPA version currency | Tends to ship newer FreeIPA 4.x releases sooner, such as 4.13.x | Ships FreeIPA on the vendor's own schedule; check which 4.x line your version carries |
| Fit for regulated environments | Often hard to justify where auditors expect vendor-backed support and fixed lifecycles | Usually the default choice where vendor support, documented lifecycles and attestations are required; confirm with your assessor |
| Security update handling | Updates follow the Fedora release cycle; confirm the response you need for security advisories | Vendor errata with advisories; confirm response times in your subscription terms |
| Other distributions | Check whether the distribution packages the FreeIPA server role, its supported versions and its vendor support terms | Confirm the same items for each option before choosing, including client support boundaries |
Why FreeIPA release versions and OS lifecycle must be planned together
The OS and the FreeIPA release are two separate lifecycles, and either one can force an upgrade. FreeIPA 4.13.0 introduced the first beta of a new web UI, DNS over TLS between clients and IdM DNS servers, LDAP system accounts, the ipa-idrange-fix tool and random certificate serial numbers by default. Version 4.13.4, a stabilization release dated July 9, 2026, fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials. A security fix like this can require a server update on a short timeline, whatever the OS calendar says.
Before you commit to a distribution, build a table that maps each candidate OS to the FreeIPA version it ships, the version it can receive through its own update channel, and the date its standard and extended support end. Include the 4.13.x line in that table, because features such as the ipa-idrange-fix tool and the DNS over TLS setting depend on it. Confirm every entry against the distribution's own lifecycle documentation and its package repositories, not against assumptions from this page. Ask whether the vendor backports security fixes from newer FreeIPA releases and for how long.
Plan the upgrade path as part of the platform decision. A fast-moving OS may move the server packages ahead of the features your team has tested, while a long-support OS may keep FreeIPA on an older line that misses the security fixes you need. Test each candidate with a non-production replica, record which feature flags and DNS settings you depend on, and set a review date tied to both lifecycles. Client support is a separate question, so confirm which distributions your enrollment tooling and SSSD versions support for the machines you plan to join.
Client support boundaries that do not follow the server OS
Server support for FreeIPA does not decide what your Linux clients can do. Enrollment, SSSD behavior, DNS configuration and time sync are checked per client distribution, and mixed fleets add their own constraints. Treat each row below as a separate check against the list for every client OS you run.
Enrollment support per client distribution
Client enrollment and SSSD support are documented per distribution, and the list can differ from the server platform you chose. Before you standardize on an OS for workstations or application servers, confirm that the client enrollment path is supported for that exact release. Do not assume that a distribution running FreeIPA servers is also a supported client. Record the enrollment method, the SSSD version and the release you tested in your own environment.
SSSD behavior on each client
Each client runs SSSD to talk to the IPA servers, and SSSD versions differ across distributions. Differences show up in offline login, SSH key retrieval, and how host and sudo rules are cached. Test login, sudo and SSH key lookup on each client OS before rollout, because a failure on one distribution will not show up on your server tests.
Two DNS servers in resolv.conf
Clients need at least two DNS servers in resolv.conf that can answer for the IPA domain. A single resolver is a common cause of failed enrollment and Kerberos lookups. Check how each client distribution manages resolv.conf (static file, NetworkManager, or systemd-resolved), because a setting that persists on one OS can be overwritten on another.
Time sync on every client
Kerberos rejects tickets when clocks drift too far apart, so every client must keep time synchronized against the same sources as the servers. Each distribution has its own default time service, and some ship chrony while others default to a different daemon. Confirm which service each client OS runs, which servers it uses, and that the offset stays small enough for Kerberos to succeed.
Mixed fleets and version drift
A fleet with several client distributions and release cadences means several SSSD versions, several enrollment paths and several support windows. The server side can stay on one platform while clients drift apart over time. Keep an inventory of client OS, release and SSSD version, and review it whenever a server upgrade or client OS upgrade is planned.
Steps to choose and validate the server operating system
This sequence turns the choice of operating system into a tested decision: it fixes the support and lifecycle terms first, then proves on a test topology that FreeIPA, backups and restores behave on the candidate OS before any production server is built.
Write down support and lifecycle requirements
The security or platform owner lists what the organization needs from the operating system: how long security updates must arrive, whether a vendor must provide support for FreeIPA server packages, which regulatory or audit commitments apply, and who on the team can patch the host. Procurement and the compliance lead should sign off on the list. The step is done when each requirement is written as a yes or no question that a candidate distribution can answer with a document, not an assumption. Ask each vendor or project to confirm the answers in writing.
Shortlist distributions and FreeIPA releases together
Pair each candidate distribution with the FreeIPA version its packages ship, because the server version is what you actually run. Compare a fast-moving community option such as Fedora with an enterprise distribution that offers a supported IdM server package. Confirm the FreeIPA release your shortlist offers against the release notes for the version you intend to deploy, including security fixes such as those in the 4.13.4 release notes. The output is a short table of distribution, package version, support terms and open questions for each candidate.
Confirm the server role plan
Before testing, fix the topology the OS must support: how many replicas each datacenter needs, which servers run the Dogtag CA and integrated DNS, and whether any server will also run AD trust components. The FreeIPA deployment recommendations advise at least two to three replicas per datacenter, no more than four replication agreements per replica, and dedicated servers without other applications. Check that the candidate OS supports every role on that plan, including the packages for DNS and trust roles. The step closes with a signed role map that names the host for each role.
Build a test replica pair
Install two servers on the candidate operating system in a non-production network that matches your DNS, time source and firewall rules. Enroll a small set of test clients from the client distributions you support, and confirm that Kerberos login, host access rules and certificate issuance work. Record the exact package versions installed on each server, the FreeIPA version reported, and any installer warnings. The step is complete when replication between the two servers reports healthy and the test clients authenticate against either server.
Run backup and restore on the candidate OS
Take a full backup with ipa-backup on the first test server, then restore it into a separate test topology built on the same OS and FreeIPA version. Confirm users, groups, hosts, certificates and DNS records return, and re-initialize the second replica as the backup guidance describes. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so record that restore ran into an isolated environment. The check passes only when the restored system authenticates test users and replication runs cleanly afterwards.
Record the upgrade path and lifecycle dates
Write down how each server moves to a later FreeIPA release and a later operating system release, including the order of replicas, the CA renewal server, and the window in which the distribution still ships updates. Ask the vendor or project to confirm the end of support dates for the distribution and the FreeIPA release line in writing, because this document is the reference your team will use for future upgrades. The step is done when an engineer who did not run the tests can follow the recorded path on a test server and reach the same result.
Approve the operating system decision
The CISO or head of platform engineering reviews the requirements list, the shortlist, the role map, the test results and the upgrade path together. The decision record names the chosen distribution, the FreeIPA version line, the accepted support terms, and the known gaps with an owner for each. Keep the record with the deployment runbook so that patch planning and audit evidence refer to the same choice. The decision is final when every requirement from the first step has a documented answer.
How the right distribution differs by environment
Organizations in banking, healthcare and other regulated sectors usually need a named vendor to answer for the platform, a published support lifecycle and a documented patch process that auditors can read. In this setting the distribution choice is mostly a question of what your support contract and change process can absorb, not which release is newest. Start with the authority that will review your controls and the vendor you already buy from, then work backward to the OS and FreeIPA versions that fall within both.
- Support scope: Confirm whether the vendor supports FreeIPA server roles on the distribution you choose, and whether that support covers replicas, DNS and certificate authority roles separately.
- Lifecycle fit: Map the end-of-support dates for the OS and the FreeIPA packages against your planned operating period and your upgrade calendar.
- Client boundaries: List every client distribution in use, since vendor support for the server does not automatically cover every enrolled Linux client.
- Change evidence: Check that patch notices, security advisories and package sources are available in a form your change management and audit teams accept.
- Upgrade path: Ask how in-place upgrades between major releases are supported and what the vendor requires before a server can be moved.
Before you decide, ask the vendor in writing which FreeIPA packages, roles and versions your contract covers, and ask your assessor which evidence of patching and support they expect to see.
Public sector bodies and networks without outbound internet access depend on how packages reach the servers. The distribution decision here is shaped by mirror availability, how updates are approved and imported, and whether the chosen OS ships the FreeIPA packages and security fixes you need in a form you can verify offline. Security releases matter here as much as in any environment, so the update path has to be planned as carefully as the initial install.
- Mirror and repository model: Confirm how packages, security updates and signing keys will be obtained, staged and imported into an isolated network, and who owns that process.
- Update approval flow: Check whether your accreditation process can accept the update cadence of the distribution and the timing of FreeIPA security releases.
- Offline dependencies: Identify the packages needed for DNS, certificate authority and trust roles, and confirm they are available in your offline repositories.
- Verification: Plan how package signatures and release checksums will be validated before they reach production servers.
- Recovery media: Confirm that the OS images and packages needed to rebuild a FreeIPA server can be kept and tested offline.
Ask your distribution vendor or mirror provider which repositories are supported for disconnected use, and ask your security authority which update approval timelines they will accept before you commit to a version.
Labs, proofs of concept and test environments exist to learn how FreeIPA behaves and to check new features before production teams depend on them. A short lifecycle is acceptable here because the goal is fast feedback, not a long period of stable operation. Fedora moves quickly and ships newer FreeIPA releases sooner, which suits this use. The trade-off is that you will need to rebuild or upgrade more often, so the lab should be treated as disposable and documented enough to repeat.
- Feature access: Use a fast-moving platform when you need to test recent FreeIPA capabilities, such as the new web UI or DNS over TLS added in 4.13.0.
- Rebuild effort: Expect to reinstall or upgrade the lab more often and keep the build steps in version control so the environment can be recreated.
- Parity with production: Record which OS and FreeIPA versions differ from production, so test results are not read as production evidence.
- Client coverage: Test the client distributions you actually run, because lab results on one platform do not show how enrollment behaves on others.
- Data handling: Use synthetic identities and avoid copying production directory data into a lab that has weaker controls.
Before you rely on lab results, confirm which FreeIPA version and OS combination will reach production, and decide which tests must be repeated on that exact combination.
Security patching and CVE response on the chosen OS
A FreeIPA server is only as current as the distribution packages beneath it and the FreeIPA releases you apply on top. The cards below cover where patches come from, how FreeIPA security releases reach your servers, and the operating constraints that decide whether you can respond quickly to a CVE.
Update speed for FreeIPA dependencies
Patches for 389 Directory Server, MIT Kerberos, Dogtag, SSSD and BIND reach your servers through the distribution's package channel, so the speed of that channel sets your exposure window. Ask each vendor how quickly it ships fixes for these packages, whether security updates are separated from feature updates, and whether it publishes advisories you can subscribe to. Confirm these details with the vendor, because update practices differ between distributions and between release channels.
Applying FreeIPA security releases
FreeIPA security releases such as 4.13.4 fix flaws in the server itself, including LDAP access control issues and authentication checks in the API. Read the release notes before each update, identify which fixes apply to your version, and schedule the update on every server in the topology. Test the update on a non-production replica first, since the fixes change how the directory and API handle access.
Running past the support window
When an operating system reaches end of support, FreeIPA servers keep running but stop receiving fixes for the packages they depend on. The risk grows with each month of exposure, and it compounds if the FreeIPA version also falls behind. Record the end-of-support date for each server's OS, set a replacement date well before it, and check whether the vendor offers extended support for identity infrastructure.
Change control during OS upgrades
Moving a FreeIPA server to a new OS release changes the packages that the server runs, so it needs the same care as a major upgrade. Plan the order of replica upgrades, confirm replication health before and after each step, and take a verified backup first. Ask your partner or vendor which upgrade path is supported for your FreeIPA version, and confirm it in writing before the change window.
Dedicated servers for patch safety
The FreeIPA deployment recommendations call for dedicated servers without other applications. This matters for patching because a shared host forces you to coordinate reboots, library updates and kernel changes with unrelated workloads that have their own schedules. Keep identity servers on their own hosts so that patch windows affect only the identity service, and document which other services, if any, depend on each server.
What buyers ask before choosing a FreeIPA server distribution
Is FreeIPA a paid product or does it need a license?
FreeIPA is free software licensed under GPL-3.0-or-later, and the project has no paid edition of its own. The software cost is therefore zero, but the operating system, support contract and implementation work are separate line items. Your costs come from the distribution you choose (some enterprise subscriptions are paid, while community distributions are not), from the people who build and run the servers, and from any vendor support you buy. Ask a partner to separate these costs in the quote so you can see which parts recur every year and which are one-time.
Does Red Hat support cover IdM on RHEL?
Red Hat sells support for Identity Management on RHEL, which is the enterprise packaging of the same FreeIPA project. Confirm the exact subscription, the IdM components it covers and the support terms directly with Red Hat before you rely on them, because entitlements differ by subscription and by product version. Also confirm whether your planned DNS, certificate authority and AD trust roles fall inside that coverage. A partner can help you map those roles to your subscription, but the support terms themselves come from the vendor.
Is Fedora suitable for production FreeIPA servers?
Fedora can run FreeIPA, and it is the upstream development platform where new releases appear first. Its cadence is fast, so each release reaches end of life sooner than an enterprise distribution, and you must plan major upgrades more often. Many regulated teams prefer a distribution with a longer support window and a vendor support path for the identity servers. If you still consider Fedora, confirm its current lifecycle with the Fedora project and decide in advance how you will test and apply each upgrade.
How does the OS choice change project effort and timing?
The distribution drives effort mainly through package versions, upgrade frequency, and how many supported client platforms you must cover. A fast-moving base means more upgrade cycles and more regression testing for DNS, certificate and replication behavior. An enterprise base means fewer but larger changes, and more time spent on subscription and repository setup. Timing also depends on your existing estate: the number of clients, the need for AD trusts and the number of replicas per site. Ask for a written scope that lists each OS version, each role and each upgrade you expect in the first year.
What does the engagement need from our own team?
A partner needs named owners on your side for identity, DNS, network and change control, plus access to the target cloud accounts, data centers or air-gapped networks where the servers will run. Your team also supplies the current LDAP or AD inventory, the host naming plan, the time sources and any compliance requirements that set controls. Expect to review design decisions, sign off test results and own the servers after handover. Ask the partner to list these inputs in the written scope so that delays can be assigned before work starts.
Can our own team choose and validate the distribution?
Yes, many teams can make this choice internally if they have Linux administration skills and a clear lifecycle policy. The decision rests on your support requirements, the client platforms you must serve, your upgrade capacity and your audit obligations. Your team should test a full install, backup, restore and replica rebuild on the candidate distribution before committing. An outside review is useful when the choice affects a regulated environment or when internal staff have not run identity infrastructure before, because mistakes in this layer affect every login.
How do we check which client platforms FreeIPA supports?
Client support is a separate question from server support, so check both. Start from the FreeIPA client enrollment documentation for the release you plan to run, then compare it with the client operating systems in your fleet. Confirm the SSSD version each client ships, because identity features depend on it. Record any gap as a risk with an owner, and decide whether to upgrade, exclude or isolate those hosts. Ask the partner to include a client matrix in the design deliverable so the server choice does not hide client-side limits.
Limits to confirm in your environment before standardizing
A Linux distribution choice for FreeIPA servers depends on facts that change outside this page: vendor lifecycle dates, packaging decisions and support terms. The items below are questions to answer with the vendor or within your own environment before you commit a standard.
Lifecycle end dates per distribution
Ask each distribution vendor for the exact end-of-life date of the OS release you plan to use, including any extended support option. Then compare those dates with the FreeIPA branch you intend to run, since the two lifecycles rarely end together. Record both dates in your standard so the upgrade trigger is written down before the first server is built.
FreeIPA version packaged for your OS
Confirm which FreeIPA release your chosen OS packages, and whether that package receives security fixes. Recent security releases, such as the 4.13.4 release that fixed two CVEs, reach you only if your distribution ships them. If your OS lags behind, decide whether you will build from a supported source or accept the older version.
Container base image options
If you plan to run FreeIPA in containers, ask the image maintainers which base OS tags are published and how long each one is rebuilt. Check whether the base OS tag matches the host OS standard you have chosen, or whether the two can drift apart. Confirm the rebuild cadence in writing, because a stale base image carries the same exposure as an unpatched host.
Red Hat support terms for RHEL IdM
If you plan to use RHEL with Identity Management, confirm with Red Hat which subscription covers the IdM server role, which versions are in support, and what support covers for replicas, DNS and certificate authority roles. Ask whether your support terms cover integrations you plan to run, such as AD trusts. Do not assume that a RHEL subscription alone covers every role you intend to deploy.
Client distribution support boundaries
Enrolled clients run SSSD and may run on different distributions than your servers. Check the supported client list for each distribution and version in your estate, including older machines and appliances. Identify any clients that fall outside the supported list early, because they affect login behavior and the lifecycle of your standard more than the server OS does.
Sector rules on OS sources
Ask your compliance lead and auditor whether your sector restricts where OS packages, container images or vendor updates may come from, and whether a sovereign or air-gapped mirror is required. Confirm which change records and patch evidence the auditor expects for each OS source. These rules can override a technically preferred distribution, so settle them before the standard is written.
How DeployOpen scopes the OS and FreeIPA build decision
DeployOpen starts by writing down which operating system the FreeIPA servers will run, why, and who supports it for the life of the deployment. The work is then built, tested, documented and handed over inside your own infrastructure, with support available as a retainer if you want it.
How we scope
- The written scope records the chosen distribution, release channel and the lifecycle dates your team must plan around.
- We list which client platforms must enroll, and confirm each one against the client support boundaries you accept.
- Engagements are fixed-scope, so the OS decision, deliverables and timelines are agreed in writing before any build starts.
How we build
- We build the FreeIPA server hosts on the agreed distribution inside your cloud accounts, data centers or air-gapped network.
- Each server is checked for time synchronization, name resolution and package sources before FreeIPA is installed on it.
- Test replicas run through a planned upgrade path so the OS and FreeIPA version changes are rehearsed before production.
How we hand over
- You receive the OS build record, package source list, patch approach and the lifecycle calendar your team will maintain.
- Runbooks explain how to confirm vendor support status, what triggers a rebuild, and who approves a distribution change.
- Knowledge transfer sessions walk your engineers through the decision record so they can defend it to auditors and leadership.
How we support
- Ongoing support, OS and FreeIPA upgrades, and continuous testing are available as retainers after handover.
- Retainer reviews can track upcoming end-of-life dates and flag when a platform change needs its own scoped engagement.
- Ask any partner, including DeployOpen, to confirm current support terms in writing with the distribution vendor for your release.
