Designing a multi-datacenter FreeIPA topology

The effort depends mostly on how many sites you run, how many replicas each one needs, and what already sits beside FreeIPA. A design for two sites with no existing directory is a small exercise in agreement layout and role placement. A design that must also absorb an existing LDAP directory, an Active Directory forest or a DNS estate owned by another team takes considerably longer, because each of those adds decisions that cannot be made in isolation. The FreeIPA deployment recommendations advise at least two to three replicas in each datacenter and no more than four replication agreements per replica, so the number of sites multiplies the number of servers and agreements to plan. Ask for the design to list every server, role, agreement and DNS location before any build starts.

Yes, if the team has someone who can read the FreeIPA deployment recommendations closely, test name resolution from every site, and reason about what happens when a site drops off the network. The harder part is usually not the installation commands but the decisions: which servers carry the CA, DNS and trust roles, where the first server's renewal and CRL duties should sit, and how the topology stays connected when a site is lost. Teams that have run FreeIPA in one location often underestimate how much of the design depends on DNS ownership and on the network paths between sites. An outside review of a draft topology is a common middle path, and it can be scoped separately from a full build.

Expect to supply a current network diagram showing every data center, the links between them and any firewall or routing limits, plus the DNS zones that FreeIPA will serve or delegate to. You will also need the list of existing systems that authenticate against the directory, any LDAP or Active Directory servers that must stay in service during migration, and the names of the people who approve DNS and firewall changes. Change windows matter because adding replicas, moving roles and changing agreements all touch live authentication. Confirm with your own change board how many windows you can book, how long each one lasts and who must be on call. Missing DNS ownership is the most common reason a design stalls.

The timeline follows the scope, and no duration is fixed until the written scope and your environment are reviewed. The main variables are the number of sites, whether the work is a new deployment or a change to a live topology, how many external systems must be integrated, and how quickly your DNS, network and change approvals move. A new deployment in a single lab can be measured in days of build work, while a live topology change across several sites that must keep authentication running usually needs staged windows and a rollback plan. Ask for a phase plan with dependencies, and check which phases depend on your teams rather than on the implementer.

A fixed-scope quote covers the work described in a written scope, including the agreed deliverables, the timeline and the acceptance criteria, and it does not cover work outside that document. For a multi-site design, the scope should name the sites, the number of replicas per site, the role placement for CA, DNS and trust, the agreements to be created, the verification tests and the documentation handed over. It should also say what is excluded, such as ongoing operations, hardware procurement, or changes to other directories. DeployOpen does not publish a price list, so the quote follows from that written scope. Ask for the assumptions and the client responsibilities listed alongside each deliverable.

Cost is driven by the same factors as effort: site count, replica count, the number of systems that must integrate, and the state of your DNS and network. A design project has one-time costs for discovery, design, build and verification, and some teams add recurring costs for ongoing support or upgrades. Hardware or virtual machines, storage and any cross-site bandwidth are paid to your own vendors or cloud providers and are separate from implementation work. The FreeIPA project is community licensed under GPL-3.0-or-later with no paid edition, so software licensing is not a line item. Ask for each cost component to be shown separately in a quote, with the recurring items marked.

The design must answer this before any server is added. If the site that holds the only CA, the renewal and CRL role, or the only DNS servers goes offline, clients in other sites can lose authentication or certificate services even though their own replicas are healthy. The FreeIPA deployment recommendations call for at least one replica per datacenter running PKI or DNS when those services are used, and for at least two DNS servers in each client's resolv.conf. Confirm with your team how replication paths reroute during an outage, which roles must be moved before a planned shutdown, and how the topology is tested with a site intentionally isolated.

It can, and the answer changes the layout. If you plan a cross-forest trust with Active Directory, the IPA domain must use a DNS domain that does not overlap with any domain in the AD forest, and that choice affects naming and DNS delegation across every site. Existing LDAP directories also shape the plan because users and groups may need migrating into FreeIPA, and the migration path differs for sudo and HBAC rules. Settle naming, trust intent and migration scope before the replica layout is fixed, so the topology does not need to be rebuilt later. Confirm the trust and migration requirements with your directory and DNS owners first.