Installing a FreeIPA replica

Why installing a FreeIPA replica is a planned change to live identity

Adding a FreeIPA replica is worth doing when you need more identity capacity or a second site, but it changes a live authentication service, so treat it as a planned change rather than a quick install. A replica is a full FreeIPA server. It combines 389 Directory Server for users, groups, hosts and policies, MIT Kerberos for single sign-on, the Dogtag certificate system and, if you enable them, ISC BIND DNS and NTP. Replicas are multi-master peers, so each one accepts writes and sends changes to the others. That is what lets a site keep logging users in when a link or a neighboring server fails, and it is also why a badly prepared replica can spread a problem across the whole topology.

Teams usually add a replica for three reasons: site resilience (a site must authenticate users when its WAN link is down), login locality (clients in a remote office should not cross the WAN for every Kerberos ticket), and role distribution (CA, DNS or KRA services should not depend on a single server). The published deployment recommendations advise at least two to three replicas in each datacenter, with no more than four replication agreements per replica and at least one replica per datacenter running PKI or DNS if you use those services. Confirm these figures against the current recommendations for your release before you finalize the layout, and confirm how many servers your sizing needs with the sibling sizing guidance.

Before you run any installation command, decide which roles the new server will carry, which existing replica it will pull from, and which clients will be pointed at it. Then confirm that forward and reverse DNS resolve correctly for the new host, because installation depends on them. Use the FreeIPA deployment recommendations as the baseline for dedicated servers and DNS settings, and record every decision in a change plan that your identity, network and PKI owners sign off on.

Which roles a new replica should carry: CA, DNS and KRA

A new FreeIPA replica can take on up to three optional roles: the integrated certificate authority, integrated DNS and the key recovery authority. Each role adds work to the server, changes what happens when that server fails, and affects where certificates are renewed, so decide them per replica before installation.

Integrated CA (Dogtag)

A replica installed with the CA role runs the Dogtag certificate system and takes part in issuing and replicating certificates. The deployment recommendations advise that at least one replica per datacenter runs PKI if you use it. Check that every site with CA-dependent services has a CA-capable replica, and confirm with your team which server will hold the renewal and CRL roles, using the sibling topic guidance on those roles.

Integrated DNS server

Adding the DNS role makes the replica answer queries for the IPA zones and serve as a target in client resolv.conf files. The recommendations call for at least two DNS servers in each client's resolv.conf, so plan DNS placement so that a client in each site can reach two DNS-capable replicas. Confirm that the zones and forwarders you need exist on the new server before clients are pointed at it.

Key recovery authority (KRA)

The KRA role stores escrowed encryption keys so that they can be recovered later. Only add it if your policy requires key escrow, because it adds sensitive key material to another server. Decide this before installation, and confirm with your security team which replicas will hold the role and how recovery access is controlled.

Replication load and failure impact

Each optional role adds services, configuration data and replication traffic to the new replica. A server that carries CA and DNS fails in more ways than a plain directory replica, so a single outage can remove several services at once. Place roles so that losing one site or one server leaves CA and DNS available elsewhere, and test that assumption in your own environment.

Where certificates are renewed

Certificate renewal and CRL publication run on one designated CA server, and a replica that carries the CA role can change which server does that work during migrations. Before you choose CA roles for a new replica, record which server currently renews certificates and publishes CRLs, and confirm the handover plan with the sibling topic on that role.

Role checklist before installation

Write down the roles for each new replica before running the install, including which site it serves, whether it carries CA, DNS or KRA, and which existing servers already hold each role. Compare that list with your replica count and agreement limits, and ask your installer to confirm the same list in the install plan so the server is not reconfigured later.

Replica options by site layout and role plan

A single site with one additional replica is the simplest case. The goal is redundancy for authentication, Kerberos ticket issuance and directory lookups, so the new server should be a full replica that can take over if the first server is unavailable. Whether it also takes DNS or CA depends on what the existing deployment already runs and how many servers the site will hold in total.

Role fit: A plain replica with the directory, Kerberos KDC and SSSD-facing services is the normal choice. Add the DNS role only if the site already runs IdM DNS and clients depend on it.
Dedicated host: Use a server that runs nothing else, as the deployment recommendations advise.
Agreement count: Confirm the existing server has fewer than four replication agreements before creating another, since the limit is no more than four per replica.
CA trade-off: Adding CA to a two-server site raises the number of CA peers to manage and adds renewal and CRL work, so confirm whether the site needs it at all.
DNS trade-off: A second DNS server gives clients a fallback in resolv.conf, but each DNS server also needs zone replication and reverse zone checks.

Before installing, confirm forward and reverse resolution for the new host and confirm which server currently holds the CA renewal role.

Some sites only need client-facing DNS. The clients there use FreeIPA for login through servers elsewhere, but they benefit from a nearby name server. In this layout the new replica still needs to be a full FreeIPA server if it runs IdM DNS, because the DNS role is installed on IPA servers, so it is not a lightweight resolver.

Role fit: Install the DNS role on the replica and leave out CA unless the site has a specific need for it.
Resolution checks: Confirm forward and reverse records for the new host and that clients can reach its DNS service on the network they use.
Resolver lists: Ensure each client has at least two DNS servers in resolv.conf, as the deployment recommendations advise, so one server outage does not break name lookups.
Agreement count: Confirm the replica can connect to the rest of the topology within the four-agreement limit.
Trade-off: A DNS-only role keeps the CA footprint small, but it still means running a full IPA server that must be patched, backed up and monitored with the rest of the fleet.

Before deployment, confirm which server in the topology holds the DNS and CA roles so that the new replica does not duplicate roles without a reason.

Install and verify a replica in order

This sequence takes a new FreeIPA replica from a dedicated host to a verified member of the topology, with DNS, time, replication and roles checked before any client is pointed at it. Each step closes with a check you can run, so a failure is caught while the old servers still carry all the traffic.

Confirm forward and reverse DNS for the host
The platform or network team confirms that the new host has a fully qualified name that resolves forward to its address and reverses back to the same name. Run forward and reverse lookups from the new host and from an existing master, and check that both return the same name and address. Confirm the new host name is not already used by a retired server, since stale records cause enrollment and replication failures. The step is done when both directions agree from both machines.
Confirm time sync and network paths to a master
The operations team confirms that the new host and an existing master keep accurate time through the same time source, because Kerberos rejects tickets when clocks drift too far apart. Check the synchronization status on both machines and confirm that the required ports between the new host and the existing master are open in both directions, including the LDAP, Kerberos, and replication ports your deployment uses. Test each path from the new host, not only from your workstation. The step is done when time sources report synchronized and every required port connects.
Prepare the host as a dedicated server
The platform team installs the operating system package set, applies the same patch level as the existing masters, and confirms the host runs no other application. FreeIPA's deployment recommendations call for dedicated servers, so the host should not also run web services, file shares or unrelated agents. Record the host's roles, memory, disk and DNS settings in your change record before the install starts. The step is done when the host is patched, dedicated, and matches the version of the existing servers.
Choose the roles and run the replica install
The identity team decides which roles the new replica will carry: certificate authority, integrated DNS, and key recovery (KRA) if your design uses them, and confirms that each role is placed deliberately across sites. Run the replica installation with the chosen options from an existing master's credentials, following the replica install procedure for your release. Keep the install log, because it records each role and configuration step. The step is done when the installer exits without errors and the host appears as an enrolled server.
Create or confirm replication agreements
The identity team checks the replication topology and creates agreements between the new replica and its peers, staying within the four-per-replica guidance in FreeIPA's deployment recommendations. Review the existing agreements on the new host and on its neighbors so that no replica exceeds the limit and every site remains connected. Where a site is involved, confirm that at least two or three replicas exist per data center as the guidance describes. The step is done when the topology diagram matches the agreements listed on each server.
Check replication status and DNS answers
The identity team checks replication from the new server, confirming that directory data from the existing masters has arrived and that changes made on one server appear on the others. Run the FreeIPA replication status and topology checks, review the directory and DNS logs for errors, and query DNS on the new server for the service records clients will use, including the Kerberos and LDAP SRV records. Also confirm that the certificate authority and DNS roles answer if you enabled them. The step is done when replication reports no errors and every query returns the expected records.
Point clients and resolv.conf at the new replica
The identity team adds the new replica to client resolver configuration only after the previous step passed, and keeps at least two DNS servers listed in each client's resolv.conf as the deployment recommendations advise. Roll the change out in small groups, then confirm that a test client resolves and authenticates against the new server, for example by checking a Kerberos login and an SSSD lookup. Watch authentication and DNS logs for a period your change process defines. The step is done when test clients authenticate through the new server and no errors appear in the logs.

How replication agreements shape the new replica's connections

Every FreeIPA replica links to its peers through replication agreements, because FreeIPA runs on 389 Directory Server in a multi-master configuration. Any server that accepts writes can send them to any peer it has an agreement with, so the new replica does not simply copy data from one source. Before you run the install, decide which existing servers it will connect to, since that choice determines how changes reach it and how many paths a later failure can take. In the first step of the install, the replica is enrolled through an existing server, and the agreements you create afterward define its long-term connections. Plan them on paper first, using your current server list and the sites each server serves.

The FreeIPA deployment recommendations cap replication agreements at no more than four per replica, and they advise two to three replicas in each datacenter. Pick peers so the new server joins at least one server in its own site and one in a second site, which keeps the topology connected if a site goes down. Avoid linking to every server out of caution. A topology with many agreements is harder to reason about during an incident, because each extra link adds another path that can carry a bad change, another server to check for lag, and another set of conflicts to resolve. Before you add agreements, confirm each candidate peer's current agreement count with ipa topologysegment-find, and record the result in your change ticket.

Backups add a separate risk to the topology. The FreeIPA backup documentation warns that restoring an outdated backup into an active replica topology can break replication. A replica installed from an old snapshot, or a restore run on a live server while peers have moved on, can hold data that conflicts with the rest of the directory. Use a backup only for disaster recovery under the documented restore procedure, and never as a shortcut for building a new replica. Confirm with your own runbook how recent a backup must be, and check replication status across all peers after the new server joins. The FreeIPA backup and restore page sets out the restore constraints you need to plan around.

Security and operational risks when a replica joins

A new replica copies user, host, policy and key data, and it may also take on DNS and CA roles. The cards below cover the hardening, role, patch level, monitoring, backup and access questions to settle before the server joins the topology.

Dedicated, hardened host

A replica holds a full copy of the directory, including user credentials, host records and policy. Run it on a dedicated server without other applications, as FreeIPA's deployment recommendations advise, and harden it to the same standard as your existing masters. Check firewall rules, OS patch level, time sync, SSH access and disk encryption before running the installer. Confirm that the replica is not a lower-trust host that happens to be convenient.

Confirm the installed version is current

FreeIPA 4.13.4 fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, and hardened authentication checks across the API. Before a replica joins, confirm that the version on the new server matches or exceeds the patched release on your existing masters. A replica on an older build can reintroduce an exposure the rest of the topology has already closed.

DNS role attack surface

A DNS replica answers queries for your internal zones and, when clients use DNS over TLS, handles encrypted client traffic. Each DNS role adds listening services and zone data that an attacker could target or poison if the host is weak. Decide whether the new server needs the DNS role at all, restrict who can query and update zones, and confirm that dynamic updates are limited to the hosts that need them.

CA role and key material

A replica that takes the CA role stores certificate authority material and issues certificates for hosts and services. Compromise of that server can lead to forged certificates for your environment, so treat it as a high-value target. Limit root and administrative logins, record who can issue or revoke certificates, and confirm that the CA role placement matches your design for renewal and CRL publication.

Replication health monitoring

Once the replica joins, replication agreements carry changes in both directions, so a broken link can leave servers with different user or policy data. Check replication status after the install, set alerts for failed or lagging agreements, and watch the server's logs for errors. Keep the agreement count within the recommended limit so that monitoring stays simple and failures are easy to trace.

Backup coverage for the new server

Backups from an existing server do not automatically cover a replica you have just added, so confirm that the new server has its own scheduled backup job and that the backups are stored off the host. Note that restoring an outdated backup into an active topology can break replication, so record which server each backup came from and when. Test a restore in a separate environment before you rely on it.

Administrative access to the host

Anyone who administers a replica can read directory data and, depending on their role, change policy for every client. Limit root and sudo access to a named group, require individual accounts with logged access, and remove any default or shared administrator accounts. Document who may run ipa commands on the new server and review that list whenever staff change roles.

Questions teams ask before installing a replica

How much does it cost to install a FreeIPA replica?

Cost depends on the written scope, so there is no standard figure to quote here. The main components are the discovery work on DNS, reverse zones and network paths, the installation and role configuration on each new server, the replication agreement design, and the verification testing before clients use the server. Each replica you add multiplies some of that work, while the first replica in a new site carries the most site-specific checks. Ask for a quote that lists each component separately, states whether it is one-time or recurring, and names what the customer must provide. DeployOpen does not publish a price list, and a quote follows from the written scope.

How long does a FreeIPA replica installation take?

Duration depends mostly on how ready the environment is, not on the install command itself. A clean network with correct forward and reverse DNS, an available host, and agreed roles can move quickly, while missing DNS records, firewall changes that need approval, or an unclear role plan add waiting time. Ask for a schedule in the written scope that separates the prerequisite checks, the change window, the verification period and any follow-up work. Confirm with your change board how long approvals take, because that is often the longest step.

What do we need to provide before a replica install starts?

You need to provide access and information that only your organization holds. Typical inputs are the target host or virtual machine with its operating system and sizing, a fully qualified host name, DNS zone ownership, a list of existing FreeIPA servers and their roles, firewall rules between sites, and an admin credential with the rights to change DNS records. If your sites use a specific automation tool, share the existing playbooks or change templates. Ask the team to confirm these items in writing before the work is scheduled, so the first session is not spent collecting them.

Can our own team install a FreeIPA replica without a partner?

Yes, a capable Linux and identity team can install a replica using the vendor documentation and its own change process. The work is manageable when the topology is small, the DNS design is already settled and the team has tested replication before. Outside help becomes more useful when several sites are involved, when CA, DNS or KRA roles must be placed carefully, or when the replica must join a live production topology without disrupting clients. Whichever path you choose, confirm the current installation steps against the official FreeIPA documentation for the version you run.

How does DeployOpen scope a replica installation?

DeployOpen scopes a replica install as a fixed-scope engagement, with the scope, deliverables and timeline agreed in writing before work starts. The scope usually covers the discovery of your current topology, the DNS and reverse resolution checks, the role decisions for the new server, the replication agreements to create, the installation, and the verification steps before clients are pointed at it. It also records what remains with your team, such as change approvals and client rollout. Ask for the scope to name the servers in scope and the exact checks each one receives.

What makes replica installation effort go up or down?

The biggest drivers are the number of sites, the roles the new server must carry, and the network between sites. Each additional site adds DNS and firewall checks, and placing CA, DNS or KRA roles adds validation work. Constrained networks, split DNS designs, and existing automation can move effort in either direction: automation shortens repeatable steps, while undocumented DNS or manual change processes lengthen them. Replication agreement limits in the vendor recommendations also shape the plan, because a server that would exceed the recommended number of agreements may need a different placement.

What checks should an engineer run before adding a new replica?

Before the install, confirm that the new host resolves forward and reverse, that its name matches the DNS records you intend to publish, and that the ports FreeIPA needs are open between it and existing servers. Check the current replication health and the roles held by existing servers, so the new replica does not depend on a server already under strain. After installation, verify replication agreements in both directions, confirm DNS answers from the new server, and test a client authentication before pointing clients at it. Document each result so the change can be audited later.

What to change after the replica is live

The first change is on the clients. Once the new replica answers DNS and Kerberos correctly, update each client's resolv.conf so it lists at least two DNS servers, as the FreeIPA deployment recommendations advise. Confirm that the list includes the new replica alongside an existing one, and that no client depends on a single server for name resolution. On enrolled hosts, check that SSSD still reaches the servers it is configured to use, and test a login from a client that was not enrolled through the new replica. Where the environment uses configuration management, make the change there so it does not drift back on the next run.

Next, revisit the server roles and replication agreements as the design settles. A replica installed with a CA, DNS or KRA role can be adjusted later, but each role change affects which server answers certificate and DNS requests, so confirm the intended layout with the team before moving anything. Check the number of replication agreements on each server against the recommendation of no more than four per replica, and remove or add agreements deliberately rather than by habit. Confirm with your own environment and the current FreeIPA documentation which role changes are supported in place and which require a fresh replica, because this differs between releases.

Finally, record the change in the runbooks. Note the new server's host name, its site, the roles it carries, the agreements it holds and the date it went live. Update the list of servers that clients and backup jobs point to, and make sure the backup procedure includes the new replica. Recovery steps should name which server holds the certificate renewal and CRL role by default, so that someone responding to an outage does not have to rediscover it. Keep the runbook in version control with the rest of your identity documentation, and review it after each topology change.

How DeployOpen scopes and delivers a FreeIPA replica

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including cloud accounts, data centers and air-gapped networks. For a FreeIPA replica, we start from your existing topology and DNS, agree the roles and agreements in writing, and verify the new server before any client is pointed at it.

How we scope

We review your current FreeIPA servers, sites, DNS zones and reverse zones before naming the replica's roles.
The written scope states which roles the new replica takes: CA, DNS, KRA or none, with the reason for each.
Engagements are fixed-scope, so the agreed replication agreements, checks and deliverables are fixed before work starts.

How we build

We confirm forward and reverse name resolution from the new host and from existing servers before installation begins.
Replication agreements are created in a planned order, and we check that each agreement stays within your agreed limit per replica.
Each installation step is recorded so the server can be rebuilt or reviewed later by your own team.

How we hand over

You receive a verification record covering replication status, DNS answers, certificate services and Kerberos login from a test client.
Clients are moved to the new replica only after the written checks pass, and the rollback path is documented.
Runbook notes cover where the server sits in the topology, which roles it holds and who owns each follow-up task.

How we support

Ongoing support, upgrades and continuous testing for your FreeIPA servers are available as a retainer.
Support can cover health checks after the replica joins, including replication monitoring and backup review.
Any later change to roles or topology is scoped in writing, so the replica's role history stays traceable.