How to update FreeIPA servers without breaking replication
In a multi-master FreeIPA topology, every server is a writable replica, so an update is a rolling change to a live directory, Kerberos KDC and certificate authority. Update one server at a time, in maintenance mode, and verify each one before touching the next. The FreeIPA upgrade page describes an upgrade as a package update on each server, carried out with that server in maintenance mode. Servers can be upgraded one at a time, but the whole topology should move within days or weeks rather than months, so replicas do not spend a long stretch running mixed versions. Enrolled clients need updating only if you want to use new features.
The supported path is therefore a sequence of individual server updates, not a single cutover. Plan the order before the first change: start with a replica that holds no CA renewal or CRL role, and leave the server that handles certificate renewal and CRL publication for later, since the backup documentation notes that the first server takes on those duties by default. Red Hat's installation guide for Identity Management on RHEL 9 advises waiting at least 10 minutes after updating one server before updating another. Confirm that interval against the guide for your own release, and treat it as a minimum, not a target, because you still need the checks below to pass.
Downgrades are not a rollback option. Red Hat does not support downgrading Identity Management, so the recovery path for a failed update is to fix forward on that server or restore it from a backup taken before the change, with the replication caveats that restore carries. Before you start, confirm that you have a current full backup and that every server is healthy: replication agreements are in sync, the directory and KDC answer on each server, and certificate status is normal. After each server, check replication again, confirm the ipactl status services are running on that host, verify a Kerberos ticket and a client login, and confirm that the server still answers certificate requests before you move on.
What the recent FreeIPA 4.x releases change for existing deployments
This table lists the changes in FreeIPA 4.13.0 and the 4.13.4 security release that affect servers already in a replicated topology, with the check or plan each one needs. Read the rows before scheduling the first server update, because the 4.13.4 row sets the urgency for the whole sequence. For the full 4.12 to 4.13 upgrade steps, see the sibling upgrade topic.
| Change | Impact on an existing topology | Action needed |
|---|---|---|
| New web UI (first beta in 4.13.0) | Beta interface present on updated servers, but it is not a supported dependency for daily administration. | Keep administrators on the existing interface, and confirm with the project which UI features are stable before relying on the new one. |
| DNS over TLS between clients and IdM DNS servers | Changes how enrolled clients reach IdM DNS, which affects resolver configuration on clients and DNS-serving replicas. | Identify which replicas run DNS, confirm client resolver settings, and test name resolution on one client after the first server is updated. |
| LDAP system accounts | New service accounts appear in the directory on updated servers, which changes what directory objects administrators see during audits. | Record the new accounts in your access reviews, and confirm that no local process depends on a name that could conflict. |
| ipa-idrange-fix tool | Provides a repair path for ID range problems, but it changes data and should not be run casually in a live topology. | Check the current ID ranges on every server before the update, and run the tool only on the guidance of the release notes or a tested runbook. |
| Random certificate serial numbers by default | New certificates issued by updated CA servers use random serials, which affects tools that expect sequential numbering. | Review any internal process or monitoring that parses serial numbers, and confirm CA renewal and CRL publication on the server that holds those roles. |
| 4.13.4 stabilization release (dated July 9, 2026) | Fixes two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, and hardens authentication checks across the API. | Treat the update as a security priority, plan it ahead of routine maintenance, and confirm the exact fixed version your servers will receive. |
| Mixed-version period during rolling updates | Replicas on different versions run together until the last server is updated, so each server must be verified before the next one. | Keep the window short, use maintenance mode on each server, and complete the post-update checks before moving on. |
Why maintenance mode and replica spacing protect the topology
Maintenance mode is the state the FreeIPA upgrade page asks you to put a server in while its packages are updated, so the server is known to be changing and is handled as such during the work. Treat it as a planned, visible change rather than a background task. While one server is in this state, the other replicas keep serving directory, Kerberos and certificate requests, and enrolled clients keep working against whichever servers they can reach. Confirm with your own change notes which services on the server are affected (for example, whether it holds the CA renewal or CRL role, which the backup documentation says the first server handles by default) so you know whether the role must move before the update starts.
Red Hat's installation guide tells administrators to wait at least 10 minutes after updating one server before updating the next. The point of that gap is to let replication and the services on the updated server settle before the topology takes another change. If a second server is updated while the first is still re-synchronizing or restarting services, a fault that would have stayed on one host can spread into your troubleshooting and make it hard to tell which change caused it. Use the 10-minute minimum as a floor, not a target, and extend it when the first server shows replication lag, failed services or new log entries. Record the time each server returned to normal so the next step has a clear starting point.
The deployment recommendations advise at least two to three replicas in each datacenter, and that number is what makes this spacing workable. With two or three replicas per site, one server can be out of service while the remaining replicas handle authentication and directory traffic for that site. Before you start, confirm that every datacenter still has enough healthy replicas to cover its clients, and that the clients' resolv.conf files list at least two DNS servers so lookups keep working during each step. If a site has only one replica, the update plan should be changed before work begins, because no spacing interval fixes a topology with no spare capacity.
What to back up and inventory before the first server
Every update in a replicated topology depends on knowing what the servers hold and how they depend on each other. The cards below cover the backup, the server roles, the replication layout, the client DNS setup, a test environment and the restore risk that connect to the update order.
Current ipa-backup on hand
Take a fresh full backup with ipa-backup before touching any server, and confirm you know which backup type you ran. A full backup covers the whole configuration and data set, while an online data-only backup captures data without stopping services. Check that the backup file is readable and stored off the servers being updated, so a failed package change can be rolled back to a known state.
Role of the first server
The backup documentation states that the first server handles certificate renewal and CRL publication by default. Record which server that is, confirm where the CA renewal role sits, and plan its update with that role in mind. Ask whether another replica has been assigned these duties, because an update to the first server can interrupt them if they are not moved first.
Replication agreements per replica
List every replication agreement on each replica and compare the count with the recommendation of no more than four per replica. Replicas that exceed the limit or have unclear agreements make the update order harder to plan. Keep the inventory with the server names, sites and roles so each step of the update has a clear source and target.
DNS and PKI role coverage
Confirm that each datacenter has at least one replica running PKI or DNS where those services are used. Check that every enrolled client lists at least two DNS servers in its resolv.conf. If a client depends on a single DNS server, that server going into maintenance mode can break name resolution for the clients behind it during the update.
Test topology that mirrors production
Build a lab with the same number of servers, the same operating system release and the same roles as production, then run the planned update order there first. Confirm the lab matches production package versions before the test starts. The lab shows whether the spacing between servers and the checks after each server work in practice, and it gives your team a rehearsal before a live change.
Restore risk from outdated backups
Restoring an outdated backup into an active replica topology can break replication, so never use an older backup to roll back one server while the others keep running. Confirm who can authorize a restore, which backup is the restore point, and how the other replicas will be handled. Treat any restore as a topology-wide decision, not a single-server fix.
Updating each replica in order, with checks after each one
This sequence moves a replicated FreeIPA topology to a new release one server at a time, so that replication, authentication and DNS keep working at every point and a failed check leaves a known-good state to return to. Each step ends with a recorded result that decides whether the next server is touched.
Confirm backups and inventory the topology
The administrator confirms a current backup of the deployment exists and can be restored, then records every server, its role (CA renewal and CRL, DNS, NTP, or general replica), its operating system and package versions, and the replication agreements between them. FreeIPA's backup documentation warns that restoring an outdated backup into an active topology can break replication, so the backup must be recent and tested against the current state. The output is a written inventory and a backup record. If either is missing, the team stops here, and the rollback point is simply not having changed anything yet.
Confirm the topology is healthy before starting
Before any package changes, check that every replica can replicate with its partners, that Kerberos and LDAP answer on each server, that DNS answers where it is used, and that certificate status is normal on the CA servers. Record the results per server. Do not begin the update if a replica is already failing, because a failure during the update is then impossible to attribute. The output is a baseline record. If a server is unhealthy, the rollback point is the current state, and the team repairs that server first.
Update a lower-risk replica first
Choose a replica that holds no CA renewal or CRL role and that other servers can cover if it is slow to return. Leave the CA renewal and CRL server for a planned later point, since the backup documentation notes that the first server handles certificate renewal and CRL publication by default. The output is a named server and a written order for the rest of the topology. If the team cannot identify a suitable replica, it should stop and review the topology design with the release notes before continuing.
Enter maintenance mode and update packages
Place the chosen server into maintenance mode as the FreeIPA upgrade page describes, then update its packages and restart services where the release requires it. Confirm the exact commands and any restart order against the release notes for your version and the Red Hat IdM installation guide for your operating system. The output is an updated package set and a restarted server. The rollback point is the pre-update package state recorded in step one, and because Red Hat does not support downgrading Identity Management, a failed update is handled by restoring from backup or by repairing the server forward.
Run post-update checks on that server
Verify that the FreeIPA services are running on the updated server, that replication status with each other replica is healthy, that Kerberos and LDAP respond correctly, and that DNS answers for the zones it serves. On a CA server, also check certificate status and CRL publication. Compare every result against the baseline from step two. The output is a signed-off checklist for this server. If any check fails, leave maintenance mode in place, keep the rest of the topology untouched, and investigate before doing anything else.
Wait before moving to the next server
Red Hat's IdM installation guide advises waiting at least 10 minutes after updating one server before updating another. Use this interval to watch replication and authentication logs and to confirm that clients can still log in through the remaining replicas. The output is a quiet period with no new replication or authentication errors. If errors appear during the wait, the rollback point remains the updated server's pre-update state, and the next server is not started.
Repeat the sequence for each remaining replica
Work through the remaining replicas one at a time using the same cycle of maintenance mode, update, checks and wait, and leave the CA renewal and CRL server until the other replicas are current. Confirm the release notes for any server-specific steps, such as changes that apply only to CA servers. The output is a per-server record for every replica. Each completed server becomes the new known-good state for the next one.
Update the CA renewal server and close out
Update the CA renewal and CRL server at the planned point, after all other replicas are current, and run the full checks again including certificate status. Then compare the final topology against the inventory from step one and file the results with the release and date of each update. Confirm with the release notes and your OS guide whether any client updates are needed, since the upgrade page notes that enrolled clients need updating only to use new features. The output is a completed, documented topology.
Why a FreeIPA downgrade is not a rollback option
Red Hat does not support downgrading Identity Management, so a rollback plan cannot assume that a server already updated can be returned to its previous package set. Treat the update of each replica as a one-way step and plan the recovery options around that fact before the first server is touched. The Red Hat installation guide for RHEL 9 is the reference to confirm this position for your own release, and your support agreement should be checked for what Red Hat will help with if a server misbehaves after an update.
What the team can rely on instead starts with a verified backup taken before the change. Use ipa-backup and confirm the archive is readable and complete on a separate host before the rollout begins. Keep the topology in a state where un-updated replicas can keep serving clients while one server is down or under investigation. That means not updating the last servers that hold the CA renewal and CRL roles, or the only replicas in a site, until the earlier updates have run cleanly. Write down the decision rule before the window opens: for example, which failed check stops the rollout, who has authority to stop it, and what the team does with the server that failed. The threshold is yours to set, but it must exist before work begins.
Restore is a recovery decision with its own plan, not a rollback step. The FreeIPA backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so a restore after a failed update may mean rebuilding a server rather than reverting it. Decide in advance who may approve a restore, which backup is used, how the other replicas are checked against it, and how clients are kept on working servers during the work. Confirm these steps against the FreeIPA backup and restore page and your own runbook, since the exact sequence depends on your topology and roles.
What makes a replicated FreeIPA update take longer
This table compares the factors that stretch a replicated FreeIPA update, from topology shape to customizations and change controls. Read each row alongside the spacing and checks in the sequence section, since every driver adds either waiting time between servers or extra verification after each one. The main takeaway is that the number of servers matters less than the roles they hold and what depends on them.
| Driver | Why it adds effort | What to ask for in a quote |
|---|---|---|
| Replicas per datacenter and across sites | Each server needs its own update, its own wait before the next server, and its own post-update checks, so more servers lengthen the sequence. | Itemized list of every server, its site, and the order the partner plans to follow. |
| Replication agreements per replica | Heavily meshed replicas show more replication lag and more possible failures to inspect after each update, so checks take longer. | Current agreement map and the replication health checks the partner will run before and after each server. |
| CA renewal and CRL roles | The server holding these roles needs careful handling, and its role should be confirmed before any update begins, because the backup guidance says the first server handles renewal and CRL publication by default. | Confirmation of which server holds CA renewal and CRL publication, and the plan for checking certificate status after that server is updated. |
| DNS and PKI roles on replicas | Servers running DNS or PKI need extra checks for name resolution and certificate operations after the update, beyond directory health. | Named list of DNS and PKI servers and the tests planned for each one. |
| Keycloak, Samba or Ansible integrations | Customizations and integrations that depend on FreeIPA may need retesting after each server, and they may not be covered by the core update checks. | Inventory of integrations, who owns each one, and which tests the partner will run against them. |
| Size and age of directory and backups | Larger or older data sets need longer post-update verification, and a current, tested backup is needed before the first server changes. | Backup status, the most recent restore test, and the partner's approach to taking a backup before the update starts. |
| Existence of a test topology | A test copy lets the team rehearse order, spacing and checks, which reduces surprises on production replicas. | Whether a test topology is included, how closely it matches production, and who builds and tears it down. |
| Enrolled clients and new features | Clients do not need updating to keep working, but any client that must use new features needs its own change, which adds separate work. | Count of enrolled clients by OS, and whether client updates are in scope or a separate project. |
| Change windows and approvals | Each update step may need a window and sign-off, and waiting for approvals between servers can stretch the calendar more than the technical work. | The change calendar, approval steps, and whether the partner's plan must be approved per server. |
Questions teams ask before updating FreeIPA replicas
How long does updating a replicated FreeIPA topology take?
The total depends on how many servers you have, how much time you leave between them, and how many checks and approvals each step needs. Red Hat's IdM installation guide says to wait at least 10 minutes after updating one server before updating another, so that floor applies to every server in the sequence. The FreeIPA upgrade page says servers can be upgraded one at a time and that the full rollout typically fits within days or weeks rather than months. Your own calendar is usually the real constraint: change windows, sign-off from each owner, and the time needed to verify replication after every server. Ask for a written sequence with a named check at each step before you book the window.
What does a replicated FreeIPA update cost, and what is fixed versus ongoing?
DeployOpen does not publish a price list. A quote follows from a written scope, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. The main cost drivers are the number of replicas, the number of environments that need a lab rehearsal, how many dependent systems must be checked after each server, and whether backups and inventory already exist. One-time work covers the assessment, rehearsal, the rollout and the handover notes. Ongoing support, upgrades and continuous testing are separate retainers. When you request a quote, ask which items are included in the fixed scope and which are optional.
Can an internal team update FreeIPA replicas without outside help?
Yes, if the team has the skills, a lab that matches production, verified backups and a written rollback decision rule. Most of the risk comes from skipping steps rather than from the package update itself, so the team needs to follow the same order, spacing and checks every time. Before starting, confirm that someone can restore a backup in the lab, that every replica is healthy, and that the team knows who may stop the rollout. An outside partner is useful when the team lacks FreeIPA replication experience, has no lab, or cannot staff the checks across several time zones. Ask a partner to show the runbook they would hand over.
What does the client need to provide for a replicated FreeIPA update?
The client provides access windows, a current inventory of every IdM server and its role, verified backups and named owners who can approve each step. Access windows must cover the time between servers, not only the first update. The inventory should list which replica runs certificate renewal and CRL publication, since the backup documentation notes that the first server handles these by default. Owners for DNS, identity, and any integrated systems should be available to confirm checks after each server. Also provide a lab or staging copy of the topology if one exists, plus the change approval process your organization requires.
Do all FreeIPA clients need to be updated at the same time as the servers?
No. According to the FreeIPA upgrade page, enrolled clients need updating only to use new features, so the server rollout does not require a matching client change. Plan client updates as a separate project that follows your own release schedule and testing. Check the release notes for the version you are moving to before deciding which client changes matter for your users. Keeping clients on their current version while servers move forward is a valid state, but record it so that support teams know which features are unavailable on each client.
Can a FreeIPA server be downgraded after an update?
No. Red Hat does not support downgrading Identity Management, according to its IdM installation guide. Treat each package update as a one-way step, and make the rollback plan a restore from verified backup rather than a package downgrade. The FreeIPA backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so restore decisions must account for the state of every other server. Test the restore procedure in a lab before the production window, and agree in advance who decides to restore and under what conditions.
When should a FreeIPA replica rollout be stopped?
Stop the rollout when a check after a server fails and the cause is not understood, or when replication, authentication or DNS behave differently from the baseline you recorded before the window. Other stop signals include a certificate or CRL process that does not respond as expected on the server that owns those roles, and client logins failing at a rate your support team cannot explain. Write these conditions down before the window, with the named owner who makes the call. Stopping early leaves a mixed-version topology for a period, so the plan should say how long that state is acceptable and what must be fixed before the next server is updated.
What checks should run after each FreeIPA server is updated?
Run the same set of checks after every server, and record the results before moving on. At minimum, confirm that replication agreements show no errors, that authentication against the updated server succeeds for test users, that Kerberos ticket requests succeed, and that DNS resolves the zones you serve. Confirm that certificate services respond on the server that holds those roles, and that the server's services are running without errors in its logs. Compare results against a baseline captured before the first update. Keep the check list in version control so that every window uses the same steps.
How DeployOpen scopes and delivers a FreeIPA replica update
DeployOpen plans and carries out FreeIPA replica updates as fixed-scope work on servers you control. The written scope fixes the server order, the maintenance window, the checks after each server and the handover documents before any package is changed.
How we scope
- Inventory every IdM server, its role (CA renewal, DNS, NTP) and its datacenter before proposing an update order
- Confirm current package versions, the target release and whether enrolled clients need updates for new features
- Agree in writing the maintenance window, rollback limits (downgrades are not supported) and who approves each server step
How we build
- Prepare a runbook that sets the spacing between servers, with a minimum wait of 10 minutes after each update per Red Hat guidance
- Take and verify a full backup of each server with ipa-backup before maintenance mode is entered
- Run replication and service health checks on each server before moving to the next, and stop if any check fails
How we hand over
- Deliver the runbook as it was executed, with the server order, timestamps, check results and any deviations recorded
- Document the maintenance mode steps, the post-update checklist and the commands used to confirm replication status
- Walk your operations team through the checks so they can repeat them on later updates without DeployOpen present
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the update is complete
- Review new FreeIPA release notes against your topology and flag changes that affect existing deployments
- Confirm with your own team which client updates are needed, since clients need updating only to use new features
