How do you keep FreeIPA logins working when a server fails?
High availability means several FreeIPA replicas in each datacenter, with the certificate authority and DNS running on more than one of them, and with clients that move to another server when one stops answering. Consider a team whose Linux logins, sudo rules and host certificates all depend on a single FreeIPA server. When that server fails, nobody can authenticate, nobody gets a sudo rule evaluated and new certificates cannot be issued. The design work is about removing that single point of failure for each of those services, not only for the directory.
The problem is harder than it looks because the parts do not fail independently. FreeIPA combines 389 Directory Server, MIT Kerberos, the Dogtag certificate system and optional ISC BIND DNS, and each has its own replication and failover behavior. The deployment recommendations advise two to three replicas in each datacenter, no more than four replication agreements per replica, and at least one replica per datacenter running PKI or DNS if you use them. Replication topology is therefore a design decision made early, because adding replicas later means revisiting agreements, placement and which servers carry which roles.
The first server you install has a role that is easy to forget. By default it handles certificate renewal and CRL publication, so a failure of that host affects certificate operations even when logins still work through the other replicas. Confirm which server currently holds these roles, decide whether a second server should be able to take them over, and write down the procedure for moving them. Also plan for client DNS: each client's resolv.conf should list at least two DNS servers, and you should test that a client resolves the IPA domain and locates a KDC and LDAP server when the first DNS server is unreachable.
Backups only help if they can be restored and the result has been tested. FreeIPA provides ipa-backup and ipa-restore, with full backups or online data-only backups. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so a restore test must be run on an isolated copy of the topology, not on production replicas. Define how often you back up, where copies are stored, who can restore them, and how long a restore takes in your environment. Measure these in a rehearsal rather than assuming them.
This page covers the design and verification of high availability: replica placement, agreement limits, CA and DNS spread, client failover and restore testing. It does not cover the initial rollout, migration from another directory or upgrades of replicas, which are handled by the implementation, migration and upgrade pages in this series. Before go-live, confirm with your own architecture review which failures you must survive, which outages you accept, and what evidence you will keep that each failover test passed.
Which FreeIPA components need redundancy?
Each FreeIPA component fails on its own, so one lost server can look like a different problem elsewhere. Directory replication, the Kerberos KDC, the certificate authority, DNS, time and client server selection each need a surviving counterpart with a defined role. Confirm which server holds each role before you size the topology.
389 Directory Server replication
389 Directory Server stores users, groups, hosts and policies as a multi-master LDAPv3 directory, so every replica accepts changes that must reach its peers. If one server is lost, the remaining replicas keep serving lookups and logins, but any change made on that server and not yet replicated is at risk. Every replica carries the full directory, so the role needed is a directory replica. Plan two to three replicas per datacenter, keep no more than four replication agreements per replica, and check agreement health after every change.
MIT Kerberos KDC
The MIT Kerberos KDC issues the tickets behind single sign-on, and it reads its principals from the directory. Losing one server removes one KDC, and clients that were pointed at it must try another. Clients find KDCs through DNS service records, so a dead server stays in discovery until its records change or the client moves on. Every replica runs a KDC, so the required role is any replica. After a failover drill, run kinit against each surviving server to confirm tickets issue from all of them.
Dogtag certificate authority
The Dogtag certificate authority issues host and service certificates and publishes the certificate revocation list. By default the first server handles certificate renewal and CRL publication, so losing it on its own stops those tasks, while enrolled clients keep authenticating for a time. Require at least one replica per datacenter running the CA role. Before planned maintenance, check which server is the CA renewal master, and move that role to a surviving CA replica if the first server must come down.
ISC BIND DNS
When FreeIPA hosts DNS, ISC BIND serves the IPA zone data and the SRV records that clients use to find KDCs and LDAP servers. A lost DNS server returns no answers for IPA names to resolvers that depend on it, so Kerberos and LDAP lookups fail there. Require at least one DNS replica per datacenter, and list at least two DNS servers in each client's resolv.conf. If DNS is hosted elsewhere, the same SRV records must survive on that service, and its redundancy becomes your responsibility.
Optional NTP time sync
Kerberos refuses tickets when client and server clocks drift too far apart, so time is a hard dependency for authentication. FreeIPA can run NTP on its servers, or you can use an existing time service. When a server loses its time source and drifts, clients it serves see authentication failures that look like password problems. Give every server more than one upstream time source, and alert on clock offset in monitoring. The required role is a working time source on each replica.
SSSD client server selection
SSSD on each Linux client caches identities and credentials and chooses which FreeIPA server to contact, using DNS discovery and any configured list. When the active server disappears, SSSD must time out and try another, so failover depends on client configuration as much as on server count. Clients with no reachable alternate stay offline, though cached logins may still work for a time. No server role is needed here. Simulate an outage from a test client and read the SSSD logs to confirm the switch.
Which replica layout fits your datacenters?
This table compares common FreeIPA replica layouts across one or two datacenters, plus an optional third site. Read each row against your sites, outage tolerance and change calendar, then use the last column as the list of questions for your platform team. The recommendation is two to three replicas per datacenter, with no more than four replication agreements per replica.
| Layout | When it fits | Operational cost | Confirm with the platform team |
|---|---|---|---|
| One datacenter, two replicas | Single-site estate where a short outage of one server is acceptable and the site itself is the main risk. | One agreement to manage. Patching must leave one replica running. No site-level failover. | Who rebuilds a lost replica, and how long clients can run on the surviving server. |
| One datacenter, three replicas | Single-site estate that needs room to patch or lose one server while another stays in service. | Three replicas to patch in sequence. Each replica stays well under the four-agreement limit. | Which replicas run the CA and DNS, and whether that placement matches the patch order. |
| Two datacenters, two replicas each | Two sites with a disaster recovery need and a modest server count. | Four servers to patch by site. Agreements cross the WAN. CA and DNS must sit on at least one replica per site. | Reliability of the inter-site link, and whether client DNS failover is tested from each site. |
| Two datacenters, three replicas each | Larger estates or critical identity services where losing a site and a server at the other site must both be survivable. | Six servers to patch. More certificate and DNS placement to track. Agreement counts must stay at or under four per replica. | Agreement topology for each replica, and who owns the change calendar across both sites. |
| Third site for witness or DNS only | A third location exists but cannot host full replicas, and it can serve a DNS or witness role. | An extra server outside the main sites adds monitoring and patching. Its role must be written down. | Whether the platform team supports a non-replica node in this role, and which clients will use it. |
| Location of the first server | Applies to every layout, since it is the default holder of certificate renewal and CRL publication. | Losing this server affects renewal and CRL publication until the role is moved or restored. | Whether the role can move to another replica, and how that move is tested before a planned outage. |
| Client DNS placement | Applies to every layout that runs DNS on IdM servers. | Each client needs at least two DNS servers in resolv.conf. DNS should run on at least one replica per datacenter. | Which resolver settings reach both sites, and how a failed DNS server is detected on clients. |
How do you build a FreeIPA HA topology step by step?
This sequence takes a FreeIPA domain from an unchecked DNS and naming design to replicas that serve logins, certificates and name lookups from more than one datacenter. Each step ends with a check, so a fault is found before the next server or client depends on it. The order matters because each replica copies from servers that already exist, and the first server holds roles the others inherit.
Confirm DNS zones and host naming
Before installing anything, confirm that the IPA DNS domain does not overlap with any other namespace you plan to trust, that forward and reverse zones are hosted where the servers can manage them, and that every planned server has a fixed, fully qualified name. Write the naming list first, because renaming a server after it joins the topology is much harder. Done when forward and reverse lookups for every planned name return the expected addresses from a host in each site.
Provision dedicated servers for FreeIPA
Build two to three replicas in each datacenter on hosts that run no other applications, as the FreeIPA deployment recommendations advise. Confirm that the operating system is supported by the FreeIPA release you choose, that time synchronization is configured on every host, and that the network ports FreeIPA needs are open between all sites. Check this by testing reachability from each server to every other server on those ports and confirming that clock sync is healthy on all hosts before you continue.
Install the first server
Run the server installer on the first host using the realm and DNS domain confirmed in step one. Enable the integrated CA and DNS only if your design uses them, and record which datacenter hosts this server. The first server handles certificate renewal and CRL publication by default, so place it where your team can reach it during recovery. Check that an administrator ticket can be obtained with kinit, that the FreeIPA services report as running, and that the domain's SRV records resolve from the host.
Add replicas one at a time
Create each replica from the first server, then install it on the new host. Add one replica at a time and let the topology settle before adding the next. Place the CA and DNS on at least one replica in each datacenter if your design uses them, so each site keeps certificate and name services if the link to other sites fails. Check after each addition that the new server appears in the topology list, that a test change made on the first server reaches it, and that it answers DNS queries for the domain.
Set replication agreements within the limit
Build the replication topology so that no replica has more than four replication agreements, and so that every server can reach every other through at least one path. Add agreements between sites deliberately, rather than letting each new replica link to whatever server is nearest. Check the agreement list on each replica and run a replication status check. Then create a test user on one server and confirm it appears on all others, which shows the topology has no broken segments.
Enroll clients against the replica list
Set each client's resolv.conf to at least two DNS servers, ideally in different datacenters, so name lookups do not depend on one server. Run the client installer and point it at the replica list so enrollment is not tied to a single host. Confirm that the client resolves the domain's SRV records through each listed DNS server on its own. Then test failover by taking one replica out of service in a planned test window and confirming that logins still succeed through the remaining servers.
How does HA differ for single-site, multi-site and air-gapped deployments?
In one datacenter, high availability mostly means surviving the loss of one replica or one host without losing logins or certificate operations. Keep the replicas on dedicated servers, in a small topology where each replica holds no more than four replication agreements.
- Replica count: Plan two to three replicas, which the deployment recommendations advise for each datacenter.
- CA and DNS: If you use the integrated CA and DNS, run them on at least two replicas so that losing one host does not remove certificate issuance or name resolution.
- Client discovery: Put at least two DNS servers in each client's resolv.conf and let SSSD find servers through DNS.
- First server: The first server handles certificate renewal and CRL publication by default. Record which host holds that role and document how you would move it before you need to. Confirm the procedure for your release.
- Shared failure domains: One site shares power, cooling and upstream network. Those are the failures that can take out every replica at once, so confirm how your facility covers them.
Before go-live, stop one replica during a planned window and confirm that client logins and DNS lookups continue, then rehearse a restore from backup.
When sites are joined by WAN links, the design goal is to keep authentication local when a link degrades and to keep replication consistent across the WAN. Each site should be able to serve its own clients, and the replication topology should be planned before servers are added, because the four-agreement limit constrains which sites can replicate to which.
- Replica count: Place two to three replicas in each datacenter so that every site can authenticate users without crossing the WAN.
- CA and DNS: Run at least one replica per datacenter with PKI or DNS if you use them, so each site keeps local name service and some renewal capability.
- Client discovery: Clients should resolve servers in their own site first. Confirm how your DNS design and SSSD configuration direct each subnet to its local replicas, then test failover to a remote site.
- First server: The renewal and CRL role stays on one host by default, which usually sits in one site. Decide where it lives and document what happens to certificate operations if that site is cut off from the others.
- Link characteristics: Measure latency and bandwidth on your own circuits and test replication traffic against them. Ask your network team to confirm the figures for each link before you finalize the topology.
Test a full WAN partition in a non-production environment, then confirm that local logins, DNS resolution and certificate issuance keep working at each site.
On an air-gapped or isolated network, FreeIPA cannot rely on public DNS, public NTP, online package mirrors or any external service. Every dependency must come from inside the enclave, so the team owns the time source, name resolution, certificate chain and backup media. The replica pattern stays similar to other designs, but the operational work is heavier.
- Replica count: Use two to three replicas on dedicated servers within the enclave, keeping to the same four-agreement limit.
- CA and DNS: Run the CA and DNS on at least two replicas. Point DNS forwarders only at internal resolvers, and distribute the internal CA chain to clients through your own approved process.
- Time sources: Kerberos depends on closely synchronized clocks. Point replicas and clients at internal time sources that you run or trust, and confirm how FreeIPA's time configuration behaves in your build.
- Client discovery: Keep resolv.conf entries and SRV records internal. Verify that no client can fall back to an external resolver.
- Backups and updates: Store ipa-backup output on approved media and test ipa-restore on an isolated host. Agree in advance how packages and fixes enter the enclave through your transfer procedure.
Confirm that every package, time, DNS and certificate dependency resolves inside the enclave, and that a restored replica can rejoin the topology without any external access.
How do you test that failover works before you trust it?
A FreeIPA high availability design is only proven when each failure path has been exercised and its results recorded. Start with replication. Run ipa-replica-manage list on every replica and check that every replication agreement is present, that replication is current on each one, and that no replica exceeds the four agreements the deployment recommendations allow. Confirm that each datacenter holds two to three replicas and that the CA and DNS roles sit on more than one server where you planned them. Save this output as a baseline before any test, so later drift is easy to spot. Confirm with your FreeIPA version's documentation which checks the ipa-healthcheck tool covers before you rely on it for sign-off.
Next, verify the certificate authority roles on each relevant replica. The first server handles certificate renewal and CRL publication by default, so identify which host currently holds that role and record it. Then confirm that each replica running the CA responds correctly to a certificate status query and that the CRL is published from the host you expect. Check the renewal role through certmonger tracking on the servers that hold service certificates. Treat any move of the renewal role as a change that belongs in a maintenance window, and confirm the documented procedure for moving it in your version before scheduling the test.
DNS and Kerberos tests show whether clients keep working when one server disappears. Pick a test client whose resolv.conf lists at least two DNS servers, stop the DNS service on one of them, and run dig against the realm's host names and service records from several clients. Resolution should continue through the second server. For Kerberos, with one replica's KDC unavailable, run kinit as a test user, check the ticket with klist, renew it with kinit -R, and log in over SSH to a enrolled host. Read-only checks such as replication listing, dig queries and klist are non-destructive and can run any time. Stopping a DNS or KDC service in production, and any full replica outage, belongs in a maintenance window with a named rollback owner.
Certificate issuance needs its own test during a failover. With one CA-capable replica stopped, request a test certificate for a non-production host using ipa cert-request or a certmonger request, and confirm that the certificate is issued, appears in ipa cert-find, and validates against the CA chain. Run the same request against each surviving CA replica. Record the outcome of every test in a table with the date, the host, the command and the result, so the evidence can be shared with reviewers and auditors without rebuilding it later.
Rollback needs the same care. Before any destructive test, take a VM snapshot or confirmed backup of the affected replica. If a replica fails after a change, remove it from the topology with ipa-replica-manage del from a healthy server, clean its agreements, and then rebuild it from a verified replica rather than trying to repair it in place. Never restore an outdated backup into an active replica topology, because the backup documentation warns that this can break replication. A backup is not verified until a restore has been rehearsed. Restore a recent ipa-backup into an isolated host, confirm replication, CA, DNS and Kerberos behave correctly, and time the procedure. Ask any partner for the written rehearsal result, not only a statement that backups run.
What drives the effort and cost of FreeIPA HA?
This table lists the design choices that change how much work a FreeIPA high availability build takes, what each one does to the work and how to keep it contained. Read it before asking for a quote, because each row maps to a question the written scope should answer.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Datacenters and WAN links | Each datacenter needs its own replicas, so the topology, firewall rules, time sync and failover tests multiply with every site and every WAN path between them. | Limit the number of sites that hold identity replicas, and confirm which sites only need SSSD clients pointed at nearby replicas. |
| Number of replicas and agreements | The deployment guidance suggests two to three replicas per datacenter and no more than four replication agreements per replica, so every added server adds topology design, joins, and replication checks. | Design the agreement map on paper first, keep to the recommended replica count per site, and document which replica serves which role. |
| DNS zone complexity | Multiple zones, reverse zones, split-horizon views and external forwarders each need records, validation and client resolver changes, and DNS faults often look like authentication faults. | Keep the zone list short, agree the record ownership model early, and ask the quote to name every zone and forwarder in scope. |
| Enrolled clients and OS mix | Each client OS and version needs its own SSSD, Kerberos and PAM configuration, and older or unusual hosts often need extra testing before a rollout wave. | Group hosts by OS family and enroll in waves, and ask whether the quote covers a fixed number of test hosts per OS. |
| Internal or external CA and DNS | Running the Dogtag CA and integrated DNS on replicas means placing them, renewing certificates, and including them in backup and failover tests; external CA or DNS shifts that work to other teams and needs clear hand-offs. | Decide the CA and DNS placement before build, and confirm in writing which party owns certificate renewal and DNS record changes. |
| Backup storage and retention | Full and online data-only backups need storage capacity, a retention policy, off-host copies and a restore test; the backup guidance also warns that restoring an outdated backup into an active topology can break replication. | Set a retention period with the security owner, store copies off the replica hosts, and ask for at least one documented restore rehearsal in the scope. |
| Monitoring and change control | Health checks for replication, certificate expiry, DNS answers and backup jobs must feed existing alerting, and every change to the topology needs a ticket, approval and a record of the step. | Reuse the existing monitoring stack, define the checks in the runbook, and confirm which change approvals apply to identity servers. |
| Compliance evidence needs | An assessor may ask for configuration baselines, access reviews, backup logs, patch records and restore test results, and each one takes time to collect and keep current. DeployOpen prepares this evidence, but auditors and certification bodies issue any opinion. | List the control objectives your auditor expects up front, and ask the quote to name the evidence artifacts and how often they are refreshed. |
What must you monitor, back up and document after go-live?
After go-live, a FreeIPA high availability design stays healthy only if someone checks it on a schedule. The recurring work falls into five areas: replication status and lag between replicas, certificate expiry and renewal, publication of the certificate revocation list (CRL) on the first server, DNS health on every replica that serves records, and drift in client enrollment. Each area needs a named owner, a check frequency agreed in advance, and an alert that reaches a person who can act on it. Replication alerts should trigger on failed agreements and on lag that grows over time, not only on a complete outage.
Certificate work deserves its own calendar entry. The integrated Dogtag certificate authority issues host, service and CA certificates, and the renewal and expiry dates of each one should be listed and tracked. The FreeIPA backup documentation warns that the first server handles certificate renewal and CRL publication by default. That makes the first server a single point of responsibility inside a topology that otherwise has no single point of failure. Confirm with your own deployment how the renewal role is set, whether it is still on the server you expect, and what happens to CRL publication if that server is offline for a long period. Check the current settings against the FreeIPA documentation for your installed release before you rely on them.
Backups are the second half of the runbook. FreeIPA provides ipa-backup with full and data-only forms, and online data-only backups can run while services stay up. Decide which form runs on which schedule, who reviews the job output, and how long each copy is kept. Store copies off the servers that produced them, in a location that a failed replica or a compromised server cannot reach. The same warning applies to restore. Restoring an outdated backup into an active replica topology can break replication, so a restore is a deliberate event, not a routine rollback. Treat the backup as a source for rebuilding one replica, and confirm the procedure in a test environment before you need it in production.
The restore runbook must name the replica that will be restored, the reason it was chosen, and the steps that rejoin it to the topology without disturbing the others. Write down which replica holds the data you want, how the remaining replicas are checked for consistency afterwards, and who approves the change. Upgrades follow the same discipline. Upgrade one replica at a time, verify replication and certificate services on it before moving to the next, and keep the sequence in the runbook. Record the operating system and FreeIPA version on each server, since the upgrade order depends on them.
Finally, keep a current topology diagram and runbook. The diagram should show each datacenter, each replica, its replication agreements (no more than four per replica is the recommended limit), which replicas run the CA and DNS, and which server holds the renewal role. Update it whenever a replica is added, retired or moved. Review the runbook after each test restore and after each upgrade cycle, so that the people on call can act without relying on memory. Ask any implementation partner to deliver these documents as part of the handover, in a format your team can edit.
How do you protect the CA, the replicas and the backups?
Replicas in a FreeIPA high availability design hold the directory, Kerberos keys and, where deployed, the Dogtag CA and its signing material. Each control below closes a specific path to those secrets: a compromised host, an over-privileged administrator, a stale restore or an unpatched service.
Dedicated replica hosts
Run each IdM replica on a server that does nothing else, not a shared application host or build runner. FreeIPA's deployment recommendations call for dedicated servers, because a compromise of any co-hosted service can expose directory data and Kerberos keys held on the replica. Check that the host's package set, cron jobs and network exposure match only what IdM needs.
Restricted administrative access to replicas
Limit root and sudo access on each replica to a named group of administrators, and route changes through the same change process as production identity policy. Without this, one stolen administrator credential can alter replication, disable an OTP policy or read directory contents. Confirm who can log in to each replica and review that list on a fixed schedule.
Protecting the CA and its keys
Only replicas that run the Dogtag CA hold its signing material, so treat those hosts as the most sensitive part of the topic. Confirm where the CA signing key is stored, who can export it and whether any HSM or key-protection option applies to your environment. The main failure to prevent is a forged certificate issued from a stolen CA key, which no later revocation can fully undo.
Encrypted and access-controlled backups
ipa-backup produces archives that contain directory data, keys and configuration, so store them with encryption at rest and restrict read access to the backup administrators. Keep copies off the replicas and in a location with separate credentials. A backup that anyone can read is a complete copy of the identity store for an attacker.
Current security releases on every replica
Keep all replicas on the same supported FreeIPA release line and apply security updates promptly. FreeIPA 4.13.4, dated July 9, 2026, fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, and hardened authentication checks across the API. Replicas left on older builds keep those exposures, so confirm the installed version on every host after each update window.
DNS over TLS for IdM DNS
FreeIPA 4.13.0 introduced DNS over TLS between clients and IdM DNS servers. Enable it where your release and client platforms support it, so resolver traffic that points clients at IdM hosts is not readable or alterable on the network. Confirm client support in your environment before changing resolver settings, and keep at least two DNS servers in each client's resolv.conf.
What do teams ask before hiring help for FreeIPA HA?
How much more effort does FreeIPA high availability add over a single server?
HA adds planning and testing work on top of the install, so expect more effort than a single server, with the extra time concentrated in topology design, replication checks and recovery testing. Each extra server needs its own OS build, time sync, DNS records, firewall rules and client enrollment, and the replication agreements must be planned so that no replica exceeds four agreements. Your team also needs a written failure runbook and a rehearsed restore. The size of the increase depends on the number of datacenters, whether the CA and DNS run on several replicas, and how many clients depend on the service. Ask any partner to split the quote into single-server baseline work and the HA additions so you can compare them directly.
Are two FreeIPA replicas enough for high availability?
Two is the floor, and many production designs add a third in each datacenter. The FreeIPA deployment recommendations advise at least two to three replicas in each datacenter. Two replicas cover one server failure, but when one is down for patching you have no spare, and a second fault in that window causes an outage. A third replica in a site gives maintenance room. If you run the internal CA or integrated DNS, at least one replica in each datacenter should run those services. Clients matter too: each host's resolv.conf should list at least two DNS servers. Confirm the replica count per site with your architects once you know your patch cadence and traffic volume.
What does the first server's renewal role mean for HA planning?
Certificate renewal and CRL publication run on the first server by default. The FreeIPA backup documentation notes this, so the role is a dependency you must plan for. If that server is offline for long enough, scheduled renewals and CRL updates stop, and certificates can expire without warning. Plan for it in three places: monitoring that alerts on renewal and CRL status, a written procedure for moving the role if the server is lost, and backups that include the CA. Confirm with your PKI owner which systems depend on the issued certificates and how often those certificates expire. List the first server as a named dependency in your runbook.
How long does a FreeIPA restore test take?
Measure it in your own environment, because the answer depends on your data and topology. Duration depends on backup size, whether you use a full or online data-only backup, network speed to the restore host, how many replicas must be rebuilt afterward, and how clear the runbook is. A credible test needs an isolated restore host or lab that matches production OS and FreeIPA versions, a recent backup made with ipa-backup, your topology notes, and a named person who runs each step with a timer. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so the test must confirm how the restored server is isolated before it rejoins. Ask any partner to state the test scope and record measured results in the written plan.
Can our own team build FreeIPA HA without a partner?
Yes, if you have the Linux, DNS and PKI skills and the time to test failure cases. FreeIPA is licensed under GPL-3.0-or-later with no license fee, so building it yourself costs staff time, lab capacity and the ongoing work of upgrades, certificate checks and monitoring. Your team needs experience troubleshooting Kerberos and LDAP, designing DNS for clients, managing certificate lifecycles and keeping a lab that mirrors production. In-house efforts often stall on untested restores and on the first server's renewal role. A partner adds value if your staff is thin or you want an independent design review. Ask whether the scope covers both the build and a rehearsed restore, since those are the parts most often skipped.
What does the work need from our staff during an HA engagement?
Named owners, access, and decisions made on time. Your side typically provides a sponsor who approves the topology and DNS domain, network and firewall changes between sites, administrator access to hosts and cloud accounts in your environment, and a Linux identity owner who can answer questions about clients and applications. Your PKI owner should confirm certificate lifetimes and which systems trust the CA. Someone from operations should attend the restore test and handover so they can run the runbook after go-live. Expect review meetings and sign-off steps defined in the written scope. Your staff time is a cost too, so ask the partner to list each dependency on your side before work starts.
What does a fixed-scope FreeIPA HA engagement include?
Scope, deliverables and timeline agreed in writing before work starts. Elements to confirm in the scope include topology design for each datacenter, replica builds and replication setup within the agreed limits, CA and DNS placement, client DNS failover configuration, monitoring and renewal checks, backup configuration, a tested restore, and documentation with a handover runbook. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms inside your own infrastructure. It does not issue audit reports or certifications, so compliance evidence still comes from your independent auditor. Ongoing support, upgrades and continuous testing are available as separate retainers. Request a quote built from the written scope, with out-of-scope items listed.
How do cost drivers for FreeIPA HA change the quote?
The main drivers are topology size, the number of sites and what runs on each replica. Each additional datacenter adds replicas, network work and testing. Running the CA or DNS on several replicas adds configuration and verification. An Active Directory trust, a migration from another LDAP source, or stricter monitoring each add scope. The build is largely one-time work, while patching, certificate checks, restore drills and upgrades recur. Ask the partner to separate one-time build items from recurring support items, state which environment is in scope, and list the assumptions behind each line. A quote that names those assumptions is easier to compare with an internal estimate.
How DeployOpen works on this
DeployOpen plans, builds, documents and supports FreeIPA high availability on servers inside your own infrastructure. The work starts with a written, fixed scope that covers replica placement, CA and DNS roles, client failover and backup and restore testing before any server is built.
How we scope
- Written scope that lists the datacenters, replica count per site and which replicas run CA and DNS
- Replication agreement map checked against the limit of no more than four agreements per replica
- Confirmation of which server holds the first-server renewal and CRL role, and how that role is protected
How we build
- Dedicated replica hosts with DNS and CA placement on at least one replica per datacenter where used
- Client resolv.conf configured with at least two DNS servers, tested by forcing failover to each server
- Failure drills for a replica outage, a lost datacenter link and a renewal run, recorded with results
How we hand over
- Runbooks for adding a replica, removing one, rotating certificates and restoring from ipa-backup
- Restore test on an isolated host, showing the backup set works and the procedure is repeatable by your team
- Documented topology diagram, agreement map and acceptance checklist signed off before go-live
How we support
- Ongoing support, upgrades and testing are available as a retainer after go-live
- Review of 4.x stabilization and security releases, applied to replicas one at a time
- Periodic backup restore checks and certificate renewal reviews, scoped in the retainer
