How FreeIPA client and server version compatibility shapes your rollout
If your estate runs mixed Linux client operating systems and the FreeIPA server platform needs to move, plan client and server versions together. Confirm the support position for each client OS before any server change starts, because a server upgrade or migration that looks routine can leave some enrolled machines outside the versions their vendor supports.
FreeIPA is not one service. It combines 389 Directory Server, MIT Kerberos, the Dogtag certificate system, SSSD on clients, and optional ISC BIND DNS and NTP, as described on the FreeIPA About page. For a user to log in, the client side matters as much as the server: SSSD on each machine resolves identities, requests Kerberos tickets, applies access rules and caches credentials. A client running an older SSSD or a different OS release can behave differently from the server's assumptions, so compatibility is tested per client OS, not assumed from the server version.
The researched material for this topic does not include a client OS support matrix. For RHEL 7, 8 and 9 clients, confirm the support statement against Red Hat's own lifecycle and product documentation for the exact minor releases in your estate, and record the answer per host group. Ask your platform team to build an inventory of OS version, SSSD version and enrollment method for each group, then test a representative client from each group against a staging FreeIPA server before the production server moves. Treat any group without a confirmed statement as a blocker for the server change, not as a later clean-up item.
Which client operating systems to check, by estate type
RHEL-based estates are the closest match to FreeIPA's own packaging, since FreeIPA comes from the Red Hat ecosystem and the client packages are maintained alongside the server. Start by checking the support statement that your distribution publishes for each client major release, including RHEL 7, 8 and 9 if they are still in your estate. Support statements state which server and client combinations the vendor tests, so read them before assuming a client will work with a newer server.
- Client support statement: Confirm in the vendor's lifecycle and support documentation whether each client release is still supported and which IdM or FreeIPA server versions it is listed against.
- SSSD and client package versions: Check the
sssdandipa-clientpackage versions shipped on each release and compare them with the protocol and configuration expectations in the FreeIPA release notes for your server version. - Packages you may have pinned: Look for locally pinned or backported packages that differ from the vendor build, because they can fall outside the statement.
- Test host set: Enroll one host per client major release in a lab realm, then test login, sudo, host access rules and certificate requests against the target server version.
- Security updates: Confirm that the client packages on each release include the fixes listed for your server version, including the fixes in the FreeIPA 4.13.4 release notes.
Before a server upgrade, write down each client release, its support status and the packages it runs, and confirm each row with the vendor and your server's release notes.
Ubuntu and Debian clients can join FreeIPA through SSSD and the client packages those distributions ship, but the support position differs from RHEL-based estates. FreeIPA's own release process is built around Red Hat platforms, so the compatibility of a Debian or Ubuntu client with a given server version is something you must establish for your own release and package set rather than assume from the server release notes. Ask the distribution and the FreeIPA project for the position on your exact combination.
- Support position: Ask whether the distribution or any commercial provider you use supports FreeIPA client enrollment on each Ubuntu or Debian release, and get the answer in writing.
- Package versions: Compare the
sssd,krb5andfreeipa-client(or equivalent) package versions on each release with what your FreeIPA server version expects. - Release cadence: Check how long each release receives security updates, since client packages on short-cycle releases may change faster than your server plan.
- Lab enrollment: Enroll representative machines, including one per release you run, and test Kerberos ticket issuance, SSSD caching, SSH key lookup and sudo rules.
- Configuration drift: Verify that
sssd.conf,krb5.confand PAM settings produced by the installer match your standard, since defaults can differ between releases.
Record each Ubuntu or Debian release in your estate with its package set, and run the lab tests again after every server upgrade before you move production clients.
Mixed estates usually combine several client OS families, several major releases and some hosts that were enrolled years ago and never reviewed. The main risk is not one incompatible release but the number of combinations nobody has recorded. Legacy clients may run SSSD or Kerberos configuration written for an older server, and they may depend on packages that the current vendor no longer maintains. Treat the inventory as the first deliverable, because you cannot plan an upgrade sequence for hosts you have not identified.
- Inventory: Export the enrolled host list from the server and match each host to its operating system release, SSSD version and enrollment date.
- Unsupported releases: Identify hosts on releases whose vendor support has ended, and confirm with the vendor what remains available for them.
- Client upgrade ordering: Plan to upgrade clients to a supported release before you upgrade the server, if the server upgrade would otherwise move them outside the support statement.
- Lab matrix: Test each distinct OS and SSSD combination that remains in production, not only the newest one.
- Rollback path: Keep a documented way to re-enroll or roll back a client, using the re-enrollment steps in your operations runbook, if a test fails.
Before you approve a server upgrade for a mixed estate, confirm the support status of every client combination in the inventory and the test result for each one.
Choosing the order of server and client upgrades
This table compares four ways to sequence FreeIPA server and client work, with the main risk and prerequisites for each. Use it to pick the option that matches your client support position and migration plans, then confirm the prerequisites before any host is touched.
| Option | When it fits | Main risk | Must be true before starting |
|---|---|---|---|
| Upgrade servers first | Clients are on a version that the newer server release still supports, and you want the directory tier current before touching endpoints | Clients that fall outside the supported set may lose the ability to authenticate or enroll cleanly | Confirmed client support statement for each OS version in use, and a tested backup of the topology |
| Upgrade clients first | Client fleet is due for OS work and the current servers stay in place for now | Newer client packages may expect server behavior the current servers do not provide | Client test group validated against the existing server release, with a rollback plan for each OS image |
| Run a parallel server migration | You are moving to new server hosts or a new platform rather than in-place upgrading existing ones | Replication, DNS and certificate authority state can diverge between old and new topology | Migration path confirmed for your version pair, and a tested backup or export of users, hosts, certificates and policies |
| Upgrade both in one window | Small estate with few clients and a short, fully rehearsed change window | Failures are hard to attribute, and rollback of one tier may not match the other | Rehearsal in a non-production realm that matches your clients, and a written decision on which tier to roll back first |
What recent FreeIPA releases change for enrolled clients
Recent FreeIPA server releases change what enrolled clients can take advantage of, so check client behavior before you upgrade the server. FreeIPA 4.13.0 introduced DNS over TLS between clients and IdM DNS servers, LDAP system accounts, and random certificate serial numbers by default, according to the FreeIPA 4.13.0 release notes. Each of these changes a different part of the estate: DNS traffic from enrolled hosts, the accounts that bind to the directory, and the certificates the server issues.
The feature that needs the most care is DNS over TLS, because it depends on the client side as well as the server. A server can offer encrypted DNS only if the resolver and SSSD configuration on each client can use it, and that depends on the distribution and its packages. Before you enable it, confirm with your distribution vendor and in a test enrollment which client versions and resolver setups support it, and confirm that clients can still resolve IdM names if they cannot. The same check applies to any client that depends on a fixed serial number pattern or an LDAP bind account, because those are server-side defaults that existing tooling may not expect.
FreeIPA 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, and hardened authentication checks across the API, according to the FreeIPA 4.13.4 release notes. That makes keeping servers current a security question as well as a compatibility one, because a server that is behind on security fixes exposes every enrolled client to the same directory. Read the full notes for the affected versions and the fix list, then schedule server updates on a timeline that your change process can support.
How to sequence client and server upgrades around a migration
This sequence keeps logins working throughout a FreeIPA server migration by checking every client against the target server release before anything changes, and by proving each stage with a backup, a replication check and test logins.
Inventory every enrolled client
Build a list of every enrolled host with its OS release, SSSD version, client package version and the owner who can schedule a change window. Pull the data from your configuration management or inventory tool, then cross-check it against the host list in the FreeIPA web UI so that machines enrolled outside your normal tooling are not missed. The step is done when every host appears once, with a version and an owner, and the count matches what your identity team expects.
Confirm client support against the target server
For each OS and SSSD combination in the inventory, check the support position for the target FreeIPA server release and record it in the same list. Confirm the statement with your distribution vendor and with the FreeIPA release documentation, because support positions differ for RHEL, Ubuntu and Debian clients. Mark any combination you cannot confirm as blocked until the vendor answers in writing. The step is done when every row has a support status and blocked rows have an owner.
Take and verify an ipa-backup
Run a full ipa-backup on the server that holds the certificate authority role and on the other servers you plan to change, then copy the archives off the host. Restore a copy into a lab environment or use the verification steps in the backup documentation to confirm the archive is readable. Record where each backup is stored and who can restore it. The step is done when each archive is verified and stored outside the servers being changed.
Rehearse the change on a non-production replica
Build a test topology that mirrors production server versions, replication agreements and DNS settings, and run the planned server move or upgrade there first. Use the restored backup from the previous step as the starting data. Record every command, every warning and any change in replication behavior. The step is done when the rehearsal ends with replication healthy on all test servers and a written runbook that matches what you actually ran.
Check replication before each server change
Before touching any production server, confirm that replication is healthy between all servers, that no replication errors are pending and that the server being changed is not the only holder of a role your clients depend on. Do not restore an older backup into an active replica topology, because the backup documentation warns that this can break replication. The step is done when a written check shows healthy replication and the change window is approved.
Move or upgrade servers in the agreed order
Change the production servers one at a time in the order set by the rehearsal, starting with replicas that carry the fewest client dependencies. Run the replication check again after each server, and stop the sequence if any server reports errors. Keep the previous server available until the new one has passed the test logins in the next step. The step is done when every server is on the target release and replication has been confirmed after the final change.
Test a login on a sample host from each OS
After the servers are changed, log in on one sample host from each client OS and SSSD combination with a password and, where used, a second factor. Confirm that a Kerberos ticket is issued with kinit or the equivalent, that sudo and SSH key lookups resolve and that the host can reach the expected DNS servers. Record the results in the inventory. The step is done when every combination in use has a passing sample login recorded.
Upgrade clients in waves with checks
Upgrade clients in small waves grouped by OS and SSSD version, starting with non-critical hosts. After each wave, run a login and Kerberos check on a sample of the hosts in that wave and review SSSD logs for authentication errors. Pause the next wave if a check fails, and roll back that wave before continuing. The step is done when every wave has passed its checks and the inventory shows the new client versions.
What goes wrong when clients and servers fall out of step
Most FreeIPA version problems show up as failed logins, broken replication or access rules that behave differently on some hosts than others. Each card below names one failure, the symptom to look for and the control that reduces it before it reaches users.
Login failures on unsupported client OS
A client running an operating system release that the FreeIPA server version does not support may fail Kerberos ticket requests, host enrollment or SSSD lookups, often only after a server upgrade. Users see password prompts that never succeed while other hosts work. Before upgrading the server, inventory every client OS release and compare it against the support statement for the target server version. Test one host of each release against a staging server first.
SSSD expecting features the server dropped
An SSSD configuration written for an older server may reference options, schema attributes or behavior that the newer server no longer provides, so lookups return empty results or authentication falls back unexpectedly. The symptom is often a single host that behaves differently after its configuration was copied from an older build. Review sssd.conf on a sample of hosts after each server upgrade, and remove settings copied from old templates.
Restoring an outdated backup into replicas
The backup documentation warns that restoring an outdated backup into an active replica topology can break replication. The symptom is replication agreements that report errors, and servers that disagree about users, hosts or certificates. Restore only into a rebuilt or isolated environment, confirm which server holds the current data, and plan the restore as a topology change rather than a single-server fix.
Server CVE fixes clients cannot yet use
A security release on the server can close flaws such as LDAP access control issues without any change on the clients, so the fix only takes effect once every server is patched. Hosts still running older client packages may not receive the same authentication hardening. Track the security release notes, patch all replicas in the same window, and confirm client package levels on the hosts that matter most.
Users migrated, client config left behind
A migration can move users, groups and policies into a new FreeIPA deployment while the old client configuration still points at the previous servers, realm or LDAP settings. The symptom is hosts that resolve the old realm, cache stale identities or fail to find the new servers. Plan client re-enrollment or reconfiguration as part of the migration, and track which hosts have moved.
Questions buyers ask about client and server version planning
Can one FreeIPA server serve client machines running different OS versions?
Yes, an estate can usually run clients on more than one OS release against a single server, but whether a specific client version is supported with a specific server version must be confirmed before rollout. Confirm the pairing against the vendor statement for your server release and your client distribution, then prove it on a test replica that matches your production configuration. Do not assume that an older client that enrolled cleanly will keep working after a server upgrade, because the authentication and SSSD behavior you rely on is what changes. Record each confirmed pairing in the change plan so that every server migration starts from a written compatibility list.
How much effort does a FreeIPA client compatibility review take?
The effort depends mainly on four things: the number of hosts, the number of client OS releases in use, how much custom SSSD configuration exists, and how many server migrations are planned in the coming years. A small estate with one client release and default SSSD settings needs a short review, while a mixed estate with hand-tuned domain sections and several planned server upgrades needs a longer one. Ask any provider to break the quote into inventory, test work, documentation and retesting, and to state which of those items recur at each server migration. The quote should follow from a written scope, not from a general estimate.
What does our team need to provide for a compatibility review?
The review needs four inputs from your side. First, an inventory export listing hostnames, OS releases, SSSD versions and any custom configuration files under the SSSD and PAM settings. Second, a test environment, ideally a test FreeIPA replica that mirrors your production server version and a sample of each client OS release. Third, change windows agreed in advance for test and production work. Fourth, named owners for identity, host administration and application teams who can approve test results and accept the rollout order. Without these inputs, the review can only describe the risks, not verify them.
Can our own team run the compatibility review without a partner?
Yes, a capable identity or platform team can run the review itself. The starting points are the FreeIPA release notes for each server version you plan to reach, the vendor statement for the client OS releases you run, and a test replica where you can enroll sample clients and exercise logins, sudo, host-based access rules and certificate use. Plan for the review to include retesting after each server migration, not only before the first one. A partner adds value when the team lacks time, has no test environment, or wants the findings documented as a repeatable procedure for later migrations.
What does a fixed-scope FreeIPA compatibility engagement cover?
A fixed-scope engagement covers the agreed deliverables written down before work starts, which for this topic typically means an inventory assessment of the client estate, a compatibility matrix for the server and client versions in scope, test results from the agreed test environment, a rollout order with rollback notes, and updated documentation. Whatever is out of scope, such as application-side changes or client OS upgrades themselves, should be listed explicitly. Scope, deliverables and timelines are agreed in writing before work starts, so ask for the exact list of deliverables and the acceptance steps in the proposal.
What should we ask for in a quote for client upgrade planning?
Ask for the quote to separate one-time work from recurring work. One-time work includes the inventory, test replica setup, initial compatibility review and the first rollout plan. Recurring work includes retesting before each server migration, updates to the compatibility record when new client releases appear, and any ongoing support you choose to buy. Ask which assumptions the price rests on, such as the number of client OS releases, the number of hosts sampled in testing, and how many server migrations are included. Also ask who performs each step and what evidence you will receive at the end.
What to confirm in your environment before you commit
The researched facts for FreeIPA do not settle which client releases match a given server release, so the items below are the checks to close before you commit to a version pairing. Each card names who can confirm the answer: Red Hat, the distribution vendor, the FreeIPA project, or your own test environment.
RHEL 7, 8 and 9 client support
Red Hat's support statement decides which RHEL client releases you can run against your exact IdM server release, and it is not the same thing as whether the packages install. Confirm the pairing for each RHEL major version in your estate, including any clients you plan to keep on older minor releases. Ask Red Hat in writing, and record the answer in your change plan before any host is enrolled or re-enrolled.
Non-RHEL client distributions
Ubuntu, Debian, SUSE and other clients use the same SSSD and client packages, but support for them against a given FreeIPA server is a separate question. Confirm with the distribution vendor or the FreeIPA project whether your distribution release is supported for your server version, and do not assume a working login means a supported configuration. Test enrollment, SSSD caching and sudo behavior on a representative host before you expand.
Client-side status of 4.13 features
Features such as DNS over TLS between clients and IdM DNS servers and LDAP system accounts were introduced in 4.13.0, but the release notes do not settle how each client platform handles them. Ask the FreeIPA project which client packages must be present for each feature, and confirm the behavior in your own test environment. Also check whether the new web UI beta affects any administration workflow your team depends on.
Upgrade path from your current server release
Confirm which server releases you can move through directly, and in what order, before you change the server tier. The 4.13.4 release notes describe a security release with fixes for LDAP access control and authentication checks, so a server running an older 4.x release may need a planned move to that line. Confirm the supported path with the FreeIPA project, then schedule client upgrades to follow the server state you have verified.
Third-party integration status
Samba file servers on IPA clients, Keycloak federation over SSSD, and AD trusts each depend on component versions that move independently of FreeIPA. Confirm with each vendor or project which versions have been tested together with your server release. For AD trusts, check the Samba components that FreeIPA relies on, because a version mismatch can break authentication for Windows users long after the server upgrade looked complete.
Release notes that affect enrolled hosts
Read each release note for changes that touch enrolled clients, such as default certificate behavior, configuration keys read by SSSD, or changed client-side tooling. The 4.13.0 notes state that random certificate serial numbers are now the default, which can matter to systems that track certificates by serial. Confirm the full list of client-facing changes with the FreeIPA project, then test those changes on a host that mirrors production before rollout.
How DeployOpen scopes client and server upgrade work
DeployOpen plans FreeIPA client and server version compatibility as written work inside your own infrastructure, before any host is touched. The scope records which client operating systems and which FreeIPA server versions are in play, the order of server and client changes, and what is tested and handed over.
How we scope
- Inventory every server, replica and client OS version, with the FreeIPA release each one runs today.
- Confirm the target server version and which client releases your estate can run against it.
- Agree the upgrade order, rollback points and affected services in writing before work starts.
- Record which clients, scripts and automation depend on specific SSSD or client package versions.
How we build
- Build a staging topology that mirrors your production replicas, DNS locations and client mix.
- Upgrade servers in the sequence agreed in scope, checking replication health after each step.
- Test sample clients from every OS family on the target server, including login, Kerberos and sudo.
- Take and verify a full backup before each server change, not only at the start of the project.
How we hand over
- Deliver a dated compatibility matrix listing tested server and client combinations and their results.
- Provide the upgrade runbook with commands, checkpoints and the rollback procedure for each step.
- Document remaining unsupported or untested client versions and the plan to retire them.
- Walk your operations team through the runbook and the evidence produced during testing.
How we support
- Fixed-scope engagements end with the agreed deliverables and a written handover.
- Ongoing support, upgrades and continuous testing are available as a retainer.
- Retainer work can cover re-testing clients when new FreeIPA or operating system releases appear.
- Ask any provider to confirm which vendor support statements apply to your exact versions.
