FreeIPA security releases: tracking and applying fixes

How FreeIPA security releases reach your servers and why they matter now

Your FreeIPA servers issue the Kerberos tickets that let users log in across your Linux estate and the certificates that services depend on, so a security fix in FreeIPA is a change to the identity layer itself. FreeIPA combines 389 Directory Server for the directory, MIT Kerberos for the KDC, the Dogtag certificate system for issuance and SSSD on clients, and it is licensed under GPL-3.0-or-later as a community project with no paid edition of its own. Nobody sends you a vendor-managed patch. Security fixes arrive as ordinary release updates that your team, or your partner, must choose to apply, roll out and verify on every server.

The release that raises the question now is FreeIPA 4.13.4, a stabilization release dated July 9, 2026. It fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, and it hardened authentication checks across the API. Those are the kinds of fixes that should not wait for a quiet maintenance window to be scheduled weeks later. Confirm the affected version range and the exact package names for your distribution against the release notes and your own package inventory before you plan the change, because the fix only protects servers that actually receive the new packages.

The central question is how to get the fix applied safely across a multi-master topology. Every replica is a live authentication source, so a partial rollout leaves some servers patched and others exposed, and an update applied in the wrong order can disturb replication. Before you start, decide who owns the change, which replicas update first, how you will confirm each server runs the fixed version, and how you will check that LDAP access and API authentication behave as expected afterward. The sections that follow set out each of these steps.

Patch options for FreeIPA security releases compared

This table compares four ways to apply a FreeIPA security release across replicas: one maintenance window, a rolling update by replica role, a staged run through a test topology, and deferring to the next scheduled release. Read each row against your own topology, change window and assessor expectations, then decide which option your estate can support without leaving servers on mixed versions for long.

Option	Risk of mixed versions	Effort on operations	Rollback path	Fit for a regulated estate
Single maintenance window for all servers	Low, because every server moves in one window, but a partial failure can leave a mixed set	High coordination, with all replicas, DNS and PKI servers changed together	Restore from a pre-change backup, which must be current to avoid breaking replication	Fits when the change board wants one approved window and evidence in one record
Rolling update by replica role	Moderate, since some replicas run the old release while others run the new one	Moderate, with ordered steps and checks between each server	Roll back the server just changed, while the rest of the topology stays on the old release	Fits when uptime targets matter and the team can prove each step in the change record
Staged update through a test topology first	Low in production, because the sequence is proven before live servers change	High, since a test topology must mirror production roles, DNS and trust settings	Test results guide production rollback steps, which still rely on current backups	Fits when assessors expect pre-production testing evidence before a security fix goes live
Deferring to the next scheduled release	High, because known fixes remain on every server for longer	Low now, but deferred work accumulates into a larger future change	No rollback is needed, though the exposure window stays open	Rarely fits when a security fix addresses access control or authentication flaws

What FreeIPA 4.13.4 fixed and what it means for LDAP access

The FreeIPA 4.13.4 release notes describe two fixed CVEs. One set of fixes covers LDAP access control flaws that could let unauthenticated clients obtain credentials, and the other hardens authentication checks across the API. Because LDAP is the path that applications, sudo and older tools use to read directory data, treat the LDAP fix as the one that changes your exposure first. Do not rely on this page for the identifiers. Open the FreeIPA 4.13.4 release notes, copy the CVE IDs and the affected versions from there, and record which of your servers and replicas run a version in that range.

Next, list every LDAP consumer in your environment, including service accounts, application binds and monitoring checks that query cn=compat or the directory suffix. Confirm which of them connect anonymously or with credentials that could be exposed, since those are the flows the access control fix is meant to protect. Ask your vendor or the FreeIPA project to confirm whether any configuration change is needed beyond the package update, and do not assume the patch alone closes a misconfigured ACI on your side.

The 4.13 branch also carries more moving parts than earlier stabilization work. Release 4.13.0 introduced a beta web UI, DNS over TLS between clients and IdM DNS servers, LDAP system accounts and random certificate serial numbers by default. Each of these changes behavior after an update. Before you roll 4.13.4 across the topology, check that DNS clients still resolve correctly over the new transport, that the LDAP system accounts your applications use still bind as expected, and that any tooling that parses certificate serial numbers handles random values. Test these on a non-production replica first.

Update order for FreeIPA security releases by server role

The first server handles certificate renewal and CRL publication by default, according to the FreeIPA backup and restore documentation, so it needs the most planning. Confirm which host holds this role before you start, since it may be an older machine that was installed first and is easy to overlook.

Take a verified backup first: Run a full backup with ipa-backup and copy it off the server. The documentation warns that restoring an outdated backup into an active topology can break replication, so label every backup with its date.
Record certificate and CRL state: Note the certificate tracking status and the time of the last CRL publication so you can confirm both continue after the update.
Plan around certificate expiry: Schedule the update so that no certificate renewal is due during the window in which renewal may be briefly paused.
Confirm replication before moving on: Check that every replication agreement reports success before you touch any other server.
Hold the rest of the topology: Do not update other servers until this host is confirmed healthy.

Before the update, check replication status and the backup timestamp on this host. After it, confirm that certificate renewal and CRL publication run as they did before.

Enrolled Linux hosts run SSSD to cache identity data and authenticate users against FreeIPA servers. They hold no directory data themselves, so their update is usually about keeping logins working during the server rollout. Read the 4.13.4 release notes to confirm whether any client-side packages change for your version.

Update clients after the server tier: Wait until the servers are confirmed healthy so that clients only talk to servers in a known state.
Update in batches: Group clients so that part of each group keeps a working login path during its window.
Record a test login before the change: Capture a Kerberos ticket issuance and an SSH login for a test account.
Verify identity lookups after: Compare id and getent output for a test user against the values recorded before the change.
Review offline login settings: Cached credentials may allow sign-in when servers are unreachable, so confirm how your SSSD configuration handles that case.

Before the batch starts, confirm that the test login and identity lookups work. After it finishes, repeat both checks on a sample of updated hosts.

Applying a FreeIPA security release one replica at a time

This sequence moves a FreeIPA topology to a security release without breaking replication, by confirming versions, keeping a restorable backup off the servers, rehearsing the update and checking each server before the next one changes.

Confirm the installed version on every server
Someone on the platform team logs in to each IPA server and client-facing replica and records the installed FreeIPA server package version, the operating system release and the output of the topology check. Compare the results with the release notes for the fix you are applying, including the 4.13.4 notes for the two CVEs it addresses. Mixed versions across servers are a finding in their own right, so note any server that is already behind or ahead of the rest. The step is done when you have a written inventory with one row per server and no unknown versions.
Take a full backup and store it off the servers
Run a full ipa-backup on a server that holds the current data, then copy the archive to storage outside every IPA server, such as a backup host or vault you control. Record the backup file name, its checksum and the time it was taken. Label the backup with the topology it came from, because a backup taken from one state of the topology cannot safely be restored into a topology that has changed. Warning: restoring an outdated backup into an active replica topology can break replication, so do not treat this archive as a rollback for individual servers unless your recovery plan says so. The step is done when the copy opens and its checksum matches the record.
Rehearse the update in a non-production copy
Build a separate test topology with the same FreeIPA version, operating system, replica count and replication agreements as production, then restore a recent backup into it. Apply the security release there in the same order you plan for production and run the checks from the later steps. Note any failed package transaction, service that does not start, certificate or DNS warning and any manual action the release required. The rehearsal is complete when the test topology reaches the target version with replication healthy and you have a written list of the issues found, if any, and how each was resolved.
Update one non-critical replica first
Choose a replica that does not run the Dogtag certificate authority or DNS, if your design has one, and that is not the server clients depend on most. Apply the update package on that server only, following the release instructions, and restart the services the update touches. Keep the other servers untouched until the checks in the next step pass. The step is done when the server reports the target version and the update log shows no errors.
Check replication, Dogtag and DNS after each server
Run ipa-replica-manage list and ipa-replica-manage list-ruv from the updated server and confirm every agreement reports a healthy state. Check the Dogtag service with ipa cert-find or the CA status command, and confirm DNS answers with a lookup of an IPA host record against that server. On a client, obtain a test Kerberos ticket with kinit for a test account, then run ldapsearch with a test bind to confirm LDAP authentication. Do not move on until every check passes on the updated server. Record the output with the time and the server name.
Repeat the update and checks on each remaining server
Update the remaining replicas one at a time, using the same order and the same checks as the first server. Start with replicas that hold less critical roles and finish with the server that handles certificate renewal and CRL publication by default, unless your topology has been changed to move those duties. Wait for replication to settle between servers, then run the replication and service checks again from the newly updated server. Stop the rollout if a check fails, and investigate before updating anything else. The step is done when every server in the inventory reports the target version.
Verify the fix and record the results
Confirm the fixed behavior on the production topology, for example by checking that the server reports the target version and that the release notes' verification guidance passes for the fixed areas. Run a test Kerberos ticket and a test LDAP bind from a client in each site, and confirm that an unauthenticated LDAP query no longer returns the credential data described in the release notes. Update the inventory with final versions, check outputs, the backup reference and any open issues. Keep this record with your change log so auditors and the next operator can see what changed and when.

How to verify FreeIPA security fixes after rollout

A fix is confirmed by the running server, not by the package manager. Start by checking the installed versions on every replica, not only the first server. Run rpm -q freeipa-server 389-ds-base and ipa --version on each host and compare the output with the 4.13.4 version recorded in the release notes. Replicas that were skipped, rolled back or restored from an older backup often report a version that differs from their peers, and a mixed topology is the first thing to rule out. Also confirm that the 389 Directory Server build on each replica is the one the upgrade installed, since the LDAP access control changes sit in that component as well as in FreeIPA itself.

Next, test the behavior the release notes describe. The 4.13.4 notes list LDAP access control flaws that could let unauthenticated clients obtain credentials, so run an anonymous ldapsearch against each replica from a host outside your trusted management network and confirm that sensitive attributes are not returned. Then test authentication through the API: run ipa ping and a kinit with a dedicated test account, followed by an authenticated ipa user-show, and confirm that unauthenticated or badly formed API requests are refused. Confirm the expected responses against the release notes and your own pre-upgrade baseline, not against memory, because the exact result depends on your configuration.

Finally, confirm that ordinary logins still work, because an over-tightened fix can break clients. On an enrolled Linux host, run kinit as the test user, check the ticket with klist, and review sssctl domain-status to confirm SSSD is online and talking to the expected server. Then confirm that id and getent passwd resolve the test user, and complete one SSH login that uses the ticket. Record each result per server with the date, the versions, the commands and the outputs, and keep that record with the change ticket. Store the checks as a script in version control so the team can rerun the same tests after the next stabilization release, and compare the results with the previous run.

Risks to manage while FreeIPA security patches are pending

Between a security release and the last patched server, the deployment carries several risks at once: exposure, exposed secrets, mixed versions, bad restores and gaps in evidence. Each card below names one of them and the control that keeps it contained while the patch is applied.

Unauthenticated LDAP exposure

The 4.13.4 fixes address LDAP access control flaws that could let unauthenticated clients obtain credentials. Until every server runs the fixed release, any host that can reach the LDAP port on an unpatched replica may be exposed. Restrict LDAP access at the network layer to known clients and monitor for anonymous or unexpected bind attempts on each server until the rollout is complete. Confirm the exact exposure with the release notes before deciding how urgent the rollout is.

Credentials exposed before the fix

A flaw that lets clients obtain credentials may have been exploited before the patch landed. Patching closes the path but does not show whether data was already taken. Review directory access logs and Kerberos authentication logs from the period before each server was updated, and list the service accounts, host keytabs and user passwords that could have been read. Plan rotation for any secret that was reachable, and record the decisions for your incident file.

Mixed versions across replicas

Replicas on different FreeIPA releases during a rolling update can behave differently in authentication checks and replication. Update one replica at a time, starting with a replica that is not holding the CA or DNS role where possible, and confirm replication is healthy before moving to the next. Keep a written order of servers and a record of the version on each one so the team can tell at any point which servers still need the fix.

Outdated backup restored into a live topology

If a recovery is needed during the patch window, restoring an older backup into an active replica topology can break replication, according to the backup documentation. Restore only into a planned recovery path, not as a shortcut to undo a failed update. Before any restore, confirm which backup is the newest good copy, and check that the first server, which handles certificate renewal and CRL publication by default, is not left with stale state.

Unreviewed changes in the 4.13 branch

Stabilization releases carry fixes, but each one also changes code the team may not have reviewed. Read the release notes for every 4.13.x version between your current release and the target, and note any behavior changes that affect your authentication, certificate or DNS settings. Test the target version in a staging topology built like production before rollout, and record the test results with the change request.

Loss of patch evidence

Auditors and incident responders need to know when each server was patched and to which version. Without that record, the team cannot prove the exposure window closed or show which hosts were affected. Keep a dated change log per server with the package version before and after, the date of verification, and the name of the person who checked it. Store this with the audit logs for the directory so it can be produced during a review.

Questions about FreeIPA security release cost, effort and timing

What drives the effort of a FreeIPA security release?

The effort depends mostly on how many servers you run, how they are placed across sites, and how much checking you need before and after the update. A single test server with no certificate authority or DNS role is a small job. A production topology with several replicas per datacenter, integrated Dogtag CA and DNS, and client fleets that must keep authenticating is larger, because each server must be updated in a safe order and verified. Other drivers include the number of custom integrations (such as LDAP binds from applications), how current your test environment is, and whether a backup is taken and proven restorable before the change. Ask for the effort to be broken down by server role and by each verification step in the written scope.

Can our own team apply FreeIPA security updates without outside help?

Yes, many teams apply FreeIPA updates in-house, and the work is well suited to that when they have a tested runbook, a non-production replica topology and staff who understand replication. The risks are in the sequencing and the checks: updating replicas in the wrong order, restoring an outdated backup into an active topology, or assuming a fix is in place without testing it. Outside help is most useful when the team lacks replication or PKI experience, has no staging copy, or must show a documented change record to an auditor. DeployOpen can plan, implement and document the update in your infrastructure, so you can decide which steps stay with your staff.

What does the security release work need from our side?

Plan for four kinds of input before work starts. First, access: administrative access to the FreeIPA servers, the ability to run the update tooling, and read access to logs and monitoring. Second, change windows: agreed times when each server can be taken out of service, and a rollback decision for each. Third, backups: a current, tested backup taken with the supported backup tools, stored outside the servers being changed. Fourth, named owners: one person who approves changes, one who runs them, and one who checks client authentication afterward. Confirm these in writing, because a missing owner or window is the most common reason a planned update slips.

How is release tracking different from a support retainer?

Release tracking is a watch on upstream FreeIPA releases and security fixes, with a written assessment of which fixes apply to your deployment and which change window they need. It produces a recommendation and, if agreed, a scoped update. A retainer is an ongoing commitment that covers continued support, upgrades and testing over a period set in the contract. Tracking alone can be a smaller, recurring cost, while a retainer also includes response to incidents and regular work. Ask which of these is in scope, how often assessments are delivered, and what happens when a fix needs an out-of-cycle change. Retainers are available from DeployOpen, and the terms are set in the written agreement.

How does a single-server FreeIPA update differ from a multi-datacenter one?

A single server is updated once, with one outage window and one verification pass. A multi-datacenter topology adds replication order, version mix and client impact. Each replica must be updated in a sequence that keeps the topology consistent, and during the window some replicas run the old version while others run the new one. The team must check replication agreements, certificate authority and DNS roles on specific servers, and client authentication from each site. The FreeIPA deployment recommendations describe the replica layout that these steps assume, so confirm your layout against them before scoping. Expect the verification and rollback planning to grow with every additional site.

How do we ask for a quote for a FreeIPA security release?

Send a written scope request that includes the FreeIPA version you run, the target release, a server inventory with roles (replica, CA, DNS, NTP), the number of sites, and the client platforms that authenticate against the deployment. Add the integrations that depend on LDAP or Kerberos, your backup method and the change windows you can offer. Ask the provider to state deliverables, verification steps, what is included in the fixed scope, what is excluded, and how post-release checks are reported. DeployOpen does not publish a price list. A quote follows from the written scope, so the more complete the request, the more precise the quote.

Does the cost of an update change if we only apply stabilization releases?

The work depends on the change, not the label. A stabilization release such as 4.13.4, which fixed two CVEs and hardened authentication checks according to its release notes, still needs the same planning, backup, ordered update and verification as any other change, because it touches the running identity service. Smaller version changes can need less investigation, but the verification of authentication and certificate behavior is the same. Ask the provider whether the quote assumes a single target release, whether it covers catch-up across several releases, and whether it includes reviewing the release notes for your specific roles and integrations.

What to confirm about FreeIPA security releases in your environment

Each item below is a question to answer for your own servers before you plan the update. The 4.13.4 release notes are the starting point, but your distribution packages, replica versions and client behavior decide what the rollout looks like.

Exact CVEs and affected versions

Start with the CVE identifiers and affected version ranges listed in the 4.13.4 release notes, and record which of them apply to the versions you run. The release notes describe LDAP access control flaws that could let unauthenticated clients obtain credentials, so confirm the exposure on each server role, not only on the first server. Keep the list as the baseline for your verification after rollout.

Packages on your distribution

FreeIPA is packaged by each Linux distribution, so the fixed build may arrive through a different package name, version string or repository than upstream. Ask your vendor or distribution which package carries the 4.13.4 fixes, when it became available in your channel, and whether it is backported. Do not assume an upstream version number means the fix is present.

Replicas that predate the fix

Check the FreeIPA version on every replica, including ones that rarely serve clients or sit in a secondary datacenter. A replica still on an older build can remain exposed even after the first server is patched. List the version of each server with its role, such as CA or DNS, so you can plan the update order.

Dependence on changed LDAP behavior

Security fixes to LDAP access control and authentication checks can change what an application or script receives. Inventory applications that bind over LDAP, service accounts, and any integration that reads attributes directly. Test those paths in a staging topology before the production update, and record any client that fails after the change.

Vendor support window

Confirm how long your operating system vendor or distribution maintains the FreeIPA packages you run, because a stabilization release may not be backported to older branches. If your platform reaches end of support before a planned upgrade, the security update path may differ from upstream. Ask the vendor in writing which versions will receive fixes.

Change-control rules for identity servers

Identity servers often fall under change windows, approval steps and emergency patch procedures that differ from general server policy. Confirm who approves an emergency security update, how a failed replica is rolled back, and whether your backup and restore process has been tested against the new version. These rules decide how quickly the fix reaches production.

How DeployOpen runs FreeIPA security release work

DeployOpen plans, implements and documents FreeIPA security release work inside your own infrastructure, from the first scoping call to the verified rollout. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before any change is made to your servers.

How we scope

Inventory every FreeIPA server, replica, client and integration with the installed release version
Map which fixes in the current stabilization release apply to your topology and enabled features
Agree in writing which servers are in scope, the change windows and the verification evidence you will receive

How we build

Take and test a full ipa-backup before any package changes on a production server
Write an update order for replicas and the first server, with rollback steps for each stage
Run checks on a non-production copy of your topology before the production rollout starts

How we hand over

Deliver a runbook listing each server, the version before and after, and the commands used
Record post-update checks for replication status, certificate services and authentication behavior
Document the procedure for future stabilization releases so your team can repeat it

How we support

Offer ongoing security release tracking and rollout work as a retainer, scoped in writing
Re-verify fixes after later updates or topology changes that touch the affected services
Confirm with the FreeIPA project and your own vendor channels which releases apply to your deployment

Keeping up with FreeIPA security releases