Which build fits: FreeIPA vs Red Hat Identity Management
Community FreeIPA and Red Hat Identity Management are built from the same upstream project, so the choice turns on support and platform rather than on directory, Kerberos or certificate features. Choose community FreeIPA when a skilled in-house team runs a non-RHEL or mixed estate without a contractual need for vendor support, and choose the RHEL-backed build when the estate is standardized on RHEL or when a contract, internal policy or auditor requires a named supplier. Red Hat only supports Identity Management on RHEL, so the vendor route is closed for Fedora, Debian or CentOS hosts. Start by listing which operating systems will run the identity servers and clients, then find out who must sign the support agreement.
The community build places patching, testing and replica operations on your team. The FreeIPA 4.13.4 release notes, dated July 9, 2026, describe fixes for two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, so someone must track upstream releases and schedule upgrades across every replica. Rehearse ipa-restore before an incident, because the backup documentation warns that restoring an outdated backup into an active replica topology can break replication. If your estate runs Fedora, Debian or CentOS, this operational load stays in-house. Red Hat documents a route for moving FreeIPA from non-RHEL distributions to IdM on RHEL 8, which is a planned platform change, so read the RHEL 8 migration guide before you commit to either path.
The RHEL-backed build fits when a procurement file, a regulator's examination or an internal control names a vendor that must answer for the identity service. Subscriptions for RHEL and its support are recurring costs paid to Red Hat, while migration and rebuild effort is usually one-time. Ask Red Hat which IdM version your subscription covers, whether support extends to the Active Directory trust and integrated CA settings you plan to use, and how errata timing compares with upstream fixes. Confirm packaging for each target platform on the FreeIPA downloads page, and ask for all of these terms in writing before you sign, since the quote should follow from your agreed scope.
How FreeIPA and Red Hat Identity Management differ on support and scope
This table compares the community FreeIPA project with Red Hat's supported Identity Management product across license, platform, support, update path, core services and migration tooling. Read it to see where the two share the same code base and where the vendor-backed build changes what you can deploy and who answers when something breaks.
| Area | Community FreeIPA | Red Hat Identity Management |
|---|---|---|
| License | GPL-3.0-or-later, with no paid edition of its own | Sold as a Red Hat subscription. Confirm the licensing and subscription terms directly with Red Hat |
| Supported operating systems | Packaged for Fedora, Debian and CentOS | Supported only on Red Hat Enterprise Linux. Confirm the supported RHEL versions with Red Hat |
| Support provider | Community project. No vendor support contract is included | Red Hat, under the RHEL subscription. Confirm the support scope and response terms with Red Hat |
| Update channel | Upstream releases such as 4.13.x, applied by you on your own packaging | Updates delivered through RHEL channels. Confirm the update and lifecycle policy with Red Hat |
| Core services | 389 Directory Server, MIT Kerberos KDC, Dogtag CA, optional ISC BIND DNS and NTP, OTP, AD trust and backup tools | Same upstream components packaged for RHEL. Confirm which features and configurations Red Hat supports |
| Migration tooling | ipa-backup and ipa-restore, ipa migrate-ds for LDAP sources, and manual LDIF for sudo and HBAC rules | Red Hat documents migrating FreeIPA on non-RHEL distributions and external LDAP to IdM on RHEL 8. Confirm the RHEL version your target needs |
Why support scope, not features, is the main split
The feature set is largely shared, so the decision turns on who supports the build, on which operating system, and under what contract. Red Hat ships the upstream FreeIPA project inside Red Hat Enterprise Linux as Identity Management, so the core components are the same: a 389 Directory Server LDAP directory, an MIT Kerberos KDC, a Dogtag certificate authority and SSSD on clients. Community FreeIPA is GPL-3.0-or-later with no paid edition of its own. Red Hat's Identity Management is the vendor-backed route, and its support is tied to RHEL. Before comparing feature lists, confirm the exact package versions you would run, the RHEL major version and minor release your contract covers, and whether the vendor's support terms reach the directory, CA and DNS components you plan to use.
For mixed estates, the consequence is direct. A Debian or Fedora host running community FreeIPA has no Red Hat support path for that server, even if the same team runs RHEL elsewhere in the environment. Red Hat's documentation covers migrating FreeIPA running on non-RHEL distributions, and external LDAP solutions, to IdM on RHEL 8, so the vendor route for those estates usually means a migration project, not a support contract added to the existing servers. Inventory every FreeIPA server, its distribution and its version, and map which ones carry production Kerberos, certificate issuance or AD trust duties. Those are the systems where an unsupported build creates the most risk.
Red Hat's Identity Management documentation index also lists an Upstream FreeIPA section that points to the FreeIPA project, which shows how the two relate: the vendor documents the upstream project and packages it, but the community project is where the code, release notes and CVE fixes for each upstream line are published. Ask your RHEL account team how fixes flow from upstream into the RHEL build and what timing applies to security errata, and compare that against the FreeIPA release notes you would otherwise track yourself. A regulated buyer should write those answers into its own patch and evidence procedures, because an auditor will ask who is accountable for a fix that lands upstream first.
Which build to choose by estate type
This fit applies when every identity server, replica and client runs Red Hat Enterprise Linux and your audit, procurement or risk policy requires a vendor to answer for the platform. Red Hat only supports Identity Management on RHEL, so the vendor-backed build is the one that matches this estate. You gain a supported path from installation through patching, and a named vendor channel for incidents and lifecycle questions.
- Support scope: Confirm that the RHEL major and minor release you plan to run is covered for IdM, and record the end-of-support date before you build.
- Incident ownership: Ask who opens and owns a severity case that spans IdM, 389 Directory Server and the certificate system, and whether your subscription covers it.
- Subscription terms: Ask what the subscription includes per server and whether replicas and certificate authority nodes each need coverage.
- Upgrade sequencing: Plan replica-by-replica upgrades and confirm the vendor's supported order, since the first server also handles certificate renewal and CRL publication by default.
- Recurring cost: Subscriptions recur every term, so the quote should separate one-time implementation from annual support.
Before signing, ask the vendor in writing for the supported RHEL release, the incident escalation path and the documented upgrade order for your replica count.
This fit applies when some identity servers or clients run Debian, Fedora or CentOS alongside RHEL. The community FreeIPA project packages for those distributions, so a single domain can span them, but the vendor's support statement does not cover non-RHEL hosts. Migration paths from FreeIPA on other distributions into IdM on RHEL 8 are documented, which gives a route to consolidate later.
- Support gap: Non-RHEL identity servers fall outside the vendor's supported scope, so any incident on them may leave you with community support only.
- Consolidation path: Red Hat documents migrating FreeIPA from non-RHEL distributions to IdM on RHEL 8, which lets you move servers in stages.
- Version drift: Different packaging sources can run different FreeIPA versions, so confirm version parity across all servers before any change.
- Replica placement: Keep each datacenter on a single distribution family where possible to simplify upgrade sequencing.
- Audit evidence: Document which hosts are covered by a support contract and which are not, because auditors will ask.
Before committing, verify the RHEL version each server will run, the exact FreeIPA version on every node and the migration steps your team would follow.
This fit applies when your platform or identity engineers already operate FreeIPA, have tested backup and restore, and face no written requirement for a vendor to support the identity platform. The community build is free to use under GPL-3.0-or-later, and the team controls the release cadence, which can suit an estate that values fast access to the upstream project.
- Cost profile: The license is free, so the main costs are staff time, testing environments and any third-party support you choose to buy.
- Upstream currency: Community releases such as 4.13.4, dated July 9, 2026, carry the security fixes, and your team must apply them promptly.
- Operational discipline: Backup and restore must be rehearsed, because restoring an outdated backup into an active replica topology can break replication.
- Replica design: Follow the published deployment recommendations on replica count, replication agreements and dedicated servers.
- Key-person risk: Document runbooks so that more than one engineer can handle certificate renewal and replication repair.
Before relying on this path, ask a qualified partner to review your runbooks and confirm that your team can restore a backup into a test topology without disrupting production.
What the license and support terms mean for each build
The two builds share most of their code, but they differ in who stands behind them. The cards below separate the license, the support contract, the update path and the contract terms you must confirm before choosing either one for a regulated estate.
Community license with no paid edition
FreeIPA is licensed under GPL-3.0-or-later, and the community project offers no paid edition of its own. You can run, modify and redistribute it without a license fee. The cost of the community build is the internal or contracted engineering time to install, patch, back up and operate it. If your compliance evidence depends on a named vendor's accountability, a free license does not supply that.
Community support through project channels
Support for the upstream build comes from the FreeIPA project's public channels and the people who maintain it, with no contractual response commitment. Questions are answered when maintainers or community members have time. Teams that need a guaranteed response window must buy it from a third party, so the support model should be decided before a production incident, not during one.
What a Red Hat subscription covers
Red Hat supports Identity Management only on Red Hat Enterprise Linux, so the subscription attaches to the RHEL host platform as well as IdM. Ask Red Hat in writing which components, versions, architectures and deployment patterns the subscription covers, and whether migrated systems from FreeIPA on other distributions fall inside that scope. Confirm these in the subscription agreement, not in marketing material.
Patch timing for community releases
Community fixes arrive when the project publishes them. FreeIPA 4.13.4, dated July 9, 2026, fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials. Your team must watch the release notes, test the update in a replica topology and schedule the change. Compare that with the vendor's own update channel, and ask how fast security errata reach RHEL-hosted IdM.
Indemnity, service levels and end-of-life dates
Before you rely on either build, confirm in writing the indemnity terms, the service level commitments, the support window for each release and the end-of-life date for the RHEL and IdM versions you plan to run. None of these are stated for the community build, and the vendor terms are set in its agreement. A regulated buyer should attach these answers to the risk file, because an auditor will ask who is accountable when a fix is late.
What Red Hat Identity Management subscriptions cost and what drives it
This table sets out who pays for each cost component in a community FreeIPA build and a Red Hat Identity Management build on RHEL, and what recurs over time. Read it as a checklist for a quote request, since Red Hat does not publish a price in the sources supplied for this page and the final figures depend on your tier, support level and term.
| Cost component | Community FreeIPA | Red Hat Identity Management on RHEL |
|---|---|---|
| Software license | None. FreeIPA is GPL-3.0-or-later with no paid edition of its own. | Red Hat subscription for IdM on RHEL. Ask Red Hat for the subscription tier and support level that covers your IdM servers and clients. |
| Operating system subscription | Not required by the license. Choose a distribution you can patch and support internally, such as one packaged FreeIPA release. | RHEL subscription for every IdM server. Confirm whether clients and other hosts in scope also need RHEL subscriptions in your estate. |
| Hardware or cloud footprint | Dedicated servers or VMs for each replica, following the deployment recommendations, plus DNS and PKI placement. | Same server footprint, but planned on RHEL-supported platforms and hypervisors. Confirm supported configurations with Red Hat. |
| Replica count | Plan at least two to three replicas in each datacenter, the number the FreeIPA deployment recommendations advise. Each replica adds hardware and patching work. | The same topology applies, so the subscription count often follows server count. Ask whether replicas are billed individually and whether a standby or test system carries a separate charge. |
| Implementation and migration effort | Internal or partner time for design, install, and migrating from another distribution or LDAP source using the migration tools. | Similar design and migration work, plus the migration path from FreeIPA on non-RHEL distributions that Red Hat documents for IdM on RHEL 8. Scope it in writing. |
| Internal staff time | Ongoing patching, upgrades, backups and CVE response handled by your own team, which must track upstream releases. | Lower dependence on upstream tracking for supported RHEL builds, but your team still runs operations, monitoring and backup verification. |
| Ongoing support or retainer | Community support through mailing lists and project resources, or a paid retainer with a provider if you need guaranteed response. | Red Hat subscription support for IdM on RHEL. A separate retainer with an implementation partner is optional and covers work outside the subscription. |
| Recurring versus one-time | Mostly recurring staff time and hardware refresh. Little or no license spend. | Recurring subscription renewals for the term you buy, plus one-time migration and design costs. |
Moving from community FreeIPA on another distribution to IdM on RHEL
This sequence moves an existing community FreeIPA deployment on a non-RHEL distribution onto Identity Management on RHEL, with the topology, certificate authority role and sudo and HBAC policy accounted for before cutover. The result is a validated IdM environment on RHEL that clients resolve and authenticate against, with a rollback point kept until replication and DNS checks pass.
Inventory the existing topology and CA role
The platform engineering lead maps every FreeIPA server, its replication agreements, its installed roles and its DNS and PKI services. Pay particular attention to the first server, which handles certificate renewal and CRL publication by default, so the CA role is not lost during the move. Also list the users, groups, hosts, sudo rules and HBAC rules that must carry over. The step is complete when the team has a written topology diagram and a list of every service that depends on each server.
Take a verified full backup with ipa-backup
The identity team runs
ipa-backupon the source server to create a full backup, and stores it off the host with its checksum recorded. Confirm the backup contents and that it can be read on a test system before any change is made. Record which server produced the backup, because restoring an outdated backup into an active replica topology can break replication, so the backup must match the state you intend to migrate. The step is complete when the backup is stored, documented and verified.Build the target IdM environment on RHEL
The platform team provisions RHEL hosts for the target IdM topology, with dedicated servers that run no other applications and enough replicas in each datacenter to match the source design. Check the RHEL 8 migration guide against the release you plan to deploy, since the supplied migration documentation is written for RHEL 8. The step is complete when the new servers are installed, patched and reachable, and the planned replica count is confirmed against FreeIPA's deployment recommendations.
Migrate FreeIPA data into the RHEL target
The identity engineer follows the FreeIPA to FreeIPA migration path to move the directory data, CA material and configuration into the RHEL build. Run the migration in a non-production copy first, then compare object counts for users, groups and hosts against the source. The step is complete when a test client can authenticate against the new environment and the CA can still issue and renew certificates.
Move users from other LDAP servers with ipa migrate-ds
Where accounts live in a separate LDAP directory rather than FreeIPA, the identity engineer runs
ipa migrate-dsto import users and groups. Kerberos attributes are excluded because FreeIPA regenerates them, so users must set or reset credentials after import. Validate the imported accounts against the source directory and confirm group membership. The step is complete when the imported population matches the source for the agreed scope and the exceptions are documented.Rebuild sudo and HBAC rules through LDIF
Sudo and HBAC rules do not migrate automatically, so the identity engineer exports them from the source as LDIF, reviews each rule for scope and intent, and imports the approved rules into the RHEL target. Access rules are a security control, so a second reviewer should compare the rebuilt rule set against the source before any client relies on it. The step is complete when a documented rule-by-rule comparison shows every sudo and HBAC rule was rebuilt or intentionally retired.
Validate replication and client DNS settings
The operations team checks that replication agreements are healthy across all new replicas, that no replica exceeds the agreement limit in the deployment recommendations, and that PKI and DNS run on the replicas where they are required. On each client, confirm that
resolv.conflists at least two DNS servers and that SSSD authenticates against the new environment. The step is complete when replication status is clean, test logins succeed from every site and the validation results are stored with the change record.Cut over clients and keep the rollback point
The change owner schedules the cutover, repoints clients and services to the RHEL environment and confirms that authentication, certificate issuance and renewal work after the switch. The source servers stay intact as a rollback point until the new environment has run cleanly, and they are not reintroduced into the active topology without a current backup review. The step is complete when the change record shows successful authentication from each client group and the decommissioning plan for the old servers is approved.
When a regulated buyer needs the vendor-backed build
Vendor backing matters most when a procurement rule, not a technical preference, decides the platform. Many regulated buyers must name a supplier that holds a support contract, and some must show a vendor escalation path for incidents and change tickets. Red Hat only supports Identity Management on Red Hat Enterprise Linux, so a buyer whose policy requires a named supplier for the directory, Kerberos KDC and Dogtag certificate authority will look at IdM on RHEL, not at community FreeIPA on Fedora, Debian or CentOS. Ask procurement whether the requirement is a contract with a supplier for the full stack, or only for the operating system, because the answer changes which build qualifies.
Controls evidence is the second driver. Change management, incident response and patching records are easier to present when the platform has a published lifecycle and vendor advisories that you can cite in your own tickets. Community FreeIPA publishes its own release notes, such as the 4.13.4 notes that describe two fixed CVEs in LDAP access control and API authentication checks, but your team must watch those releases and show how each one was tested and applied. A vendor-backed build shifts part of that tracking to the supplier, and that shift is what the assessor may weigh. Confirm with your assessor which artifacts they accept, such as a vendor lifecycle statement, your own patch log, or a tested restore of an ipa-backup archive.
An in-house team can satisfy the same expectations on community FreeIPA if it has documented runbooks, tested recovery, named owners for each replica and a tracked upgrade policy. The FreeIPA backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so a runbook for that scenario matters more than the support label. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms, and it prepares systems and evidence for compliance assessments, but it does not issue audit reports or certifications. Auditors and certification bodies make that determination. Ask your assessor, before you buy either build, whether community FreeIPA with documented procedures will be accepted for your control set.
Questions buyers ask before choosing Red Hat Identity Management
Can community FreeIPA run on Debian, Fedora or CentOS, and what support is there?
Yes, FreeIPA is packaged for Fedora, Debian and CentOS, according to the FreeIPA downloads page, so it can run on those distributions. The support model is the difference. FreeIPA is a community project with no paid edition of its own, so support comes from the community, from your own staff, or from a third party you contract with. Red Hat only supports Identity Management on Red Hat Enterprise Linux, so a Debian or Fedora deployment will not carry Red Hat's support terms. Before you commit, confirm with your distribution vendor and your own risk team which patch windows, CVE response and escalation paths you will rely on. FreeIPA 4.13.4, dated July 9, 2026, fixed two CVEs, so patch cadence is a real operational item on any distribution you choose.
How much effort does migrating from another Linux distribution to IdM on RHEL take?
The effort depends on four drivers: topology size, the number of custom sudo and HBAC rules, the external LDAP sources feeding identities, and how much of your Kerberos and certificate setup must be rebuilt. Red Hat documents migrating FreeIPA running on non-RHEL Linux distributions to IdM on RHEL 8, so the path is supported in principle. FreeIPA's migration guidance notes that the ipa migrate-ds command moves users and groups from other LDAP servers, but sudo and HBAC rules need manual migration through LDIF. Replication topology, the first server's role in certificate renewal and CRL publication, and backup state also shape the cutover plan. Ask for a migration assessment that inventories these four items before agreeing on scope.
Can an organization move from community FreeIPA to RHEL-backed IdM later?
Yes, the move is documented as a migration path, but it is a planned cutover, not a package swap. Red Hat's guidance covers migrating FreeIPA from non-RHEL distributions to IdM on RHEL 8, and FreeIPA publishes a FreeIPA to FreeIPA migration page for moving between installations. A cutover typically needs a current backup, a tested restore plan, and a replication design that avoids restoring an outdated backup into an active topology, which FreeIPA's backup documentation warns can break replication. Plan for client re-enrollment checks, certificate authority continuity, DNS and time service validation, and a rollback window. Confirm the exact steps for your version with Red Hat and your own test environment before scheduling production work.
Which cost components should be requested in a quote for either build?
Ask for each component separately so the two builds can be compared on equal terms. For community FreeIPA, the software carries no license fee under GPL-3.0-or-later, so the costs are the infrastructure, the operating staff, the testing and upgrade effort, and any third-party support you contract. For Red Hat Identity Management, the subscription for RHEL and the support entitlement are recurring costs you must confirm with Red Hat directly. Request one-time items (design, migration, hardening, documentation, training) apart from recurring items (subscriptions, patching, backups, support retainers). Ask what drives each figure up or down, such as the number of replicas, the number of hosts enrolled, and whether AD trusts are needed. Note that FreeIPA's deployment guidance recommends two to three replicas per datacenter, which affects infrastructure cost directly.
Can DeployOpen implement either FreeIPA or Red Hat Identity Management, and who sets the scope?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, which covers community FreeIPA. Most engagements are fixed-scope, and the scope, deliverables and timelines are agreed in writing before work starts. Red Hat Identity Management is a Red Hat product, and DeployOpen is not a Red Hat partner, so any work on RHEL-backed IdM should be confirmed with you and with Red Hat's support terms before scoping. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications.
Do I need a DeployOpen engagement if my team can run FreeIPA alone?
That depends on how many people you have who know Kerberos, LDAP replication, the integrated certificate authority and DNS well enough to handle an incident without outside help. FreeIPA combines 389 Directory Server, an MIT Kerberos KDC and a Dogtag certificate authority, so a fault can cross several components. Your team should be able to run ipa-backup and ipa-restore, verify replication after patches, and handle certificate renewal on the first server. If those skills are thin, a fixed-scope engagement can cover the design, hardening and documentation, followed by a retainer for upgrades and testing. Ask for a written list of tasks each side will own before signing.
What does FreeIPA's Active Directory trust need from my network and DNS design?
A cross-forest trust with an Active Directory domain is possible on Windows Server 2008 R2 or later, so AD users can reach Linux resources. The main design constraint is that the IPA domain must use a DNS domain that does not overlap with any domain in the AD forest. Samba components handle the trust, so confirm the versions your distribution ships. Plan DNS carefully, since FreeIPA's deployment recommendations advise at least two DNS servers in each client's resolv.conf and at least one replica running DNS per datacenter if DNS is used. Test the trust in a non-production environment first, and confirm with your AD administrators how group mappings and sudo rules will apply.
How DeployOpen scopes and supports either build
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so the work on FreeIPA follows the same method whichever build a team chooses. The first decision is which build the organization can support, and that decision shapes the written scope before any installation begins.
How we scope
- Confirm the operating system estate, including whether existing FreeIPA servers run on RHEL or on another distribution.
- Record which services the written scope covers: directory, Kerberos, the integrated certificate authority, DNS and host policy.
- Agree in writing whether the engagement is fixed-scope, with deliverables and timelines set before work starts, and whether ongoing support will follow as a retainer.
How we build
- Design replica topology per datacenter, following the vendor's deployment recommendations for replica count and replication agreements.
- Set up backup and restore procedures, and test a restore in a non-production environment before relying on it.
- Plan any migration from another distribution or external LDAP source, including manual transfer of sudo and HBAC rules.
How we hand over
- Document the installed topology, certificate authority choices, trust configuration and recovery steps for your operations team.
- Provide runbooks for patching, replica addition and removal, and the checks to run after an upgrade.
- Deliver evidence of configuration and testing that your internal assessors or external auditors can review, without DeployOpen issuing any audit report.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped in writing alongside the build.
- Confirm with Red Hat which support subscription, if any, applies to your RHEL-based deployment before relying on vendor support terms.
- Retest after major releases, security advisories and changes to trust or certificate configuration in your environment.
