Why decommissioning a FreeIPA server starts with roles, not uninstall
The safe path to retiring a FreeIPA server is to confirm which roles it holds, move those roles to other servers, and only then remove it from the topology. Running ipa server-del or uninstalling the host first is the step that causes outages, because FreeIPA is a multi-master system and the server is one node in a replication graph that other servers depend on. Teams usually need this work when a site closes, hardware is replaced or several small sites are consolidated into fewer data centers. The replica and CA renewal topics on this page cover how roles are assigned and moved in general, so use them as background before you start.
Start by inventorying what the server does. Check whether it runs the integrated CA, DNS, the KRA, or any combination, and confirm which server holds the CA renewal and CRL publication role. FreeIPA's backup documentation notes that the first server handles certificate renewal and CRL publication by default, so a server that was installed first is the most likely holder unless the role was moved. Also check its replication agreements, since removing a node can split the graph if other servers only reach each other through it. Record the DNS zones it serves, the DNS locations and SRV records clients may rely on, and any trust or migration duties tied to it. Confirm each finding with the current server list in your own environment rather than relying on the original install plan.
Two checks are easy to skip and expensive to miss: DNA ID ranges and HSM-backed keys. Each replica holds a range of user and group IDs that it allocates from, so confirm the range is either still covered by another server or deliberately retired before the server leaves. For HSM-backed CAs, confirm where the key material lives and who controls that hardware before removing the host, because uninstalling the server does not automatically move keys. Ask your team or partner to write down each role move, the verification step that proves it, and the rollback plan, then sign off on that list before any removal command runs.
Which roles to confirm on the server before you remove it
A FreeIPA server often carries more than its own host entry. Before you remove it, confirm which services, certificate duties and ID allocations it holds, and where each one lives in the remaining topology. Each card below covers one role and the check to run against your own version.
DNS service placement
If the server runs the integrated DNS service, clients that query it lose answers for the zones it served. Confirm that at least one other IdM server in each site answers authoritative queries for every zone, and that clients' resolver lists still point at servers that remain. Check the DNS service list on each remaining server, then query the zones from a client in each site. Confirm the exact commands against your FreeIPA version.
CA service placement
The Dogtag certificate authority issues and signs certificates for hosts, services and users. If the removed server is the only CA replica, certificate requests stop until a replacement is in place. Confirm that a remaining server runs the CA role in each site that needs issuance, and that the CA signing chain is replicated there. Check the role list on each server before you remove the original.
KRA service placement
The Key Recovery Authority holds archived encryption keys for users and services that opted into key archival. If the removed server holds the only KRA instance, key recovery requests fail, and archived keys become hard to reach. Confirm that a remaining server runs KRA, and that the transport and storage keys are available there. Treat a missing KRA as a recovery risk that needs a plan before removal, not after.
Certificate renewal master
One server acts as the renewal master for shared CA certificates, and by default this is the first server installed. If it disappears without a replacement, renewals for shared certificates stop, and certificates eventually expire across the topology. Confirm which server holds the renewal master role, then move it to a remaining CA server before you remove the old one. Check the backup documentation for how the default role is set on your version.
CRL publisher role
The CRL publisher generates and publishes the certificate revocation lists that clients and services use to reject revoked certificates. Without a publisher, revocation checks fall out of date, and revoked certificates may still be accepted. Confirm which server publishes CRLs, move that role to a remaining CA server, and verify that clients can still fetch the list from a surviving location. Repeat the check after the move.
ID range ownership
Each server holds a slice of the ID range that assigns UIDs and GIDs to new users and groups. If the removed server owns a range that no other server has allocated from, the remaining servers can run out of IDs or create conflicts later. Confirm which ranges the server owns and that other servers have unallocated IDs in the same range before you remove it. Check the ID range tools documentation for your version to confirm the commands.
How DNA ID ranges and replication agreements affect removal
Before you remove a server, check which ID range it holds. FreeIPA uses the Distributed Numeric Assignment (DNA) plugin so that each replica can allocate user and group IDs from a range assigned to it, which lets replicas create accounts without contacting each other for every new ID. If the server being removed holds a range that has partly been used, the unused portion can become stranded: no remaining server allocates from it, and the range stays unavailable for new users. Compare the ranges recorded for each server with the IDs already in use, and confirm with your team how the remaining servers will cover new allocations. Where a range needs repair, the ipa-idrange-fix tool and the ID range repair guidance in the operations documentation are the next places to read.
Next, map the replication agreements. Replication in FreeIPA runs between pairs of servers, and removing a server deletes every agreement attached to it. Run ipa topologysegment-find for each suffix and sketch the resulting graph, then confirm that every remaining server can still reach every other through some path. A removal that splits the graph leaves one site unable to receive changes. The deployment recommendations advise no more than four replication agreements per replica, so when you decide which links to add to close a gap, check that the servers you choose have capacity under that limit. Confirm the current agreement counts in your own topology, since the recommendation is a guideline and your layout may differ.
Do not solve a broken topology by restoring an older backup. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication, because the restored server's data no longer matches what its partners hold. If a rollback is tempting, treat it as a separate recovery exercise planned with your own backup process and a tested restore on isolated hosts. For routine removal, the safer path is to finish the topology checks, move any roles the server holds, and only then remove the server with ipa-replica-manage or ipa server-del as described in the removal steps.
The removal sequence from pre-checks to cleanup
This sequence removes a FreeIPA server without breaking certificate renewal, DNS, client lookups or replication for the servers that remain. Each step ends with a check, so the team can confirm the topology is healthy before the next change.
Take a full backup before any change
Run a full backup with ipa-backup on the server being removed and on at least one other replica before anything changes. Store the archive off the server and confirm it is readable. FreeIPA's backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so label the archive with the date and the topology it reflects. Done means you hold a verified full backup taken the same day as the removal plan, and the team has agreed where it is stored.
Inventory the roles the server holds
Identify every role on the server: CA, DNS, KRA, certificate renewal and CRL publication, and any trust or NTP function. Run ipa server-role-find on a remaining server and compare the output with the server's own role list. By default, the first server in a topology holds certificate renewal and CRL publication, so confirm whether the server being removed has it. Done means you have a written role map that shows which server takes over each role.
Move the CA renewal and CRL publisher roles
If the server holds the CA renewal server or CRL publisher role, move it to a surviving CA-enabled replica before removal. Confirm the target server runs the CA and can reach the other CA replicas. Then verify with ipa config-show that the renewal master now points to the new server. Done means the configuration reports the new renewal master, and a test certificate request completes against the remaining CA replica.
Confirm DNS and client resolver entries
Search every client's resolv.conf, DHCP options and configuration management data for the server's address, and remove it from the lists. FreeIPA's deployment recommendations advise at least two DNS servers in each client's resolv.conf, so confirm that clients still have at least two working DNS servers after the change. Resolve the service names from a sample of clients in each site with dig or getent. Done means lookups succeed through the remaining servers and no client still points at the retiring host.
Check ID ranges and replication topology
Run ipa idrange-find and check whether the server holds an ID range that is not covered elsewhere. Then review replication with ipa topologysegment-find and ipa topologysuffix-verify, and confirm the remaining servers still form a connected topology without isolating any site. Make sure the server is not the only link between two parts of the topology. Done means the ID ranges are assigned to a surviving server, and the verification shows no broken segments after the planned removal.
Remove the server with ipa server-del
From a different, healthy server, run ipa server-del with the host name of the server being removed. This removes its topology entries and service records from the directory. Run this from the surviving replica, never from the server being retired. Done means ipa server-find no longer lists the host, and ipa topologysegment-find shows no segment that references it.
Uninstall the server and clean up DNS records
On the retiring host, run ipa-server-install --uninstall, then reboot or stop the IPA services, and confirm the directory, Kerberos and certificate services have stopped. Next, delete the host's A and AAAA records and any remaining NS records and SRV entries that still point to it. Check the zones that hold the NS records and any DNS locations or service records that name the old host. Done means dig queries for the retired name return no answer, and no zone lists it as a nameserver.
Handle HSM-backed keys
If the server's CA keys are stored in a hardware security module, follow the HSM vendor's documentation and your own key custody procedure before you wipe or repurpose the machine. Confirm which keys belong to the shared CA and which are local to the server, and make sure the surviving CA replicas still reach their keys. Record the key handling decisions, including any destruction or transfer, in the change log. Done means the vendor or custody record confirms the disposition of each key, and the remaining CA replicas can sign requests without errors. Confirm the exact steps with your HSM vendor, since they depend on the product and deployment.
How the removal differs by deployment shape
In a single-site deployment, every server sits close to the others, so the main risk is losing the last copy of a role rather than network reach. With only a few replicas, one server often carries several roles at once, and the removal order matters more than the commands themselves. Confirm the remaining servers can reach each other and that replication is healthy before any change is made, because a small topology has little slack if a second server is affected.
- Role inventory first: List which servers run DNS, the CA, KRA, the CA renewal and CRL role, and the DNS SRV records that clients rely on, then confirm each role has a home on a server that will stay.
- Replication health: Check that every remaining agreement is current before you remove anything, since a broken agreement can hide missing data until the removal is underway.
- Client resolver settings: Make sure clients do not depend on the retiring server through their resolver configuration, and that enough DNS servers remain in each client's configuration.
- Backup before change: Take a current backup of a server that will remain in service, so a mistake in ordering can be reversed.
- Clean removal of records: Once the server is gone, verify that its host entry, service principals and NS records no longer point at it.
The decisive check in this shape is whether the remaining servers, alone, can serve every role the retiring server held.
When a server is the only CA or DNS host for its site, removing it affects local clients directly, and it can also affect other sites that rely on that site's DNS or certificate services. The work shifts from a simple removal into a site-level change: a new role host has to be in place and verified before the old one stops answering. Plan this as a sequence where the site keeps working at each step, not as a single cut.
- Replacement role host: Enable the missing role on another replica at the same site and verify it answers before the retiring server is touched.
- Location and resolver updates: Check whether clients are assigned to locations or use resolver lists that point to the retiring server, and update them so they fail over cleanly.
- Cross-site dependencies: Identify whether other sites resolve names or request certificates through this server, since a site-only view can miss those paths.
- Renewal and CRL duties: If the server is the CA renewal or CRL publisher, move that role deliberately and confirm publication continues before removal.
- Hardware security module keys: Confirm where any CA keys held in an HSM are reachable from the surviving servers, because keys that are only reachable through the retiring host are a removal blocker.
The decisive check is whether the site can resolve names and issue or validate certificates without the retiring server, tested from a client inside that site.
A same-site replacement is the least disruptive shape because a working server with the same roles already exists in the location. The risk is not losing capacity but making the swap look cleaner than it is: the replacement may hold the roles on paper while some data, records or clients still point at the old host. The work is mostly verification and cleanup, and the order is to bring the replacement fully into service before the old server is retired.
- Verified replacement first: Confirm the new server has the roles, replication agreements and DNS records it needs, and that clients can authenticate against it with the old server still running.
- Staged traffic shift: Reduce the old server's role in client configuration and DNS answers gradually, so any hidden dependency shows up while the old server can still answer.
- Agreement removal: Remove replication agreements to the retiring server only after confirming that no remaining server depends on it for updates.
- Record cleanup: Delete the old host's NS records, host entries and any service records left behind, since stale entries are a common source of later failures.
- Post-removal checks: Repeat the health checks and a test login from several clients after the old server is uninstalled, rather than assuming the swap succeeded.
The decisive check is whether every client and replica continues to work after the old server stops, not only whether the replacement reports healthy.
Removal options and when each fits
This table compares three ways to take a FreeIPA server out of service: moving its roles and removing it in place, retiring it after a verified replacement, and removing it without a replacement. Read each row against the roles the server holds today, since the first check is always which other servers take over CA, DNS, KRA, renewal and CRL duties. The main takeaway is that the option you can use depends on your topology, not on preference.
| Option | When it fits | Main risk | What to confirm first |
|---|---|---|---|
| In-place removal after moving roles | The server holds roles that other servers can take over, and the remaining topology stays connected | Roles left unassigned, or a replication path cut that isolates a site | Which servers hold CA, DNS, KRA, renewal and CRL roles, and whether each has a replacement |
| Retirement after a verified replacement | A new replica with the same role set is installed, tested and used by clients before the old server leaves | Clients or services still point at the old server, and DNS records linger after removal | The replacement replicates fully, resolves in DNS, and answers client authentication requests |
| Decommissioning without a replacement | Your topology has spare replicas in each site and the server is not the only path for a site or role | Losing capacity or resilience in a site, and possible loss of a role with no owner | Each site keeps at least one working replica, and the server is not the last holder of any role |
| Removal with a single remaining CA or DNS server | Rarely appropriate; use only when a planned role move is complete and verified | Single point of failure for certificate renewal or name resolution | Whether the CA renewal server and CRL publisher role has moved, and DNS answers from other servers |
| Removal of a server that holds a DNA ID range | Only after its range is confirmed as unused or reassigned | Duplicate or missing UIDs and GIDs for new users and groups | The ID range assigned to the server and whether any allocated IDs fall within it |
Security and operational risks during removal
Removing a FreeIPA server touches credentials, certificates, DNS, key material and logs at once. Each card below covers one risk that outlives the uninstall, so the removal plan should name an owner and a check for every item before the server leaves the topology.
Leftover credentials and keytabs
A retired host can still hold host keytabs, service principals and cached Kerberos tickets that remain valid until they expire or are revoked. Before the server is powered off, list the principals it served and confirm that no client or service still depends on them. Remove or rotate any keytab copied to other systems, and ask your security owner whether the retired host's disk will be wiped before reuse.
Stale certificates and CRL state
Certificates issued or renewed by the retired server remain trusted until expiry, and CRL publication depends on which server holds the renewal role. Confirm the CRL publisher and renewal roles have moved, and that the new holder publishes CRLs on schedule. Ask your PKI owner how revocation of any certificate tied to the retired host will be recorded and checked.
DNS records pointing at a removed server
A removed server's A, SRV and NS records can keep sending clients to an address that no longer answers, which slows or breaks Kerberos and LDAP lookups. Check every zone the server hosted, remove stale NS and service records, and confirm clients' resolv.conf still lists at least two working DNS servers. Name the person who signs off on the zone changes.
HSM key custody and destruction
If the retired server used an HSM for CA or KRA keys, the key material may sit in a device or partition that outlives the host. Confirm which keys belong to shared CA or KRA function and must stay available, and which may be destroyed. Ask your key custodians to document the destruction method and who witnesses it, since the outcome may matter for audit evidence.
Restoring old backups into a live topology
Restoring a backup taken before decommissioning into an active replica set can reintroduce retired servers and break replication. The FreeIPA backup documentation warns about restoring an outdated backup into an active topology. Keep the pre-removal backup offline, label it with the removal date, and confirm with your operations owner who may restore it and under what change ticket.
Audit log retention for the retired server
Logs from the retired server may be the only record of who authenticated, which certificates were issued and which administrative changes were made before removal. Decide where those logs go, how long they are kept and who can read them. Ask your compliance lead which retention period applies to identity and certificate logs, and confirm the archive is readable after the host is gone.
Questions teams ask before retiring a FreeIPA server
How much effort does removing a FreeIPA server take?
Effort depends mostly on what the server holds, not on the removal command itself. A replica that only serves LDAP and Kerberos is usually the simplest case. A server that also carries the CA, DNS, KRA, certificate renewal or CRL publishing role needs those roles moved first, and each role adds checks and change time. The number of replicas, how many replication agreements touch the server, whether it is the only server at a site, and whether HSM-backed keys are involved all add work. Ask the provider for a written inventory of roles and agreements for each server, and for the verification steps after removal, since those are often where time goes.
Can our own team remove a FreeIPA server without outside help?
A team with working FreeIPA administration experience can often remove a replica from a healthy topology, provided it reviews the topology, moves every role the server holds and tests the result. The risk rises when the server is the CA renewal server, holds the only DNS or CA role at a site, sits in a topology that is already degraded, or has HSM-backed keys. Teams should be honest about whether they have rehearsed a removal in a non-production environment and whether someone can roll back if replication breaks. A partner can carry out the work or review the team's plan before the change.
What does the work need from our team before it starts?
The team needs to provide a current topology diagram that shows every server, replication agreement, site, DNS location and role assignment. It also needs a recent full backup taken with ipa-backup, confirmed as restorable in a separate environment, and a change window agreed with application owners, since clients that rely on the retiring server may be affected. Administrative access to every replica and the DNS and certificate configuration is required, along with a list of clients whose resolv.conf or SSSD settings point at the server. These inputs should be listed in the written scope so the quote reflects them.
How long does a FreeIPA server removal take?
Duration is set by the number of roles to move, the size and number of sites, how many clients depend on the server, the change window policy and how long verification takes after each step. No duration is fixed for every deployment. A simple replica removal in a well-documented topology can be short, while a removal that involves moving CA and renewal roles, cleaning DNS records and handling HSM keys takes more planning and checking. Ask for the duration in the written scope, with each phase listed separately, and ask what happens if a verification step fails.
What happens if we remove the CA renewal server first?
The CA renewal server handles certificate renewal and CRL publication by default, and the backup documentation notes that the first server holds this role. Removing it without first assigning the role to another CA-capable server can stop renewals and prevent CRLs from being published, which can cause certificate-related failures across the deployment. The safe order is to confirm which server holds the renewal role, move it to a surviving CA server, verify that renewals and CRL publication work there, and only then remove the old server. Ask the provider to confirm this sequence against the FreeIPA version you run.
Should a renamed FreeIPA server be removed or replaced?
A FreeIPA server cannot be renamed in place, so a renamed server is normally handled by installing a replica with the new name, moving roles to it and retiring the old server. That makes the removal described on this page the last step of a rename, not a separate choice. Teams should not leave the old name in DNS, certificates or client configuration after the move. The written scope should state whether the rename project includes removing the old server, cleaning its records and updating clients, since those steps are easy to miss.
When should we bring in a partner to retire a FreeIPA server?
Bring in a partner when the server holds several critical roles, when the topology is already fragile, when HSM keys or regulated certificate hierarchies are involved, or when your team has not rehearsed a removal. A partner can also help when the internal team lacks time during the change window. DeployOpen implements, hardens, backs up and documents open-source platforms in infrastructure you control, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Ask for the quote to list the topology review, role transfer, rollback plan, verification and documentation as separate items.
How DeployOpen scopes and runs a FreeIPA server decommission
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including FreeIPA. For decommissioning a FreeIPA server, we start with a written inventory of the server's roles and dependencies, then remove it in a sequence agreed with your team before any command changes the live topology.
How we scope
- The written scope lists every role the server holds, including DNS, CA, KRA, renewal and CRL duties, before work starts.
- We confirm which surviving servers will take over each role and record the change window your team approves.
- Engagements are fixed-scope, so deliverables, the removal sequence and the verification steps are agreed in writing first.
How we build
- We check replication agreements, DNS locations, DNA ID ranges and client configuration on the remaining servers before removal.
- We take and verify a full backup of the topology, then run the server removal and clean up leftover DNS records and agreements.
- We test client authentication, certificate issuance and DNS resolution against the reduced topology, and handle HSM key retirement where it applies.
How we hand over
- You receive a written record of the pre-removal checks, commands run, roles moved and the verification results.
- The runbook covers the post-removal health checks your operators need to repeat on the remaining servers.
- We walk your platform and security teams through the updated server layout, clients and any follow-up actions.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer for FreeIPA servers that remain in your topology.
- Retainer scope is agreed in writing and can cover follow-up checks after a topology change or a later server removal.
- Questions about the decommission record or post-change behavior can be routed to the same team that ran the removal.
