How to plan a FreeIPA 4.12 to 4.13 upgrade without breaking replication
To move a replicated FreeIPA topology from 4.12 to 4.13 without interrupting logins, upgrade one server at a time, in a planned order, inside a maintenance window for each server, and check replication and authentication before moving to the next. The supported approach is an in-topology upgrade, not a rebuild, and the target should be the latest 4.13 maintenance release, which is 4.13.4 at the time of writing. Confirm that version against the FreeIPA 4.13.4 release notes before you set the target, because maintenance releases change, and the notes list the CVE fixes that justify moving to the newest build.
Plan for changed defaults before you start. The FreeIPA 4.13.0 release notes say the compat tree and NIS configuration are disabled by default when deploying FreeIPA, so any client or application that still depends on the compat tree or NIS lookups must be identified in advance. Random certificate serial numbers are now the default, which changes what your CA-related scripts, audit queries and certificate inventories will see for newly issued certificates. The modern Web UI is a beta that runs alongside the current Web UI, so administrators keep their existing workflow unless they opt into the new interface. Review each of these changes against your own configuration files and automation, not only the release notes.
Use the release notes and the topology inventory to set the order. Start with a replica that does not hold the certificate authority renewal or CRL publication role, record the current replication agreements, and confirm that every server reports healthy replication before touching packages. Take a full ipa-backup before the first change and confirm that you can restore it, since restoring an outdated backup into an active topology can break replication. Keep the number of servers changing at once low, and confirm the spacing between servers and the rollback plan with your platform team. Ask the FreeIPA project and your operating system vendor to confirm supported upgrade paths for your specific distribution.
What FreeIPA 4.13 changes for existing deployments
This table lists the 4.13 changes from the 4.13.0 release notes, plus the certificate pruning behavior and the 4.13.4 security fixes. For each change it shows the effect on a running 4.12 topology and the step your team should take before or during the upgrade. Read the impact column first, because most rows affect only new installs, new replicas or features you choose to enable.
| Change | Impact on an existing 4.12 deployment | Action for your team |
|---|---|---|
| Modern Web UI (beta) | Ships as a beta that runs alongside the current Web UI, so existing administration screens stay in place. | Treat it as a lab feature. Do not use it for production administration until you have tested it in a non-production topology. |
| DNS over TLS between clients and IdM DNS servers | A new option for encrypting DNS queries from clients to IdM DNS servers. Nothing changes until you configure it. | Decide whether you need it. Confirm the certificate, client and resolver requirements in the 4.13.0 release notes before planning it. |
| LDAP system accounts | Adds a way to create system accounts in the directory for services that bind to LDAP. | Inventory existing bind accounts and service credentials. Decide whether any of them should move to the new account type, and test each change separately. |
| ipa-idrange-fix tool | A repair tool for ID range problems. It is relevant only if your deployment already has ID range issues. | Check your ID ranges first. Take a full backup and read the tool's documentation before running any repair. |
| Random certificate serial numbers by default | Newly issued certificates get random serial numbers instead of sequential ones. | Check scripts, audit reports and monitoring that assume sequential serials, and update any that do. |
| Compat tree and NIS disabled by default | Applies to new deployments. Confirm in the release notes whether upgraded servers keep their current compat and NIS settings. | If any Linux or legacy client relies on the compat tree or NIS, enable it deliberately and test those clients before upgrading production. |
| Expired certificate pruning on new replicas | Confirm the exact behavior in the 4.13.0 release notes before planning. The effect depends on how expired certificates exist in your topology. | Before adding a new 4.13 replica, review the certificate inventory and document what the new replica will and will not carry over. |
| 4.13.4 security fixes | The 4.13.4 stabilization release, dated July 9, 2026, fixes two CVEs, including LDAP access control flaws and hardened authentication checks. | Target the latest 4.13 maintenance release rather than the first 4.13 build, and confirm the CVE list in the 4.13.4 release notes against your risk review. |
What to back up and inventory before the FreeIPA 4.13 upgrade
Nothing in a FreeIPA 4.13 upgrade should start until the topology is captured and recoverable. The cards below cover the backup, the role inventory, the customizations and legacy dependencies, a rehearsal environment, and the window and communication plan that tie the work together.
Take a full backup off-server
Run ipa-backup on a server you can rely on, then copy the archive off the FreeIPA servers to storage you control. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so record the backup time and the server it came from. Confirm the archive can be read before any package changes start, and keep the backup from the same change window as the topology inventory.
Inventory CA and DNS roles
List which servers run the Dogtag CA, which run integrated DNS, and which hold the CA renewal and CRL publication roles. By default the first server handles certificate renewal and CRL publication, so note that role explicitly and confirm it still lands on a server you will upgrade last or move deliberately. Record every replica agreement so the replication order in the next section is based on the actual topology.
List custom rules and integrations
Export custom sudo rules, HBAC rules, trusts, ID views, and any automation such as Ansible playbooks or scripts that read or write FreeIPA objects. Mark which of these assume current default behavior. Each item becomes a test case in the rehearsal environment, because a rule that works today may change meaning after the release.
Check compat tree and NIS use
The 4.13.0 release notes say the compat tree and NIS configuration are disabled by default when deploying FreeIPA. Identify any client, application or legacy host that still reads the compat tree or depends on NIS maps, and decide whether that dependency is kept, moved, or retired. Confirm the choice with the release notes before changing any setting on existing servers.
Rehearse on a topology copy
Build a test topology that mirrors the production server count, operating system versions, replication agreements, DNS forwarders, and CA roles. Restore a recent backup into it, apply the same update order you plan for production, and run your client login, Kerberos, certificate, and integration tests. Treat the results as the basis for your rollback and recovery decisions, not as proof that production will behave the same way.
Set the window and notify owners
Agree the maintenance window with the teams that depend on authentication, including application owners, help desk, and security operations. Publish the server order, the expected checkpoints after each server, and who can approve a pause or rollback. Name one person who holds the backup location and the decision log so that recovery steps are not improvised during the change.
Upgrading a FreeIPA 4.13 replica topology one server at a time
This sequence moves a replicated FreeIPA topology to 4.13 one server at a time, so replication, authentication and the CA role stay available and every server has a checked state before the next one changes.
Confirm replication health across all servers
Before any package changes, check replication agreements between every pair of servers, confirm that each replica can reach the others, and confirm that the topology still matches your deployment records. Look for replication errors, stale agreements and servers that are already out of step with each other. Record the current package versions and the server that holds the CA renewal and CRL roles, since that server is handled last. Stop if any agreement is failing or any server is unreachable, and resolve it first. Done when every agreement reports healthy and you have a written upgrade order.
Take a backup and agree the maintenance period
Run a full backup with ipa-backup on the server you plan to upgrade first and store it outside the server. Confirm that the backup is recent enough to restore, since the backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Agree the maintenance period with the people who depend on authentication, DNS and certificates, and notify them when changes start and when they end. Stop if the backup cannot be read back from storage or no restore owner is named. Done when the backup is verified and the window is confirmed in writing.
Put the first replica into maintenance mode
Select a replica that holds no unique CA role, so the CA renewal and CRL publishing duties stay on a server you upgrade later. Enter maintenance mode for that server and confirm that clients will not be routed to it during the update, using your DNS and load arrangements. Record the rollback point: the backup from the previous step and the package versions noted earlier. Stop if the selected server holds a unique CA role or if clients still resolve it as a primary. Done when the server is out of service for clients and the rollback point is written down.
Update packages on the first replica
Apply the FreeIPA 4.13 package updates on the selected replica using your distribution's package process, following the project's upgrade guidance for that release. Watch the output for errors from the directory server, Kerberos and the CA components, and do not reboot or restart services outside the documented steps. Confirm the new package versions on the server. Stop on any failed scriptlet or service that will not start, and keep the server out of service until the cause is known. Done when the packages report 4.13 and the server's services start cleanly.
Run post-upgrade checks on the first replica
Check replication status from this server to every other server, then test a Kerberos login with a known user, confirm that DNS names resolve through this replica, and inspect certificate status for the services it serves. Test client authentication from one enrolled Linux host that uses this replica. Use the results to decide whether the server returns to service. Stop and roll back if replication errors appear, a Kerberos login fails, DNS answers are wrong or certificate status shows failures that were not present before. Done when every check passes and the server is back in service.
Pause and confirm before the next replica
Leave the upgraded server in service for an observation period your team sets, and watch replication, authentication failures and log entries during that time. Do not start the next server while the previous one is still being checked. Record the state of the topology at this point, including which servers are on 4.13 and which are still on the previous release, because mixed versions are the normal condition during a rolling upgrade. Stop if any check regresses. Done when the team signs off the state of the topology in writing.
Repeat the sequence for each remaining replica
Work through the remaining replicas that do not hold the CA renewal or CRL role, one at a time, repeating the backup, maintenance, update and check steps each time. Keep each server's rollback point recorded, and confirm replication after every server. Do not upgrade two servers in the same window unless your own testing has shown that to be safe. Stop if replication or authentication fails on any server, and hold the rest of the topology in its current state. Done when every non-CA replica runs 4.13 and passes its checks.
Upgrade the CA renewal server last
Move the CA renewal and CRL publishing role to an upgraded replica at a planned point in the order, then upgrade the former CA renewal server using the same steps. Confirm which server now holds the role before changing anything on the old one, and check certificate status and CRL publication after the role moves. Keep the backup from before the role change available as the rollback point. Downgrades are not supported in this sequence, so the recovery path for a failed server is restore and rebuild, which should be confirmed against the project documentation for your release. Done when the CA role is on an upgraded server, certificate status is healthy and the whole topology reports 4.13.
Choosing a rollout approach for single-site and multi-site topologies
A single datacenter with two or three replicas usually allows the whole topology to be sequenced in one maintenance window. The team controls every server, can see the full replication picture and can run tight checks between steps. The trade-off is concentrated risk: a problem found on the second or third server affects the whole topology until it is resolved, and there is no other site to absorb client load.
- One window, one owner: One change owner runs the order, records the state after each server and decides whether to continue to the next host.
- Short replication path: With few replicas, the number of agreements to inspect after each step stays small, which keeps verification quick and easy to repeat.
- Restore is the fallback: Downgrades are not possible, so the recovery path is restoring from a backup taken before the window. That restore must be rehearsed beforehand, not assumed.
- Shared roles on shared hosts: If CA renewal, CRL publication or DNS run on the same server, the team must know which host holds each role before starting.
Confirm that the pre-change backup is recent and restorable, that the window leaves time to stop safely, and that no client-facing service depends on a single server during the change.
Multi-site topologies are shaped by the deployment recommendations: at least two to three replicas per datacenter, no more than four replication agreements per replica, and at least one replica per datacenter running PKI or DNS if those services are used. These limits mean the order must keep each site served while another site changes, and the work usually spans several windows. The trade-off is more time and coordination in exchange for lower exposure at each step.
- Per-site ordering: Update one replica, verify it, then move on, so every datacenter keeps at least one working replica for its clients.
- Role holders kept in place: Move CA renewal, CRL and DNS duties deliberately, because each datacenter should keep a PKI or DNS replica available throughout the rollout.
- Agreement budget: Check the agreement count on each replica against the four-per-replica limit before adding any temporary path, since the limit applies to every connection.
- Wide-area timing: Schedule windows around inter-site links and remote on-call coverage, and confirm how clients fail over to replicas in other sites during each step.
- Client resolver settings: Confirm that each client lists at least two DNS servers in
resolv.conf, so an outage in one site does not strand its clients.
Confirm the replica count and agreement map for every site against the recommendations, then record which site moves first and the checks that must pass before the next site starts.
Whichever approach fits, the choice depends on facts only the team can establish about its own deployment. The 4.13.0 release notes describe several defaults that affect existing estates: random certificate serial numbers are used by default, the compat tree and NIS configuration are disabled by default for new deployments, and the modern Web UI is a beta that runs alongside the current one. Each of these should be checked against the team's own configuration before the window is scheduled.
- Topology inventory: List every server, its site, its installed roles (CA, DNS, NTP) and its replication agreements, since these decide the order.
- Certificate and serial behavior: Confirm how existing certificates and serial numbers are handled by any tooling or downstream process that expects a particular pattern.
- Compat tree and NIS dependencies: Identify any legacy client or application that depends on the compat tree or NIS, because those features are disabled by default in new deployments.
- Beta UI exposure: Decide whether the beta web interface is offered to administrators at all, and keep the current interface as the supported path during the rollout.
- Backup and rehearsal: Confirm that a backup can be restored into a test copy of the topology before any production server is changed.
Confirm each item in writing with the team that owns the topology, and treat any answer you cannot verify as a blocker for the first window.
Testing the FreeIPA 4.13 upgrade and what rollback can and cannot undo
A rehearsal on a copy of the topology is the main protection you have before a 4.13 upgrade reaches production. Build a test environment that mirrors your replica count, server roles, CA and DNS placement, and the client mix, then upgrade it in the same order you plan to use in production. Test the things your users and services depend on most: Kerberos logins from SSSD clients and from applications using GSSAPI, host enrollment and re-enrollment, sudo and HBAC decisions for representative users, certificate issuance and renewal through the Dogtag CA on the server that holds the CA renewal role, and DNS resolution including DNS over TLS for clients, which the 4.13.0 release notes list as a new capability. Also test every integration you run, such as Active Directory trusts, OTP or RADIUS proxying, Samba file servers, and automation that calls the IPA API, because these often break in ways basic login tests will not show.
Treat rollback as restoring service from a verified backup, not as reverting packages on one server. Once a replica has run the new packages, downgrading that host alone is not a dependable path, and the FreeIPA backup documentation warns that restoring an outdated backup into an active topology can break replication. Before the window, confirm with the project documentation exactly which backup type, restore steps and replica rebuild steps apply to your version and topology, and rehearse them on the test copy. Record what the rollback will not undo: changes made to users, policies or certificates after the backup, certificates issued in the interim, and any client state that changed during the window. Ask your team to agree in writing who decides to roll back, and at what point in the sequence that decision is still safe to make.
Write down the test results and the rollback criteria before the production window opens, so the go or no-go call is not made under pressure. Each test should have an owner, an expected result and a pass condition, and failed tests should block the next server in the order. Keep a fresh, verified backup of the first server to be upgraded and confirm it can be read before you start. If any test environment result differs from production behavior, stop and investigate before continuing, because the rehearsal is only useful if it matches the systems your users actually touch.
What makes a FreeIPA 4.13 upgrade take longer
This table lists the factors that stretch a FreeIPA 4.13 upgrade and explains why each one adds work. Read each row against your own topology, then use the last column to build the scope you put in a quote. The main takeaway is that most of the extra time comes from what your deployment depends on around FreeIPA, not from the package update itself.
| Driver | Why it adds work | What to ask for in a quote |
|---|---|---|
| Replica count and geography | Each server needs its own update, maintenance mode, and checks, and replicas in separate sites add travel, change windows and coordination with local teams. | A per-server sequence with the order of replicas, the checks after each one, and who performs them at each site. |
| Number of CA and DNS roles | Servers that run Dogtag or integrated DNS need extra verification of certificate renewal, CRL publication and DNS answers before and after the change. | Explicit checks for the CA renewal and CRL server, and for DNS resolution from representative clients. |
| Custom sudo and HBAC rules | Rules written for your environment must be reviewed for behavior changes and retested for representative users and hosts. | A review of existing rules and a test list covering the access paths your teams rely on. |
| Legacy compat tree or NIS dependencies | The compat tree and NIS configuration are disabled by default in 4.13, so any system still reading through them needs a dependency check and possibly a deliberate change. | An inventory of clients or services that use compat or NIS lookups, and a decision record for each. |
| Trusts with Active Directory | Trust configuration and ID mapping must keep working after each server updates, which means testing cross-forest logins on more than one replica. | Trust validation steps and the AD-side test accounts used to confirm login and group resolution. |
| Integrations with Keycloak, Samba or Ansible | Each connected system has its own configuration and test path, and an upgrade can change behavior those systems rely on. | A list of each integration, its owner, and the regression test that proves it still works. |
| Size of the directory data | Larger directories take longer to back up, verify and replicate, and a restore from backup must be rehearsed before production work starts. | A backup step, an estimate of backup and verification time for your data, and a tested restore plan. |
| Enrolled clients to verify | Sample checks on each client type can be small, but a wide mix of operating systems and SSSD configurations widens the verification set. | The number and types of clients in the test set and the criteria that count as a pass. |
| Change window constraints | Maintenance windows limit how many servers can change in one session, which can stretch the calendar across several weeks. | The approved windows, the number of servers per window, and the rollback decision point for each. |
| State of the test environment | A test topology that does not match production, or that lacks current data, hides problems until the live change. | Confirmation of how closely the test setup matches production, and the plan to refresh it before the upgrade. |
How much effort does a FreeIPA 4.13 upgrade need from our team?
How is the cost of a FreeIPA 4.13 upgrade structured?
The cost is mostly labor, split between assessment, the upgrade work itself, testing and handover. FreeIPA is community software under GPL-3.0-or-later with no paid edition, so there is no license fee to budget for the server software. Your own staff time is a cost too, and it often runs longer than the partner's time because your team must schedule windows, approve changes and test applications. Most engagements are fixed-scope, so the written scope defines the price. One-time costs cover the assessment, the upgrade and any remediation of problems found. Recurring costs appear only if you buy ongoing support, upgrades or testing as a retainer. Ask any quote to separate these, and to show who performs each task.
How long does a replicated FreeIPA 4.13 upgrade take?
The duration depends on your topology, and a written scope sets the actual timeline. The number of servers, the number of sites, how many replicas run the Dogtag CA or DNS, and how many applications depend on authentication all change the work. Each server needs its own update, a maintenance window and checks before the next server starts, so the schedule grows with the server count. Your change approval process and the availability of application owners for testing often take longer than the technical steps. Ask for a timeline that lists each server, each window and each checkpoint, with dates agreed by both sides.
What does the upgrade need from our own staff?
Your staff must provide access, change windows and application owners. The team needs administrative access to every IdM server, the ability to run commands on each host, and read access to monitoring for replication and certificate status. Change windows must be approved in advance for each server, because each one is taken into maintenance mode. Application owners must test login, Kerberos ticket use, sudo and host access rules, and any service that relies on FreeIPA certificates after each step. Name a technical owner who can make decisions during the window, and a business owner who can accept or reject the result.
Can our own team perform the FreeIPA 4.13 upgrade without a partner?
Yes, if your team has the skills to run it safely. You need experience with FreeIPA replication, the ability to check replication status and certificate state after each server, and a tested way to restore from backup. The vendor backup guidance warns that restoring an outdated backup into an active replica topology can break replication, so your team must know how to take a current backup and how to avoid restoring stale data. Confirm the release notes for your exact starting version before you begin. If those skills are not in-house, a fixed-scope partner engagement can cover the assessment, the upgrade, checks and handover so your team learns the procedure.
Can we roll back a FreeIPA 4.13 upgrade after it is applied?
You should plan for the upgrade to be one-way, so rollback means restoring from backup rather than reverting packages. The sibling guidance on updating FreeIPA servers states that downgrades are not possible, which makes a verified backup taken before the first server is changed essential. Restoring a backup in a live topology is a separate operation that can disrupt replication if it is done carelessly. Ask your partner or your team to document the restore steps, test them on a non-production copy, and define the conditions under which the team would stop and restore.
Do we have to use the beta modern Web UI in FreeIPA 4.13?
No. The FreeIPA 4.13.0 release notes describe the modern Web UI as a beta that runs alongside the current Web UI, so the upgrade does not require your administrators or users to switch. Your team should decide whether to pilot the beta with a small group of administrators while keeping the existing interface for production work. Treat any beta feature as something to test, not something to rely on for change control or audit evidence. Confirm the beta's status for your environment before you plan training, and keep the current interface documented as the fallback.
What should we ask for in a written quote for the upgrade?
Ask for a scope that lists every server, the starting and target versions, and the checks performed after each server. Request a list of deliverables, including the pre-upgrade assessment, the change plan, the rollback and restore steps, the test scripts or checklists, and the handover documentation. Ask who performs each task, what your staff must provide, and what is excluded, such as application remediation or work on clients. Request the timeline with dates agreed by both sides, the acceptance criteria, and how changes to scope are priced. Also ask whether ongoing support or testing is a separate retainer.
Which compliance evidence should the upgrade produce for auditors?
The upgrade should produce records that show what changed, when, and what checks passed. Keep the change tickets, the maintenance window records, the pre- and post-upgrade replication and certificate status, the backup records, and the test results from application owners. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications. Independent auditors and certification bodies make those determinations. Ask your assessor early which evidence they expect, so the upgrade records match your control framework.
How DeployOpen scopes, delivers and supports a FreeIPA upgrade
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a FreeIPA 4.12 to 4.13 upgrade, we start from your topology, agree the sequence of replica changes in writing, and check each server before the next one is touched.
How we scope
- We inventory every FreeIPA server, its role, its DNS and CA responsibilities, and its replication agreements before work starts.
- The written scope names which servers move to 4.13, the order and maintenance windows, and who approves each change.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing, and a quote follows from that scope.
How we build
- We rehearse the upgrade order in a non-production copy of your topology, including maintenance mode and rollback notes.
- We review the 4.13 release notes against your own configuration, covering compat tree, NIS, certificate serial and pruning behavior.
- We run replication, Kerberos, DNS and certificate checks after each server and record the results before continuing.
How we hand over
- You receive a runbook with the server order, pre-change backups, maintenance steps and the checks used after each server.
- Documentation records which new defaults apply to your deployment and which settings were kept, changed or left disabled.
- We walk your administrators through the checks so your team can repeat them for later FreeIPA updates.
How we support
- Post-upgrade monitoring of replication and certificate health is scoped in the written agreement if you want it.
- Ongoing support, upgrades and continuous testing are available as retainers for FreeIPA estates that change often.
- Questions about the beta modern Web UI or future 4.x releases are scoped as separate work, confirmed against the project documentation first.
